Give your agent a key, not the keyring

An agent has a task: pull last month’s refund report and drop a summary in a channel. Someone wires it up in an afternoon. The fastest way to make the tool call work is to paste the platform’s existing API key into the agent’s environment, because that key already reads refunds. It also issues refunds, changes payout schedules, and lists every customer.

The task needed read access to one report. The agent now holds the company’s most powerful payments credential, and it holds it for every run, not just this one.

This is the credential problem for agents, and it is not the same as the credential problem for a normal service. A normal service runs code you reviewed. An agent runs a plan a language model wrote at request time, reads untrusted content, and can be steered by that content. The question worth asking before an agent gets any secret is narrow: what is the smallest credential that finishes this one run, and how do I make sure it is gone afterward?

Why “the agent has the key” is the wrong mental model

Handing an agent a long-lived credential fails on two fronts at once, and both are on OWASP’s 2025 list of top risks for LLM applications.

The first is excessive agency. OWASP describes this as giving a model more tools, broader permissions, or more autonomy than its task requires, which turns the model’s reach into an attack surface OWASP Top 10 for LLM Applications. A refund-summary agent that holds a refund-issuing key has exactly this shape. Nothing has to be malicious for it to matter: a confused plan, a prompt-injected instruction inside the report data, or a wrong tool argument can now do more damage than the task ever called for.

The second is sensitive information disclosure, which OWASP moved up to second place in the 2025 edition because agents read context and produce output that can carry secrets back out OWASP Top 10 for LLM Applications. A credential placed in the model’s context is data the model can repeat. It can end up in a completion, in a tool argument, in a log line, or in a memory file the agent writes for its next run.

So the credential is exposed to more actions than the job needs, and exposed to more channels than a service key normally travels through. Both problems shrink when the credential is small and short-lived. Neither is fixed by a better prompt.

Three places the secret leaks once the agent holds it

If an agent can see a secret, assume the secret can escape through anything the agent can write to. There are three routes worth naming, because the defenses differ.

Leak route	What it looks like	What actually contains it
Context and prompt	The key sits in the system prompt or an environment dump the model can read	Keep the raw secret out of model-visible context entirely
Transcripts and logs	The key appears in a tool-call argument, an error message, or a saved session	Redact at the logging layer; never log raw arguments for auth calls
Agent memory and output	The agent writes the key into a notes file, a summary, or a downstream message	Scope what the agent can persist; short-lived secrets limit the damage

The uncomfortable part is that redaction is a second line of defense, not the first. Regex-based scrubbing misses reformatted or base64-encoded values, and it cannot catch a secret the model paraphrases. The reliable move is to make sure the secret is never in a place the model can read in the first place. Redaction then protects the paths you did not anticipate.

Scope to the run, not to the agent

The durable fix is to stop thinking of “the agent’s credentials” as a standing set and start issuing credentials per run, matched to that run’s task.

This is the same logic zero trust applies to any actor. NIST’s Zero Trust Architecture describes access as per-session, granted with least privilege, and decided dynamically from identity and context rather than from a standing grant tied to where the request comes from NIST SP 800-207. An agent run is a session. Treat it like one.

Concretely, that means a broker sits between the agent and your secret store. When a run starts, the broker issues a credential that is:

• Narrow. Read-only scope for the one system the task names, not the parent key’s full scope. CWE-798 covers the failure mode where credentials are embedded and reused in software; its remediation is to keep credentials out of code and in strongly protected storage rather than baked into the thing that runs CWE-798.
• Short-lived. The OWASP Secrets Management Cheat Sheet recommends dynamic, on-demand secrets precisely so that a stolen credential expires quickly; it notes that if an application’s database credentials are dynamically generated per session, stolen credentials are useless after the session ends OWASP Secrets Management Cheat Sheet.
• Attributable. The credential is tied to this run’s identity so that later audit can answer which run did what, instead of “some process used the shared key.”

