How Vault thinks about credentials

Vault is built on a small set of architectural ideas that distinguish it from traditional secret managers. Understanding these concepts will help you make better decisions about how to structure your credentials, configure leases, and integrate with AI agents.

Credential Model

Every secret in Vault is a typed credential. Rather than treating all secrets as opaque strings, Vault assigns each credential a type (API key, OAuth token, SSH key, TLS certificate, database URL, or generic secret) and validates it accordingly. Typed credentials enable Vault to apply type-specific policies, rotation strategies, and display formatting.

See Credential Model for the full specification.

Encryption Envelope

Vault encrypts each credential individually using AES-256-GCM. The encryption keys are organized in a tenant-scoped hierarchy: a root key derives tenant keys, and tenant keys derive per-credential data encryption keys. This means compromising one credential’s key does not expose any other credential, and compromising one tenant’s key material does not affect other tenants.

See Encryption Envelope for details on the key hierarchy and cryptographic choices.

Leasing and TTLs

Credentials in Vault are leased, not permanently checked out. When an agent or human requests a credential, they receive a lease with a time-to-live value. The lease grants temporary access to the credential value. After the TTL expires, the lease is invalid and the credential is no longer accessible through it. This pattern limits the blast radius of compromised agents and provides a clear audit trail of when credentials were in use.

See Leasing and TTLs for configuration options and renewal behavior.

Agent Attribution

Every credential access in Vault is attributed to a specific identity. When Claude Code requests a credential through the MCP server, Vault records the agent identity, session ID, and purpose. When a human uses the SDK, their user identity is recorded. This attribution is immutable and forms the basis of Vault’s audit log.

See Agent Attribution for identity types and how attribution flows through the system.

Tenant Isolation

Each organization in Vault operates as a separate tenant with its own key material, credential store, and access policies. Tenants share no cryptographic material. A request scoped to one tenant cannot read, list, or reference credentials belonging to another tenant, even if the underlying storage layer is shared.

See Tenant Isolation for the isolation guarantees and multi-tenant deployment model.