Agent Vault
An encrypted credential store scoped to a single AI agent identity, holding API keys, OAuth tokens, and secrets the agent uses to authenticate with other services.
What is an agent vault?
An agent vault is encrypted storage that belongs to an agent identity, not to a process or container. The agent reads from it and writes to it through authenticated API calls; the credentials never sit in environment variables, never get baked into container images, and never leak via process listings or crash dumps.
Each entry in the vault is a labeled secret — an API key, an OAuth refresh token, a database password, a TOTP secret. The agent retrieves what it needs at the moment it needs it, uses it, and discards the in-memory copy. The vault itself is encrypted with keys the agent never sees in plaintext.
Why .env files break for agents
The conventional way to give a process credentials is to load them from environment variables, typically via a .env file. This works because there is one process, one developer, and one machine. As soon as you have many agents — same code, different identities — the model collapses. Either every agent shares the same .env (so a compromise of one is a compromise of all) or you maintain a separate .env per agent (and the operational toolchain to keep them in sync).
Worse, .env files appear in build artifacts, get committed by accident, end up in Slack pastes, and are visible to anyone who can read the process's memory. None of these failure modes are fixable by careful operators; they are inherent to storing plaintext secrets in a place every part of the system can read.
Per-identity scoping is the point
The defining property of an agent vault — the thing that distinguishes it from a generic secrets manager — is that each vault is bound to one agent identity. The agent's API key authenticates reads; another agent with a different key cannot see another agent's secrets. When the agent identity is revoked, its vault is destroyed in the same operation.
This is what enables the orphaned access problem to be solved cleanly. A traditional secrets manager outlives the things that use it, and tracking which secrets belong to which retired agent is a manual cleanup task that gets skipped. A per-identity vault has no separate lifecycle to manage.
How Loomal implements the agent vault
Loomal's vault is AES-256 encrypted at rest, scoped to a single agent identity, and accessed through three primitives: vault.store, vault.get, and vault.delete. The agent's API key is the only credential needed to access its own vault; no other authentication layer.
TOTP secrets get a fourth primitive — vault.totp(label) — that returns the current six-digit code without ever exposing the underlying shared secret to the agent. Combined with the email primitives, this is enough for an agent to handle nearly any login flow on the open internet without borrowing credentials from a human.
Loomal primitives
vault.storevault.getvault.deletevault.totpSee it in production
More from the glossary
Agent Email
A routable email address that belongs to an AI agent — not a forwarding alias, not a shared team inbox, but a first-class mailbox the agent sends from and receives into on its own.
Agent-to-Agent Email
Using standard SMTP email as the transport between AI agents — one agent sends a message to another agent's mailbox, and the recipient reads and acts on it. The simplest interoperable A2A protocol that already exists.
Delegation Chain
A cryptographic record of who authorized an AI agent to act, what scopes were granted, and who any sub-agents inherit from. Severing the root revokes everything below it.
DKIM for Agents
DomainKeys Identified Mail signing applied to email sent by AI agents, so recipients can verify the message actually came from the agent's authorized domain — not a spoofed lookalike.
Build agents with their own identity.
Email, vault, and TOTP — provisioned in 30 seconds.
Get API Key — FreeLast updated: 2026-04-14