Secrets Your AI Agent Can Use but Never Sees

Give an AI agent a real job — log into a SaaS, call a partner API, act on a customer's behalf — and it immediately needs credentials. The unsafe reflex is to hand those credentials to the model: drop the API key in the system prompt, or pass it as a tool argument. Secrets management for AI agents is the discipline of doing the opposite — letting the agent use a secret without ever seeing it.

This matters most when you're building agents into a multi-tenant SaaS, where a single leaked credential isn't your test key — it's a real customer's. This post covers the exfiltration risk, the per-tenant vaulting pattern that fixes it, and how Naïve's vault primitive implements it.

Why is a secret in the prompt dangerous?

The moment a credential enters the model's context, it's reachable by prompt injection. A crafted message — in a document the agent reads, an email it processes, a web page it browses — can convince the agent to reveal, encode, or forward its own instructions. The secret leaks not because your code is careless, but because the attack surface is the input itself.

It gets worse downstream. Prompts, tool calls, and errors are routinely written to logs, traces, and analytics. A key that touches the context window tends to end up in five systems you didn't think about. In a multi-tenant product, that's a real customer's credential in your log pipeline.

What does "use but never see" actually mean?

The goal is to separate the effect of a secret from its bytes. The agent should be able to make an authenticated call, complete a login, or resume a session — while the raw value stays server-side, out of the prompt, out of the client, out of the logs.

That's a vault: an encrypted, per-tenant store the platform reads on the agent's behalf at the moment of use. The agent references a key by name; the platform supplies the secret to the operation and never returns it to the model.

What kinds of secrets does an agent accumulate?

It's easy to picture "the API key" as one thing, but an agent operating in the real world collects a surprising range of credentials, and each one is a liability if it lands in the prompt:

• API keys it generates during onboarding to a SaaS, so it can call that service later.
• Session cookies and tokens captured after an autonomous login, so it can resume a logged-in session without re-authenticating.
• Passwords it sets up on a customer's behalf.
• References like a KYC or verification ID that tie back to a sensitive flow.

Naïve's vault tags each entry with a kind — api_key, password, cookie, token, note, or reference — which keeps this sprawl organized per tenant and makes it obvious what each stored value is for. The important property is uniform: whatever the kind, the raw value lives encrypted and scoped to one user, not in a prompt.

How does per-tenant vaulting compare to a DIY stack?

Here's the hand-rolled version versus the vault primitive.

How do you store and use a secret with Naïve?

Storing is idempotent on the key, and every call is scoped to a tenant user:

// store a secret the agent generated during onboarding, scoped to one customer
await naive.forUser(alice.id).vault.put("instantly.api_key", "key_xyz", {
  kind: "api_key",
});
 
// read it back server-side only when a call actually needs it
const { value } = await naive.forUser(alice.id).vault.reveal("instantly.api_key");

reveal is a POST, so the secret travels in the response body rather than a URL that a proxy or query log might capture. Values are envelope-encrypted with AWS KMS and scoped to alice — no other tenant's agent can reach them.

How does an agent use a secret it can't read?

Mark the entry locked. A locked entry can be written and used by the platform to complete an action, but a reveal returns forbidden — the raw value never comes back to the agent or the operator.

// the agent can use this credential indirectly, but can never read it back
await naive.forUser(alice.id).vault.put("stripe.restricted_key", "rk_live_...", {
  kind: "api_key",
  locked: true,
});

This is the cleanest expression of "use but never see": autonomous login and authenticated API calls work, while the secret stays out of every surface the model or a curious operator can reach.

How does this enable autonomous login?

Autonomous signup and login are where "use but never see" earns its keep. When an agent signs a customer up for a service, it generates a password or captures a session — a credential that must persist so the agent can come back later, but that no one should be able to read out of the system.

Stored locked in the vault, that credential is available to the platform whenever the agent needs to re-authenticate, yet a reveal is refused. The agent gets durable access to the service without ever holding the secret in a form it could leak. Combined with per-tenant scoping, that means each customer's logins stay sealed inside their own vault.

What about expiry and rotation?

Short-lived secrets should disappear on their own. An entry can carry an expires_at timestamp; once passed, it's excluded from listings and returns not-found on reveal — no cleanup job required.

For long-lived credentials, vault_rotate re-wraps the encryption key cheaply, and a full re-encrypt is available when you need to rotate the underlying data. Rotation is an operation, not a migration. See the vault docs for the full tool set and error semantics.

Where does this fit in a multi-tenant agent?

Vaulting is one of the building blocks of a governed, per-customer agent — alongside identity, permissions, spend controls, and revocable sessions. Secrets are the block most likely to cause a headline if you get them wrong, which is why "use but never see" is the default worth designing around. The broader pattern is covered in the multi-tenant playbook, and the enforcement layer around it in Naïve's governance primitive.

Where to start

Pick one credential your agent handles today — a SaaS API key, a session cookie — and move it into the vault: put it under a tenant user, mark it locked if the agent only needs its effect, and reveal it server-side at the point of use. Once one secret flows through the vault cleanly, route the rest the same way. The vault docs are the source of truth for kinds, expiry, and rotation.