---
title: "Approvals and governance"
---

# Approvals and governance

How your organisation's policy decides each agent action in the Agents app, what happens when an action needs approval or a session is unattended, how engines are governed, and where to see policy, approvals and the activity record.

The Agents app is where agents do most of their work unattended, so governance matters most here. Every action an agent takes is decided before it runs by the governance decision point in the agent host, using your organisation's signed policy. The same policy, the same decisions and the same approval records apply in the Editor.

## Each action has one of three answers

| Answer | What happens |
|---|---|
| Allowed | The action runs. |
| Needs approval | The session shows the rule and the reason and waits for you. In a session nobody attends, including an automation run, this is a refusal. |
| Denied | The action does not run. The agent gets the reason and the rule, so it can try another way. |

What is decided: the engine itself (whether it may run), each tool call, each shell command after full parsing (chained commands, pipes, subshells, wrappers like `sudo` or `timeout`, `sh -c` and PowerShell do not hide a command), each file read and write, each host contacted, each MCP server, and the model. What cannot be analysed, such as `eval` or a program name from a variable, needs a person.

Even with no organisation policy, agents can never change policy files, approval records, git hooks, CI and task files, shell profiles, or the audit and governance folders without a person; writes outside the workspace need a person too.

## Approving

- **You can approve it yourself** when the policy names no approval rule and no control for the action: approve it in the session.
- **Others must sign** when an approval rule or a control applies, for example two reviewers for safety-classified code. Choose **Request Approval**, commit `.neuralinverse/records`, and once other enrolled approvers have signed in the Approvals view, try again. Governance then allows exactly that action or that content.
- **Keeping an agent's changes** is an action of its own and can need approval the same way.

You can sign approvals from the Agents app: open the **Governance** panel's **Approvals** view, or run **Sign Approval Request...**. The device key is held by whichever app started first; when you sign in the other, the prompt comes from the app that holds the key. See [Approvals and signatures](https://neuralinverse.com/docs/editor/approvals/).

## Intent

When the policy requires an intent for a repository, the agent host refuses sessions there until you set one. The Agents app asks for it in the new-session toolbar before the session starts. Agent sessions record the intent they started under, and the policy can confine an agent to the code linked to its requirements; widening that scope needs a person. See [Intent, projects and releases](https://neuralinverse.com/docs/editor/intent-and-projects/).

## How engines are governed

Governance always wins over an engine's own settings:

| Engine | How rules are applied |
|---|---|
| Claude | Rules become Claude permission rules (`deny`, `ask`, `allow`), bypass permissions mode is turned off, denied MCP servers are removed, and a hook decides each tool call before it runs |
| Codex | Rules set its approval policy, sandbox mode and network access |
| Every engine | Whatever the engine's settings cannot express is decided live before each tool call |

Each engine version has a table of what it can enforce. A rule an engine cannot enforce is reported as unsupported, never dropped. A mandatory rule an engine cannot enforce blocks that engine for the session. An engine version governance does not know is treated as enforcing nothing. The Governance view lists the settings governance overrode for each engine.

The `engines` list in the policy can restrict which engines may run at all (for example `claude-code`, `codex`, `neural-inverse`, `copilot-cli`).

## When the policy is locked

If your organisation's policy expired beyond its offline grace, a required policy cannot be verified, or Govern revoked it, agent sessions, tool calls and model calls are locked. The title bar shows the policy as locked by your organisation. You can still edit and commit in the Editor. Your administrator distributes a current policy.

## Where to look

| What | Where |
|---|---|
| Connection and policy state | The title bar indicator: signed out, connecting, `Keystone: <region>`, degraded with a reason code, or locked by policy |
| Policy in force, decisions, waivers, governed settings | **Governance** panel, Governance view |
| Requests and signatures | **Governance** panel, Approvals view |
| Project overview, traceability, release readiness | **Governance** panel |
| Everything recorded | **Open Activity Log** |
| Evidence packs | **Build Evidence Pack**, **Open and Verify Evidence Pack** |

The Agents app records into the same activity record as the Editor. Every engine's sessions, prompts, tool calls and permission decisions are recorded through the engines' own hooks, without modifying the engines. See [Activity Log and audit upload](https://neuralinverse.com/docs/editor/activity-log/).

## What binds

A modified build, or an engine run outside the agent host, is outside the device's controls; the activity record shows a modified build. What must hold is enforced by Govern (its model gateway, organisation context and vault) and, for merges and releases, by your CI. See [Organisation policy](https://neuralinverse.com/docs/editor/organisation-policy/).