Neural Inverse Govern

Neural Inverse Govern, powered by Keystone, is the control plane for the AI tools, models and agents your engineers use. It holds identity and access, decides what each person, agent and tool may do, enforces those decisions in its own gateways, and records every decision in a tamper-evident audit log.

Govern is self-hosted. The backend is a single Go binary with PostgreSQL as its only required dependency, and it is designed to run without calls to external services. See Deploy and operate.

Where decisions are enforced

Govern is the single source of policy. The Neural Inverse apps, the endpoint agent and third-party tools read it; none of them invents rules.

• Server side. Model requests, MCP tool calls and agent-to-agent calls are decided in Govern's own gateways. These checks are the security boundary.
• On the developer's machine. Local actions of coding agents (shell commands, file reads and writes, pushes, package installs) are enforced by the endpoint agent from a signed policy manifest. How much control this gives over a third-party tool depends on the tool; see Third-party AI coding tools.
• Checks inside an app are a second line. An editor's own checks improve the experience but are not relied on, because a modified client can remove them.

Decisions fail closed: an unknown action, an unreadable policy, a missing signing key, an expired manifest or a failed audit write is a denial.

Main concepts

Organisations

An organisation is a tenant. Every organisation's data sits in the same PostgreSQL database, and the database itself keeps them apart with row-level security, so a query without an organisation context fails instead of returning another tenant's rows. See Security architecture.

Inside an organisation, a directory of nodes (teams and projects, nested as a tree) and groups (static or rule-based) is what roles, policies and budgets attach to.

People and agents

• People sign in with a password and second factor, passkeys, or single sign-on through your identity provider, and can be provisioned by SCIM. See Identity and access.
• Service accounts and API keys are non-human principals with their own credentials and scope bounds.
• AI agents are registered as identities of their own: OAuth clients with a scope ceiling (a caller can only grant scopes it holds), short-lived agent tokens, delegation from a person to an agent (RFC 8693 token exchange, limited by the person's consent), and suspend and revoke.

Roles and least privilege

Access is granted with roles bound to a node. Account roles (Owner, Admin, Member, Security and compliance, Billing, Read-only) cover the whole organisation; resource roles (User, Viewer, Editor, Manager) cover a project or one object. Deny policies, permission ceilings and separation-of-duties rules sit around them, and nobody can grant a permission they do not hold or grant anything to themselves. See Roles and permissions.

Policy

Policy is the set of rules that decides what AI may do:

• Model access: which models exist for whom, through which provider connections, at which data classification, within which budgets. See Model access and AI Gateway.
• Agent policy: allow, ask and deny rules for what coding agents do on a machine. See Agent policy.
• MCP servers: a reviewed catalog of MCP servers, assigned to the organisation, teams or projects, called through the MCP gateway.
• Remote agents: allow rules for which people, services and agents may call which remote agents through the agent gateway.

Approvals

When a rule says "ask", the action waits for a person. Approvals can be confirmed by the developer or routed to named approvers, who decide in one approvals inbox. A requester can never approve their own request. Approval requests can also be sent to webhook, email, Slack and PagerDuty channels. See Approvals.

Audit

Every change and every enforced decision is written to an append-only audit log, chained with HMAC-SHA256 per organisation and sealed with signed checkpoints. Exports are signed and can be verified offline. See Audit log.

The three gateways

Each gateway authenticates the caller, applies the organisation's policy and data loss prevention (DLP), keeps provider and remote-agent credentials out of the caller's hands, and audits every call.

Guides in this section

Context, evidence packs and deployment have their own sections: Context, Evidence and Deploy.