Neural Inverse Govern / Identity and access

Access that follows your directory and never grants itself.

Single sign-on, provisioning, least-privilege roles, just-in-time access and access reviews for the people, keys and agents that use AI in your organisation.

Sign-in
SAML 2.0, OIDC, passkeys and TOTP
Provisioning
SCIM 2.0
Access model
Account and resource roles, with guardrails
Elevation
Just-in-time, with approval
Record
Every change in the audit log

Overview

Govern is the identity provider for the Neural Inverse apps and the authorisation service for everything it governs. People sign in through your identity provider, SCIM keeps them current, and roles bound to your teams and projects decide what each person, key and agent may do. Guardrails cap what any role can grant, elevated access is temporary, and every change is written to the audit log with the change.

What it does

What identity and access covers.

Who someone is and how they prove it, and what they may do once signed in.

Single sign-onSAML 2.0 and OpenID Connect connections, with presets for Microsoft Entra ID, Okta, Google Workspace and Ping Identity. A change is a new revision that can go live only after a passing test sign-in of that exact revision.
Certificates and sessionsService provider certificates roll over on their own, with warnings before any certificate of a connection expires, the identity provider's included. Each connection can set shorter sessions, a re-authentication window and identity provider MFA for administrators.
Sign-in methodsPasswords with a per-organisation policy and lockout, authenticator-app codes with recovery codes, passkeys, and Google, GitHub or Microsoft sign-in. Machines without a browser sign in with a device code approved in the console.
Verified domainsClaim your email domains by DNS record or file, and set each to off, optional or required single sign-on. Making it required checks its preconditions, takes effect on a date you set and can wait for a second person's approval.
Break-glass sign-inWhile single sign-on is required, the root user and up to two emergency administrators keep a console-only way in: password, second factor, a written reason and a session of at most one hour. Every attempt alerts the other administrators.
Provisioning and leaversSCIM 2.0 creates, updates and deactivates people and groups. A deactivation suspends the login, ends sessions and refresh tokens, disables API keys and revokes every role binding before the response is returned.
Group mappingsIdentity provider groups and SCIM groups map to permission sets, account roles or project roles. Mapped bindings cannot be changed by hand and are reconciled at every sign-in and every SCIM change.
RolesAccount roles (Owner, Admin, Member, Security and compliance, Billing, Read-only) and resource roles (User, Viewer, Editor, Manager) on a project or a single object, plus custom roles. Approval is always a separate permission.
Guardrails on accessDeny policies, permission ceilings, delegation allow-lists and separation-of-duties rules sit on teams and projects and apply to everything below them. None of them can grant.
No self-grantingGranting a role requires holding every permission it grants. Nobody can grant a role to themselves or to a group they belong to, and at least one Owner is always kept.
Just-in-time accessEligible roles are activated with a justification, a fresh second factor and an end time. Where approval is required, the approver cannot be the requester. Break-glass roles skip approval but raise an alert and a mandatory review by someone else.
Access requestsA person can ask for a level on one project, model connection or MCP server. A manager of the object who is not the requester decides, and approval grants the level in the same transaction.
Access reviewsCampaigns on a schedule ask named reviewers to keep or revoke each role binding. Reviewers cannot decide on their own access, undecided items can be revoked at the close, and each campaign exports its decisions as evidence.
API keys and service accountsA key holds a permission only when both its own scopes and its owner hold it, checked on every request. A key whose owner is disabled or gone stops working; service accounts keep automation independent of any person.
Agent identitiesAI agents are identities of their own, with short-lived tokens, a scope ceiling, delegation from a person limited by that person's consent, and suspend and revoke.
Explain a decisionAsk why someone can or cannot do something and see every deny, ceiling and binding considered. The analysis uses the same engine as enforcement, so it cannot disagree with it.

Access guardrails and access reviews are configured through the API; they have no console page yet. LDAP and Active Directory directory sync is partial and is not a sign-in method.

How it works

From your identity provider to a reviewed grant.

  1. Connect
    Add a SAML or OIDC connection, copy Govern's values to your identity provider and import its metadata.
  2. Test
    Sign in through the connection yourself. Only a tested revision can be activated.
  3. Enforce
    Verify your domains and make single sign-on required on a date you choose.
  4. Provision
    SCIM pushes people and groups; group mappings turn them into roles.
  5. Approve
    An activation that needs approval waits for someone with the right permission who is not the requester.
  6. Review
    Campaigns certify who holds what, and export the decisions as evidence.

Who uses it

Built for every role that answers for AI.

Identity and IT administratorsConnect the identity provider, verify domains, require single sign-on, run SCIM and map groups to roles.
Security and compliance teamsRead the audit trail and access configuration, run access reviews and export their evidence, without being able to grant roles.
Project and object managersShare projects and objects up to their own level, and decide access requests from people other than themselves.
EngineersSign in once, activate eligible roles when they need them, and ask for access to a single object.

Enforced and recorded

Decided on every request, recorded with every change.

Access is checked by the server on every request. The record of who changed what is written with the change itself.

Enforced

Every routeEvery route declares what it needs. The server refuses to start while a route has no declaration, and a request to an undeclared route is denied.
Permission checksIn a fixed order: the permission exists, the node is in the caller's organisation, the caller is not disabled, deny policies, ceilings, role bindings, separation of duties. A deny whose condition cannot be evaluated still applies.
Required single sign-onPassword sign-in, passkey sign-in and device approvals are refused for addresses at a domain that requires single sign-on.
Temporary stays temporaryAuthority from a just-in-time activation can only create bindings that expire with it, and never counts for Owner-reserved actions.
KeysRevoked and expired keys are refused at authentication, which is never cached. A demoted owner's keys lose what the owner lost.

Recorded

ChangesEvery change to roles, bindings, guardrails, settings, activations and reviews, in the same transaction as the change.
Sign-insEvery single sign-on attempt, successful or refused, with its reason; every break-glass sign-in and every refused attempt.
ProvisioningSCIM token changes and every SCIM change, with provisioning status that shows the last operations without their attributes.
ReviewsEvery item, decision, reviewer and time of an access review, with the audit record ids, exportable as JSON or CSV.

Where it runs

Your identity provider, your deployment.

Deployment options
Self-hosted and in your cloudGovern signs people in on your own installation; secrets for connections are held in its vault and never returned.
Identity providers on your networkCalls to an identity provider go through Govern's outbound guard. A provider on a private address is allowed by the operator.
Domain checksVerifying a domain on a self-hosted installation needs a DNS resolver the operator configures.
Hosted by usWe run it for you, with the same controls and audit record.

Talk to our team.

Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation.

Identity and access · Neural Inverse Govern · Neural Inverse