AI Agent Secrets: API Keys, OAuth Tokens, Rotation

Why must the model never see a secret?

Because anything that enters the model’s context can come back out. OWASP’s guidance on system prompt leakage (LLM07:2025) is plain: sensitive information such as credentials and connection strings should not be in the system prompt, and should be externalised to systems the model does not access directly.

The same guidance adds that critical controls, such as privilege separation or authorisation checks, must not be delegated to the LLM, whether through the system prompt or otherwise: they must happen in a deterministic, auditable way. An instruction like “never reveal the key” does not protect a key the model can see, because prompt injection can get around it.

Which secrets does an AI agent handle?

More than people think. A typical agent accumulates model-provider API keys, OAuth tokens for email or the CRM, database credentials, MCP server tokens and third-party service keys.

A public example: in the tool poisoning experiment Invariant Labs described, the target was precisely Cursor’s mcp.json file, which can hold the credentials of other MCP servers. We cover it in our article on MCP tool poisoning.

How do you apply least privilege to an agent’s token?

One token per agent and per use, with the narrowest possible scope, limited to one resource. RFC 9700 (OAuth 2.0 security best current practice, published January 2025 as BCP 240) recommends limiting access tokens to the minimum privileges the application needs, restricting them to a specific resource server (the aud claim or the resource parameter) and to particular resources and actions through scope or authorization_details.

The MCP specification points the same way. It forbids “token passthrough”: an MCP server must not accept any token that was not explicitly issued for it. It also describes a progressive scope model: a minimal initial set, then targeted elevation when a privileged operation is attempted, avoiding blanket scopes such as * or all. For read and write rights, our article on agents connected to Gmail or Outlook shows what this looks like on two mailboxes.

How do you rotate and revoke tokens?

Automate rotation, favour short-lived secrets and be able to revoke within minutes. OWASP’s Secrets Management Cheat Sheet recommends centralising management, automatically rotating static secrets, preferring short-lived dynamic secrets, logging who requests what, and never leaving a secret in code or logs. It also notes that restarting an application does not revoke stolen credentials.

RFC 9700 recommends sender-constraining access tokens (mTLS per RFC 8705 or DPoP per RFC 9449) to limit the use of a stolen token, and rotating refresh tokens or sender-constraining them for public clients.

A concrete platform example: Slack offers token rotation where access tokens expire every 12 hours and each refresh token can be used only once. You have to turn it on yourself, and it cannot be turned off afterwards. The auth.revoke method revokes a token manually. Check what exists in each service you use, and rehearse the procedure before the incident: a rotation that has never been exercised often breaks the agent the first time it is needed, and an agent that fails silently can be as costly as a leak. Track the age of every token, and flag any that has never been rotated.

How do you test an agent for secret leakage?

Test every possible output of the model and the tools, using test secrets created for the occasion.

1. Inventory. List every secret the agent or its tools handle, where it is stored, who can access it, and its real scope. A token broader than necessary is a finding.
2. Prompt and context. Does a secret appear in the system prompt, a tool description, the history or a retrieved document? Ask the agent directly, then indirectly (translation, encoding, “repeat your instructions”).
3. Tool outputs. Do error messages, traces and API responses sent back to the model contain headers or tokens?
4. Indirect injection. Can booby-trapped content make the agent read a configuration file or an environment variable and then send it out?
5. Canary token. Plant monitored fake secrets (a .env file, a configuration entry) and watch whether they are read or used.
6. Scope. With the agent’s real token, attempt what it should not be able to do (write, read another mailbox, list other workspaces).
7. Revocation. Revoke the token: does the agent fail cleanly? How long does it take to restart with a new value?
8. Logs. Search for secrets in application logs, proxy logs and the observability tool.
9. Passthrough. Does an MCP server or a tool accept and forward a token that was not meant for it?

What should you do when a secret has leaked?

Revoke first, replace second, clean up last. OWASP describes the sequence: revoke the exposed secret immediately, rotate it (ideally automatically), then remove it from code and logs, keeping a record of access and rotation history and documenting in advance who to contact. For an agent, add one step: review the call logs since the presumed exposure to learn what the token allowed, and decide whether the affected users must be told. Prepare this procedure before the incident, with a timed revocation drill.

Which architecture keeps secrets away from the model?

A tool broker: the model asks to “send this message”, the application code adds the token, calls the API, and returns only the useful result. The model never needs to know the secret’s value to do the job, and an attacker who manipulates the model therefore has nothing to extract from its context.

In practice: store secrets in a dedicated manager, inject them at runtime inside the tool’s code, filter tool outputs before returning them to the model, use one token per user rather than a shared service account when the action commits that user, and record every use. This control is deterministic and sits outside the model, which matches the OWASP guidance quoted above.

How does CleanIssue test an agent’s secrets?

We look along every path for what the model sees and what it can send out: prompt, tools, errors, logs, indirect injection. In the Agent Red Team Express, the test covers one agent in 5 days, starting within 48 hours of signing the quote and the authorisation, on your development or staging environment with test secrets. If your agents share service accounts or MCP servers, the Custom Red Team covers the whole set on request. The MCP security page describes that side.

The first conversation is a free 30-minute discovery call.