---
title: "Organisation policy in the Editor"
---

# Organisation policy in the Editor

What your organisation's signed policy enforces in the Editor, what only the server or CI can enforce, where the policy comes from, how to read the Governance view, and what happens when policy expires.

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:

1. **Managed policy** `NeuralInverseGovernancePolicyBundle` (through Group Policy, an MDM profile, or `/etc/vscode/policy.json` on Linux, trusted only when owned by root and not writable by others).
2. **Your organisation's Govern deployment**: a signed agent policy fetched with your sign-in and verified on the device.
3. **A bundle you imported** with **Import Signed Policy Bundle...** in the Governance view.
4. **The repository**: `.neuralinverse/policy.bundle.json`.
5. **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](https://neuralinverse.com/docs/editor/approvals/) 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.*` and `neuralInverse.security.*` setting;
- `neuralInverse.checks.enabled`, `security.workspace.trust.enabled`, `security.workspace.trust.untrustedFiles`, `security.restrictUNCAccess` and `extensions.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).

```sh
scripts/ni-gov.sh policy show
```

It 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](https://neuralinverse.com/docs/govern/). The managed policies the Editor reads are listed in [Settings and policies](https://neuralinverse.com/docs/editor/settings/).

## 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.