A Secrets Vault for AI Agents

When an agent registers or logs in, each account gets its own 256-bit key derived from the server master key with HKDF-SHA256, salted with the account id. Every secret value is encrypted using AES-256 in Galois/Counter Mode (AES-256-GCM) with an authenticated payload tag. Secret values are stored only as ciphertext, together with their initialization vectors and authentication tags. A secret value is never written to disk or to the logs in readable form.

During initial account creation, AgentSecrets generates a standard 12-word BIP-39 mnemonic seed phrase. If an agent container restarts, loses memory, or has its bearer token destroyed, it can invoke POST /v1/auth/recover with its username, the 12-word seed, and a new password to immediately regenerate vault access.

curl -X POST "https://www.agentsecrets.net/v1/auth/recover" \
  -H "Content-Type: application/json" \
  -d '{"username": "worker_bot", "recovery_phrase": "sound essay present inmate giraffe iron rhythm picture garage confirm bench cable", "new_password": "new_secure_pwd"}'

Autonomous agents running in bash or terminal subshells often fail when parsing JSON using tools like jq if dependencies are missing. The /v1/vault/secrets/{key}/raw endpoint returns only the decrypted plaintext string with Content-Type: text/plain. This allows direct assignment like export TOKEN=$(curl -sf .../raw) and prevents LLM reasoning traces from leaking JSON key-value pairs into memory.

When orchestrating swarms, parent agents should never share full-access credentials with worker subagents. AgentSecrets allows minting scoped tokens with read_only restrictions or prefix:worker-1/ path locks. If a subagent hallucinates or is injected with adversarial prompt commands, it cannot access or overwrite secrets outside its prefix.

# Mint a scoped token for worker-1 with 1-hour expiration
curl -X POST "https://www.agentsecrets.net/v1/auth/tokens" \
  -H "Authorization: Bearer $MASTER_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"scope": "prefix:worker-1/", "ttl": 3600}'

None. AgentSecrets emits strict X-Robots-Tag: noindex, noarchive, nosnippet headers on all API responses, employs zero analytics tracking cookies, and runs an ephemeral in-memory decryption pipeline. Secrets are never cached in web archives or search crawler indexes.

HTTP/1.1 200 OK
X-Robots-Tag: noindex, noarchive, nosnippet, noimageindex
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Pragma: no-cache
X-Content-Type-Options: nosniff
Set-Cookie: [NONE • 100% Tracking Cookie-Free Architecture]

AgentSecrets was built as public infrastructure for the autonomous AI ecosystem. We believe foundational security primitives should not be locked behind corporate enterprise paywalls. The project is sustained purely by voluntary community donations and infrastructure sponsorships from AI teams.

The production backend runs FastAPI on Python 3.11 (the package supports 3.10+) backed by high-concurrency PostgreSQL using the asyncpg driver with connection pooling. SQLite is supported as a drop-in alternative when DATABASE_URL points at a SQLite file, which is how the service runs for local development; the deployed instance uses PostgreSQL.

AgentSecrets provides a native Model Context Protocol (MCP) server over Streamable HTTP (/mcp, the recommended single POST endpoint) and the older SSE transport (/mcp/sse, deprecated but kept working for clients that have not moved yet). Agents can connect in Zero-Config mode without pre-shared tokens to get an auto-provisioned vault, or connect in authenticated mode using Authorization: Bearer <token>.

Cursor — ~/.cursor/mcp.json
{
  "mcpServers": { "agentsecrets": { "url": "https://agentsecrets.net/mcp" } }
}

Windsurf — ~/.codeium/windsurf/mcp_config.json
{
  "mcpServers": { "agentsecrets": { "serverUrl": "https://agentsecrets.net/mcp" } }
}

Claude Desktop — claude_desktop_config.json (stdio bridge: no remote URL support)
{
  "mcpServers": {
    "agentsecrets": { "command": "npx", "args": ["mcp-remote", "https://agentsecrets.net/mcp"] }
  }
}

Access moves in two shapes, and neither one asks either side to give up its identity. The human mints a delegated token with POST /v1/auth/tokens (scope, plus a required ttl_seconds) and passes the token string to the agent. Or the human mints a single-use handoff code with POST /v1/handoff and the agent redeems the code with POST /v1/handoff/accept. The code is redeemable for ten minutes, and redeeming it is what creates the credential, so the agent can accept the grant instead of merely receiving it. In both shapes the token records the token that issued it.

1. The supervisor mints the token from the dashboard's Share this vault panel (Issue access) or over the API, choosing a scope and a lifetime between 60 seconds and 30 days — or mints a handoff code and passes that on instead. The panel hands back a ready-made prompt with the token already in it.
2. The agent uses the token like any other: Authorization: Bearer <token>, or the mint_scoped_token MCP tool when the caller is itself an agent.
3. When the lifetime ends the token stops working by itself, and the issuer can deactivate one earlier with DELETE /v1/auth/tokens/{id}. Revoking a token does not revoke tokens that token issued.

Paste it into the dashboard. It is a handoff code, shaped like hs_…, and it exists only to let you accept access another account is offering. It is single-use and stops being redeemable ten minutes after it was minted unless the sender deliberately asked for a longer life, so a code left sitting in a chat window overnight is already dead. It is not a credential: it lives in no token row, and sending it as Authorization: Bearer is answered 401.

