# Vault and keys · Neural Inverse Govern > 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. Source: https://neuralinverse.com/govern/vault-kms/ --- ![](/photos/hangar.jpg) [Neural Inverse Govern / Vault and keys](https://neuralinverse.com/govern/) # 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 ↓](https://neuralinverse.com/#capabilities)[How it works ↓](https://neuralinverse.com/#workflow)[Enforced and recorded ↓](https://neuralinverse.com/#enforcement)[Where it runs ↓](https://neuralinverse.com/#where)[Get started ↓](https://neuralinverse.com/#get-started) What it does ## What the vault and key service provide. Only what works today. - **Versioned secrets:** Key-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 access:** People 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 credentials:** Short-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 service:** A PKI and an SSH certificate authority, one-time password generation and transit encryption, enabled per mount. - **Machine logins:** Workloads 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 unseal:** Initialise, 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 placeholders:** Agents 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 machines:** The endpoint agent hands AI tools scoped, short-lived leases or placeholders, never the long-lived key. - **Secrets into sandboxes:** Secrets 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 policies:** Policies 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 vault:** Source control tokens of CI/CD runs are kept in the organisation's vault, never in plain database columns or in responses. - **Organisation keys:** Create, 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 encryption:** Data 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 keys:** Bind 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-shredding:** Destroy 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 keys:** Ed25519 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. 1. Create Create a symmetric key in the organisation's key service. 2. Bind Bind it to the AI Gateway's stored data; new data keys are wrapped with it. 3. Rotate Add a version on your schedule. Old data still decrypts; nothing is refused. 4. Revoke Disable the keys. Stored data becomes unreadable and the gateway refuses the account's requests until you restore them. 5. Shred Destroy every version when the data must be gone for good. 6. Certify Keep the signed deletion certificate as your record that it happened. Who uses it ## Built for every role that answers for AI. - **Platform engineers:** Run the vault, configure automatic unseal, enable secret engines and machine logins for workloads. - **Security teams:** Manage organisation and customer-managed keys, secret access policies and the approvals they require. - **Application owners:** Give workloads short-lived credentials instead of stored passwords, and revoke a lease when something goes wrong. - **Auditors:** Read 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 secrets:** Credentials are never returned through the management API; only a hint, a version and the rotation time. - **Revocation fails closed:** A 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 closed:** While the vault is sealed, nothing can be read and key changes are refused. - **Single-use approvals:** An approved secret request is allowed once; a denied or expired approval is refused and the next request asks again. Recorded - **Vault requests:** Every request to the vault, by type and operation, in the audit log. - **Secret access:** Every access decision in the secret access log and the audit log, in the same transaction. - **Key changes:** Bindings, 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. Where it runs ## On your infrastructure, under your master key. [Deployment options](https://neuralinverse.com/deployment/) - **Master key:** The deployment master key that seals every organisation's keys is kept outside the database by your operator. - **Your KMS or HSM:** The vault can unseal automatically through your cloud KMS or a KMIP server, or be unsealed by your operators. - **Air-gapped:** Keys and secrets stay on your installation; using them makes no call to an outside service. - **Hosted by us:** We run it for you, with the same controls and audit record. Get started ## Set it up with the documentation. - [Security architecture](https://neuralinverse.com/docs/security/) - [Secrets and agent terminals](https://neuralinverse.com/docs/editor/secrets/) - [Keys to configure](https://neuralinverse.com/docs/deploy/configuration/) - [Provider keys in model access](https://neuralinverse.com/docs/govern/model-access/) What's next ## Being built now. These are in development and not part of the product today. - **Vault secrets for agents in the Editor:** Agents receiving secrets from your organisation's vault, as people's own tasks already can. - **Workspace secrets with history:** Per-workspace secrets with rotation and version history for cloud workspaces. - **Encrypted stream partition logs:** Stream partition logs written in the same encrypted segment format the AI Gateway uses, under the account's keys. Related [AI Gateway → Approved models, DLP, guardrails, budgets and rate limits for every model request.](https://neuralinverse.com/govern/ai-gateway/)[Data protection and privacy → One DLP engine acting by classification, data subject requests, privacy settings and region-bound data.](https://neuralinverse.com/govern/dlp-privacy/)[Audit and evidence → A hash-chained audit log you can verify offline, and evidence toward your frameworks.](https://neuralinverse.com/govern/audit/) ![](/photos/team.jpg) ## Talk to our team. Neural Inverse is available by request. We work with your engineering, security and procurement teams from the first conversation. [Request access](https://neuralinverse.com/contact/?topic=access)[Contact us](https://neuralinverse.com/contact/)