Suppose a run’s credential lives for the length of the run plus a small margin. If it leaks into a log, the window to abuse it is measured in minutes, and the scope is one read path. Compare that to a leaked standing key with full payments access and no expiry. Same leak, very different incident. The numbers here are illustrative, not measured — the point is the shape of the blast radius, and you should set the actual lifetime from your own run durations.

Better still: keep the secret out of the agent entirely

Scoping shrinks the damage. Not showing the model the secret at all removes a whole class of it.

The pattern is a credential-injecting proxy at the egress boundary. The agent calls an internal endpoint with only its run identity. The proxy checks that this run is allowed to make this call, attaches the real downstream credential, and forwards the request. The secret never enters the model’s context, so it cannot be repeated in a completion, and it never touches a tool argument the agent might log.

The Model Context Protocol’s security guidance names the anti-pattern this avoids: token passthrough, where a component accepts and forwards a token it should not have taken responsibility for, blurring who authorized the call MCP Security Best Practices. A proxy that issues its own scoped downstream credential, rather than relaying whatever the agent hands it, keeps the authorization boundary legible.

This is more infrastructure than pasting a key into an environment variable. It needs a policy check, an audit log, and a place to store the real secrets. For an agent that touches money, customer data, or production systems, that cost is proportionate. For a developer’s local assistant reading only its own sandbox, it is not — and pretending otherwise just moves the friction somewhere less useful.

Who this is for, and who can skip it

This matters most when an agent runs unattended, on a schedule or a webhook, against systems that can change state or expose regulated data. In that setting the model chooses actions without a human in the loop for each call, so the credential is the last hard boundary. Platform and security teams building agent runtimes are the audience.

You can reasonably skip the broker and the proxy when the agent only ever reads a local sandbox it already owns, when a human approves every state-changing call before it executes, or when the “agent” is really a deterministic script with a fixed set of calls. In the last case, write the service the normal way and give it a normal scoped service account — you do not need agent machinery to hold a key well. Adding a secrets broker to a workflow that a cron job and a read-only token would cover is cost without a matching risk.

There is also a real failure mode in over-scoping the controls: if issuing a run credential is slow or manual, teams route around it and go back to the shared key. Short-lived credentials only help if getting one is automatic. The OWASP guidance is blunt that rotation and issuance should be automated and should limit direct human handling of raw secrets, both to reduce error and to keep least privilege enforceable OWASP Secrets Management Cheat Sheet.

Assume it already leaked

Design the credential path as if a secret has already escaped, because eventually one will. That assumption produces the controls that matter after the fact.

Rotate on a schedule and on demand, so a suspected leak has a fast remedy that does not require finding every copy. Keep credentials attributable to a run, so an investigation can scope the damage to specific runs instead of an undated shared key. Log which run requested which scope and when, but never log the secret value or the raw arguments of an authentication call. And keep the standing parent credentials — the ones the broker draws from — out of every agent environment, so a compromised run cannot mint its own successor.

None of this is agent-specific security theory. It is ordinary secrets hygiene applied to an actor that reads untrusted input and writes to more channels than a service does. The agent just raises the stakes on getting it right.

What to revisit as this changes

Re-examine the credential design when the scope of what agents can reach grows, when a runtime starts persisting agent memory across runs, or when a new tool lets an agent write somewhere it could not before. Each of those adds a channel a secret can travel or a reason a broader grant creeps back in.

The vendor and platform layer here is moving quickly. Managed agent runtimes are adding their own secret injection, per-run identity, and egress controls, and the specifics differ enough that a control you build today may be worth replacing with a platform feature next quarter. Treat this as an area to review on a cadence, not a setting to configure once. The principle is stable even while the tools are not: the smallest credential, for the shortest time, seen by the fewest components, attributable to one run.

A refund-summary agent should be able to read one report and nothing else. If it can also move money, the problem was never the agent. It was the keyring.