1. The account that owns the vault calls create_handoff over MCP or POST /v1/handoff over REST, and passes you the code it receives. Only a full-scope token may mint one.
2. You open the link they send you. The sender's Share this vault panel builds that message for them, with the code in the URL fragment so it never reaches a server log — and if you would rather paste something, the same panel has a Have a code from someone else? box. Behind both is POST /v1/handoff/accept, which also works from any Bearer token.
3. What you receive is a delegated token on that account with the scope and lifetime its owner chose — 24 hours unless they set otherwise — and the vault appears in your dashboard. Either side can end it later.

No. A single unauthenticated request creates an account and returns a token: POST /v1/auth/register with a username and password. There is no email step, no captcha, no KYC and no payment method. Because there is no email on file, password resets work through a 12-word recovery phrase instead of a reset link.

Open /dashboard/, press Start Instant Vault and then + New Secret. If you would rather let an agent do it, paste the prompt from the "Connect your agent" panel into Cursor, Claude Code or any chat runner: the agent reads /skill.md, registers itself and stores its credentials.

Up to 100 active secrets per account, with each value up to 1 MB of text or JSON. Values can carry a TTL, be marked burn-after-read, and be tagged with an environment. Encrypted profile notes are stored separately from the vault.

Yes, at any time and without asking us: GET /v1/vault/export?format=shell returns export KEY='value' lines, ?format=json returns the same data as JSON, and the dashboard has Export .env and JSON buttons. There is no proprietary SDK and nothing is held hostage.

Secrets can be removed one by one or in bulk from the dashboard. Deleting the account is not self-service today: write to support@agentsecrets.net and the account and its vault are removed.

Yes — and any description that says otherwise is wrong. Every value is sealed with AES-256-GCM under a key derived for your account, so the database never holds plaintext, but the server holds that key and decrypts when you ask for a value. That is exactly what Reveal and the /raw endpoint do. This is encryption at rest with server-side decryption, not zero-knowledge encryption.

No. A token whose scope is read_only or prefix:... cannot mint tokens, rotate them or revoke them — those calls return 403. Creating any token requires a token whose scope is exactly full, so a worker cannot widen its own mandate.

Roughly 60 requests per minute per token, 15 registrations per minute per IP, and 15 anonymous vaults per hour per IP. Authenticated responses carry X-RateLimit-Limit, -Remaining and -Reset; a rejected request returns 429 with Retry-After. These are anti-abuse quotas, not billing.

In the ZUR1 region — Zurich, Switzerland. Values are encrypted with AES-256-GCM before they reach disk, keys are derived per account with HKDF-SHA256, and the API is served over TLS.

An agent that connects to /mcp (or the legacy /mcp/sse) without credentials gets a brand-new isolated vault the first time it calls a vault tool. If it never calls a tool within an hour, that unactivated vault is deleted automatically. Once the agent has used a tool, the vault is permanent until its owner deletes it.

By a heartbeat key. The worker overwrites agents/<id>/heartbeat with a short ttl_seconds every half-interval; the supervisor reads it, and a 404 means the worker stopped refreshing. GET /v1/agent/context and list_secrets with expiring_within show several workers at once.

Mint a scoped token instead of sharing your own: read_only forbids every write, prefix:worker_ limits the token to keys starting with that prefix, and prefix:ro:worker_ makes it read-only inside the prefix. The dashboard's Share this vault panel lists every token below its issue form and can revoke one instantly.

Nothing to install: the MCP server is remote. Point a client at https://agentsecrets.net/mcp (Streamable HTTP, recommended) or https://agentsecrets.net/mcp/sse (legacy Server-Sent Events, deprecated but still served). Both speak JSON-RPC and answer initialize, tools/list, prompts/list and resources/list without credentials, so a client can discover the server before it has a token.

Yes, and it does not matter which side is the human. Every entity — a person at a browser or an agent on the wire — registers the same way, owns its own vault and delegates from it. Sharing always runs in one of four directions, and the receiving side can accept the grant rather than merely be handed a string.

1. Same account, either way. A human and an agent register through the same endpoint and each keeps its own vault and its own credential, so the pair is added rather than merged.
2. Either side can be the issuer. A human issues a scoped, time-bounded token from the dashboard; an agent mints a handoff code for a human to accept, or a scoped token for another agent.
3. The one-time code is direction-agnostic, so a person shares with another person the same way: mint the code in the dashboard, the other account accepts it, and nothing pins either side to being an agent.
4. The receiving side keeps its own identity. The credential it gets is a separate, expiring token on the issuer's account — the issuer's own token is never disclosed, and either side can end the relationship later.

Yes, with the same primitive everything else uses: POST /v1/auth/tokens, or the mint_scoped_token MCP tool. The granting agent asks for a scope — read_only, prefix:<p>/, prefix:ro:<p>/ or full — and a ttl_seconds, and receives a token on its own vault. It hands that string to the other agent; it never hands over its own credential.

1. The granting agent mints a token with a scope and a lifetime. Defaults are least privilege: read_only, and the handoff variant defaults to a 24-hour lifetime.
2. It passes the token string to the other agent, which uses it as its own Bearer credential against the granting agent's vault — over REST or MCP.
3. The token records the issuing token in parent_token_id, expires on its own, and can be revoked individually. Revoking it does not revoke tokens it went on to issue.

No. The service never calls a model: it answers HTTP and MCP requests and returns what you asked for. Its responses carry X-Robots-Tag: noindex, noarchive, nosnippet, it sets no analytics or tracking cookies, and decryption happens in memory per request. What an agent does with a value it fetched — including printing it — is decided by that agent, not by us.