Neural Inverse Govern / Vault and keys
Secrets that are never handed back, under keys you can revoke.
A vault for secrets, dynamic credentials and certificates, credentials kept out of agents' reach, and per-organisation and customer-managed keys for the data Govern encrypts.
- Secrets
- Versioned, write-only, audited
- Credentials
- Dynamic, leased, revocable
- Keys
- Per organisation, versioned and rotated
- Data
- AES-256-GCM under per-object data keys
- Your key
- Bind, rotate, revoke, shred
Overview
Govern holds secrets in its own vault and returns them only to the workloads and people allowed to use them, never in plain form through the management API. Workloads sign in to the vault with their own identity and receive short-lived credentials. Everything Govern encrypts is sealed under the organisation's own versioned keys, and an organisation can bind its own key to its AI Gateway data, revoke it to make that data unreadable, or destroy it with a signed deletion certificate.
What it does
What the vault and key service provide.
Only what works today.
Versioned secretsKey-value secrets with versions and metadata, soft delete, undelete and destroy. AI provider keys and other credentials are write-only: responses show a hint, a version and the rotation time.
Shared through accessPeople reach a secrets mount only when it is shared with them through Govern's roles, at use, read or write level. A vault policy alone does not grant a person access.
Dynamic credentialsShort-lived credentials for PostgreSQL, MySQL, Redis and LDAP, AWS, Azure and Google Cloud, with leases you can list, renew and revoke, and scheduled rotation of static credentials.
Certificates and encryption as a serviceA PKI and an SSH certificate authority, one-time password generation and transit encryption, enabled per mount.
Machine loginsWorkloads sign in with AppRole, client certificates, JWT, Kubernetes service accounts or a Govern agent's identity, and receive tokens that can be renewed, wrapped and revoked.
Seal and unsealInitialise, seal, unseal, rotate the keyring, rekey and take snapshots, with automatic unseal through AWS KMS, Azure Key Vault, Google Cloud KMS, a KMIP server or another vault's transit engine. Instance operations are for platform operators only.
AI keys behind placeholdersAgents use AI provider credentials through placeholders that an egress proxy replaces with the real key on the way out, within egress allow rules. The real key never reaches the agent.
Short leases on developer machinesThe endpoint agent hands AI tools scoped, short-lived leases or placeholders, never the long-lived key.
Secrets into sandboxesSecrets pushed into a sandbox or workspace land only in memory-backed storage, and only for people who may use both the secret and the target.
Secret access policiesPolicies by secret, agent role, person and environment decide each request, with a maximum lease time. A policy can require a person's approval in the approvals inbox; an approval allows one request.
Pipeline tokens in the vaultSource control tokens of CI/CD runs are kept in the organisation's vault, never in plain database columns or in responses.
Organisation keysCreate, list, rotate, disable and use keys for encrypt and decrypt. Rotation adds a version; every older version still decrypts. Keys are sealed by a deployment master key kept outside the database.
Envelope encryptionData is encrypted with AES-256-GCM under per-object data keys wrapped by the organisation's key. AI Gateway request logs and cached answers are sealed this way.
Customer-managed keysBind one of your keys to the AI Gateway's stored data. Rotation adds a version without refusing a request; revocation disables every key that may wrap the data, and the gateway refuses the account's requests until you restore it.
Crypto-shreddingDestroy every version of the bound keys and receive a deletion certificate, signed with the audit signing key, naming the keys, their fingerprints, the reason and the requester.
Signing keysEd25519 keys sign policy, model, MCP and skill manifests and the audit chain's checkpoints, with public key sets published by your installation for verification.
How it works
Your key, from binding to shredding.
How an organisation takes control of the key that protects its AI Gateway data.
- CreateCreate a symmetric key in the organisation's key service.
- BindBind it to the AI Gateway's stored data; new data keys are wrapped with it.
- RotateAdd a version on your schedule. Old data still decrypts; nothing is refused.
- RevokeDisable the keys. Stored data becomes unreadable and the gateway refuses the account's requests until you restore them.
- ShredDestroy every version when the data must be gone for good.
- CertifyKeep the signed deletion certificate as your record that it happened.
Who uses it
Built for every role that answers for AI.
Platform engineersRun the vault, configure automatic unseal, enable secret engines and machine logins for workloads.
Security teamsManage organisation and customer-managed keys, secret access policies and the approvals they require.
Application ownersGive workloads short-lived credentials instead of stored passwords, and revoke a lease when something goes wrong.
AuditorsRead every vault request in the audit log and keep deletion certificates as evidence of crypto-shredding.
Enforced and recorded
Never returned, never left open.
The vault and the key service each enforce their own boundary on the server and write to the same audit log.
Enforced
Write-only secretsCredentials are never returned through the management API; only a hint, a version and the rotation time.
Revocation fails closedA revoked customer-managed key cannot decrypt, even for code that bypasses the binding, and a binding that cannot be read refuses the request.
Sealed means closedWhile the vault is sealed, nothing can be read and key changes are refused.
Single-use approvalsAn approved secret request is allowed once; a denied or expired approval is refused and the next request asks again.
Recorded
Vault requestsEvery request to the vault, by type and operation, in the audit log.
Secret accessEvery access decision in the secret access log and the audit log, in the same transaction.
Key changesBindings, rotations, revocations, restores and shredding, with the signed deletion certificate stored.
The server can use Go's FIPS 140-3 cryptographic module and refuse to start without it. Whether this meets a validation requirement is for you and your assessor to decide.
Master keyThe deployment master key that seals every organisation's keys is kept outside the database by your operator.
Your KMS or HSMThe vault can unseal automatically through your cloud KMS or a KMIP server, or be unsealed by your operators.
Air-gappedKeys and secrets stay on your installation; using them makes no call to an outside service.
Hosted by usWe run it for you, with the same controls and audit record.
Get started
Set it up with the documentation.
What's next
Being built now.
These are in development and not part of the product today.
Vault secrets for agents in the EditorAgents receiving secrets from your organisation's vault, as people's own tasks already can.
Workspace secrets with historyPer-workspace secrets with rotation and version history for cloud workspaces.
Encrypted stream partition logsStream partition logs written in the same encrypted segment format the AI Gateway uses, under the account's keys.
Talk to our team.
Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation.