Agent Credentials Should Expire

Hand an agent a key that never expires and you have not really given the agent access. You have given access to whoever eventually finds that key, for as long as they care to use it. Keys leak out of ordinary systems often enough. An agent raises the odds, because handling material and passing it along is most of its job.

Our position is simple enough to fit on an index card: an agent's credential should be born with the task, scoped to that task, and dead shortly after it. If a deployment cannot say when its agents' credentials expire, the honest answer is probably that they don't, and that is the problem worth fixing first.

A key does not stay where you put it

A conventional service holds a credential in one place, a config store or an environment variable, and uses it from there. An agent moves things. The key, or something that can be exchanged for it, can surface in a prompt, ride along in a tool call, get written into a run log, be quoted in a summary the agent writes about its own work, or travel inside the context handed to a second agent. None of that requires an attacker. It is the normal plumbing of these systems, doing what it was built to do.

That changes what a leak means. With a human operator, a copied key is an incident. With an agent, copies are a by-product of ordinary operation, scattered across stores that were designed for reading, not for secrecy. You cannot reliably hunt down every copy after the fact. You can make every copy worthless on a schedule you choose in advance. That is what expiry is for.

Scope matters as much as lifetime, and the two decisions belong together. A grant that can read one collection for fifteen minutes is a different object from a grant that can write anywhere for a year, even if both are called "the API key" in a config file. Expiry forces the scope conversation, because a credential that has to be re-issued for each task gets its permissions re-asked for each task too.

The machinery already exists

None of this needs inventing. Cloud platforms settled the pattern years ago for ordinary workloads. The AWS Security Token Service issues temporary credentials that work much like long-term keys, except that they are generated on request rather than stored, are valid for a configured span from fifteen minutes up to twelve hours, and stop being recognised at all once they expire. AWS makes the quiet point that follows from that: a credential with a limited lifespan does not have to be rotated, and it does not have to be explicitly revoked when the work ends. Time does it.

Google Cloud lands in the same place from the service account side. Its documentation calls obtaining short-lived credentials the most secure way to authenticate as a service account, with access tokens expiring after one hour by default. It also blocks a neat circumvention: a short-lived credential may not be used to mint a fresh token for the same service account, because that would let a stolen token refresh itself indefinitely. Expiry that can be quietly extended by the holder is not expiry.

Agents are simply late to a settled practice. The workload changed, from a service with a stable job to a system that takes a new instruction every few minutes, and the credential should change with it: one grant per task, sized to the task, rather than one standing key behind every task the system will ever run.

Keep the credential out of the model's hands

Expiry alone still leaves the raw credential passing through a system that writes things down. The stronger shape puts a broker between the agent and the credential. The agent asks the broker for access to a named tool, for a named task. The broker checks that request against policy, obtains or mints a short grant, and the tool gateway attaches that grant to the outgoing call. The model sees that the call succeeded or failed. It never sees the thing that made the call authorised.

This is the arrangement the OWASP secrets guidance points at with dynamic secrets: credentials generated on demand rather than retrieved from a drawer, given a short lease, and revoked when they are no longer needed, which cuts down how much any one credential can be reused. Applied to agents, the payoff is concrete. There is nothing in the prompt to leak, nothing in the transcript to scrape, and nothing in a handoff packet that quietly carries write access to the next run. A stolen transcript becomes a record of work, not a set of working keys.

Renewal belongs to the broker as well, and it should be a fresh decision, not an automatic extension. When a grant runs out mid-task, the broker re-checks the task before issuing another: is this still the job that was approved, with the same scope? Most renewals will pass in milliseconds. The point is that they are checked at all, so a run that has wandered somewhere new does not drag its original permissions along with it.

Where this gets awkward

Plenty of the tools agents need to reach do not offer short-lived credentials at all. Plenty of SaaS products still work the older way: a single API key per account, with no expiry, no per-task scope, and no way to ask for less. There the broker earns its keep differently: it holds the one standing key, never releases it to the agent, and enforces the expiry and scope on its own side of the gateway, by refusing calls that fall outside the current task's grant. The underlying key stays long-lived. The agent's effective access does not.

Long tasks are the other friction. A research run or a migration that legitimately takes hours will cross several grant windows, and a grant that dies in the middle of a multi-step write can leave the work half-applied. The answer is renewal at step boundaries, arranged before the work starts, plus the discipline covered by idempotent tool design: a step that is retried after a renewal must be safe to run twice. What you should not do is respond to one awkward long task by issuing day-long grants to everything.

And the broker itself becomes a high-value target, which is worth saying plainly. You have concentrated the ability to mint access in one component. It needs the boring protections any such component needs, tight policy, a full record of every grant it issues, and no path by which the agent can talk it into a wider scope than the task was approved for. Short-lived credentials shrink the blast radius of almost every failure except a failure of the broker. Staff it accordingly.

None of these are reasons to keep handing agents standing keys. They are the shape of the work once you stop.

Work with us

If your agents are running on keys that never expire, bring that setup through Trida AI's intake and we will work out how to put a broker and a per-task grant between the model and the credential, starting with the tools that carry the most risk.