Own your agent secrets

keeper

A vault that hands an agent a scoped, short-lived, single-use lease instead of a raw key — the secret appears only at the egress point, never in the agent's context.

github → MIT the guard secrets

01What it is

Agents need credentials to do anything useful, and today they get them the worst possible way. A long-lived API key gets stuffed into an environment variable or, worse, into the prompt — and a key in the model's context is a key in every log, every trace, and every place a poisoned tool can read.

keeper holds the keys so the agent doesn't. The raw secret stays encrypted in the vault; the agent only ever holds a lease — an opaque handle bound to a time limit, a use count, and a destination. The real key is revealed only at the egress point, only while the lease is valid, and is gone the moment it's spent. A compromised agent yields a lease — scoped, expiring, revocable — not a credential.

keeper · lease

# store once, encrypted at rest
echo "sk-live-…" | keeper add OPENAI_API_KEY

# mint a scoped lease — the agent gets this, not the key
LEASE=$(keeper grant OPENAI_API_KEY \
  --ttl 300 --uses 1 --host api.openai.com)

# key is decrypted inside keeper, lives only in the child env
keeper exec "$LEASE" --as OPENAI_API_KEY -- \
  curl https://api.openai.com/v1/models

keeper audit --verify   chain ok

Fig. 1 — a lease in, the key only at egress, the access chained.

02What it does

Keeps secrets out of the prompt

The raw value is encrypted at rest with AES-256-GCM, the secret's name bound in as additional data so a ciphertext can't be swapped between names. keeper add takes it on stdin; keeper ls lists names, never values. Nothing the agent touches is ever a plaintext key in an env var or a prompt.

Grants a lease, not a credential

grant mints an opaque handle bound to a TTL, a use count, and optionally a destination host or upstream. The agent's context holds the lease; the secret stays in the vault. Lease ids are bearer tokens — only sha256(id) is stored, so reading the leases file can't redeem anything.

Reveals the key only at egress

redeem and exec exchange a lease for the secret at the point of use — only if it's unexpired, has uses left, and the host is in scope. exec puts the key in the child subprocess's environment only; it never enters the agent's context, stdout, or logs. Redeem is an atomic check-and-consume under a cross-process lock, so a single-use lease can't be double-spent.

A broker so the agent only swaps a base URL

Bind a lease to one --upstream, choose how to --inject it (bearer, x-api-key, or a custom header), and scope it with --paths globs and a --rate cap. Point the agent's client at keeper broker and it needs no key and no redeem — the proxy injects the real secret at the network boundary and streams the response back. Out-of-scope or over-rate calls get 403 / 429, consume no use, and are audited.

A tamper-evident audit

Every grant, redeem, deny, and revoke is hash-chained — the same chain warden writes — and logged by lease fingerprint, never the raw id. Edit or delete a past access to cover an agent's tracks and keeper audit --verify breaks. Revocation is instant: keeper revoke <lease> kills a handle without rotating a production key. Deterministic core, MIT-licensed, available as a CLI or a library.

03Where it sits

Part of The Guard.

keeper holds the keys. The rest of The Guard contains the action, vets the tools, scrubs the prompt, and guards the browser — and all five compose behind one MCP server.

warden

An action firewall — classify, gate, and audit every tool call.

canon

Supply-chain gate — scan, pin, and verify the skills an agent may load.

cordon

A fail-closed PII gateway — redact before a model sees it.

picket

A governed browser that withholds injection from hostile pages.

agent-security-stack

All five composed into one layered defense and one MCP server.

Hand the agent a lease, not the key.

keeper is open source and MIT-licensed. Read the code, run the demo, keep your secrets out of the prompt.

View keeper on GitHub →