Your organisation's governance policy decides what agents may do, which in-app actions need approval, which settings you may change, and what the commit, merge and release gates check. The policy is one signed document, verified on the device, and enforced the same way in the Editor, the Agents app, the agent host, the git hooks and CI. No Neural Inverse server is called: policy reaches the device from your organisation.
What is enforced where
Anything enforced only inside the app can be removed by a modified build. The table says which layer binds.
| Layer | What it decides | Can a person on their own machine skip it? |
|---|---|---|
| The agent host | Every agent session, tool call, command, file read and write, network access, MCP server and model, for every engine | Only by running an engine outside the product |
| The apps (Editor and Agents app) | In-app actions: tool confirmations, keeping agent changes, model selection, MCP servers, extensions, workspace trust, tasks and launch configurations, Neural Inverse settings | Yes, with a modified build; the activity record shows the build |
| Git hooks | Commit and push gates | Yes (--no-verify); CI catches it |
| CI | Merge and release gates on the exact commit | No, when CI runs on protected configuration |
| Govern (server) | Who may read what, model access through its gateway, token validity, organisation context, team work, vault grants | No |
The merge and release gates in protected CI, and Govern's own controls, are what bind. Everything on the device is convenience, early warning and evidence. A local administrator can ultimately do anything on their own machine; the design makes that visible (signed audit checkpoints, the app integrity record, CI verification), not impossible.
Where the policy comes from
The device takes the strongest source that verifies:
- Managed policy
NeuralInverseGovernancePolicyBundle(through Group Policy, an MDM profile, or/etc/vscode/policy.jsonon Linux, trusted only when owned by root and not writable by others). - Your organisation's Govern deployment: a signed agent policy fetched with your sign-in and verified on the device.
- A bundle you imported with Import Signed Policy Bundle... in the Governance view.
- The repository:
.neuralinverse/policy.bundle.json. - The last bundle this device accepted.
Every source must verify against keys your organisation pinned through managed policy (NeuralInverseGovernancePolicyKeys). The product ships with no trusted key, so every bundle is refused until your organisation pins its own. A failing stronger source is reported and the next valid one applies.
Govern's policy is a layer on the bundles, not an alternative: its deny and ask rules are added to whatever bundle supplies the policy (restrictions only add), and it supplies the policy alone when no bundle verifies.
Unsigned workspace rules (.neuralinverse/policy.local.json) are advisory: they warn, never block, and never satisfy anything.
What of Govern's policy applies on the device
Govern's policy model is richer than what the device can enforce exactly. The device turns into local rules only what is exact or stricter: deny and ask rules over file reads and writes, network hosts, models, MCP servers and shell commands. It does not apply allow rules (a local allow lifts nothing), per-kind defaults, or rules about git, packages and hooks; Govern and its agent layer enforce those. An ask that names approvers in Govern is refused locally, because that approval is Govern's. The Governance view states this when Govern is the source.
The Governance view
Open the Governance panel. Its views are Governance, Approvals, Project Overview, Traceability and Release Readiness. With several folders open, choose one with Select Repository....
The Governance view shows:
- Policy in Force: the source (Managed policy, Organisation server (Keystone) verified on this device, Imported bundle, Repository bundle, Governance store cache, or Built-in advisory baseline), the organisation, version, digest, issue and expiry, and the state.
- Rejected Policy Sources, each with its reason.
- Trusted keys and Rollback protection (OS keychain counter, or File counter where there is no keychain).
- You, as the Policy Sees You: your principal, roles and how you are identified (by this device's enrolled key), with Copy Key for Enrolment.
- Recent Decisions, newest first, with outcome, rule and reasons.
- Active Waivers.
- Governed Settings: the settings your organisation decides, and any values in your settings files that were ignored.
Refresh Policy reads the sources again.
Policy states
| State | Meaning |
|---|---|
| Valid | A current, verified policy applies. |
| Cached (last valid bundle) | No current source verified; the last accepted bundle applies. |
| Expired (offline grace period) | The policy has expired and applies within its offline grace. The view says when agent features will lock. |
| Locked | The policy expired beyond its grace, a required policy cannot be verified, the stored policy was deleted or rolled back, or Govern revoked it. |
| No organisation policy | The built-in advisory baseline applies: it warns and never blocks or satisfies anything. |
When locked, agent sessions, tool calls, model calls and governed CLI subcommands are refused on every surface. Editing and saving files keep working, so you can still commit. Deleting the policy never loosens it: deleting the cache after a bundle was accepted also locks.
The device keeps the highest accepted policy version in the OS keychain (service Neural Inverse Governance), so restoring old files cannot roll the policy back. Where there is no keychain (for example Linux without a Secret Service), the counter is a file and a local user can roll back; the view shows File counter (no OS keychain). Managed installs should require a keychain.
Rules that always apply
Even with no organisation policy, agents can never write their own governance: policy files, approval records, git hooks, CI and task files, shell profiles, and the audit and governance folders. Writes outside the workspace and network or device paths need a person. These rules come from the product's code and only make things stricter.
In-app actions
Installing extensions, trusting a workspace, running tasks (every task of a dependsOn chain is decided before any runs) and launch configurations, adding MCP servers, picking a model, keeping an agent's changes and changing Neural Inverse settings are decided by the same decision point. Your organisation can also require extension signatures, allow or block extensions by publisher and name, decide side-loading of VSIX files, disable debugging, and require a signed app. See Approvals and signatures for what happens when an action needs approval.
Hardware operations of domain modules (flash, erase, fuse write, bitstream) are decided as domain actions, so a policy can, for example, require approval for fuse writes on production boards.
Governed settings
A setting your organisation governs takes its value only from managed policy or its default. A value for it in any settings file (user, workspace or folder) is ignored, and you are told; the Settings editor shows it as managed by your organisation.
Always governed, with or without a policy:
- every
neuralInverse.governance.*,neuralInverse.audit.*andneuralInverse.security.*setting; neuralInverse.checks.enabled,security.workspace.trust.enabled,security.workspace.trust.untrustedFiles,security.restrictUNCAccessandextensions.verifySignature.
Once an organisation policy is in force, the agent auto-approval settings are governed too: chat.tools.global.autoApprove, chat.tools.edits.autoApprove, chat.tools.urls.autoApprove, chat.tools.terminal.enableAutoApprove and chat.tools.terminal.autoApprove. Your organisation can list more settings, or the whole neuralInverse.* namespace.
The governance home
Policy state for your OS account lives in <home>/.neuralinverse/governance/<quality>/, where <home> comes from the operating system's account database, never from $HOME or another environment variable, so an agent terminal cannot point governance elsewhere. The folder is owner-only. It holds the imported bundle (policy.bundle.json), the last accepted bundle (cache/accepted.bundle.json) and, while the agent host runs, the local endpoint the CLI and hooks use.
Check the policy from a terminal
ni-gov is the governance tool for git hooks and CI. In a build of the Neural Inverse source it is scripts/ni-gov.sh (scripts/ni-gov.bat on Windows).
scripts/ni-gov.sh policy showIt shows which source is in force, its version, digest and expiry, the trusted key ids, and every rejection with its reason. Exit codes of ni-gov: 0 pass, 1 refused or failed, 2 error or tampering.
For administrators
Writing, signing and distributing the policy, pinning keys, enrolling people, and running the merge and release gates in CI are described for administrators in Govern. The managed policies the Editor reads are listed in Settings and policies.
What is not claimed
No certification. A local administrator can defeat local enforcement; the activity record and CI make that visible. Commit and push gates are conveniences; the merge and release gates in protected CI bind.