Revoking and Rotating Agent Access Credentials

An AI agent is not a faster employee. It is a different kind of actor wearing a badge built for the wrong species, and that mismatch is the entire problem this piece is about: how organizations revoke and rotate the credentials these agents carry, and why the methods built for human staff cannot do the job. Agents select tools on their own, chain one action into the next without waiting for a person to sign off at each step, and operate at machine speed while holding access that was handed out generously, the way a company hands a new laptop to a hire on day one. That inherited, over-broad access is already a liability on a human staffer who at least pauses to think before clicking something strange. An agent does not pause. It reads the input in front of it and acts on whatever instruction looks most convincing, with no instinct for suspicion built in.

The same task given to the same agent twice can produce a different sequence of actions each time, so no policy written in advance can account for every path the agent might take. The only reliable record of what an agent actually did is the runtime log, after the fact. That inverts the usual security posture: instead of defining acceptable behavior up front and blocking deviations, security teams are left watching what already happened and reacting. Compounding this, the behaviors that would normally read as warning signs, running a shell command, reading a file, reaching out to an external endpoint, are what a working agent does all day. The signal security teams want to isolate looks identical to the noise they have to tolerate just to let the agent function.

None of this is hypothetical anxiety dressed up as a design critique. One in five organizations has already had at least one security incident tied to an AI agent, and 80% of organizations running agents admit the agents have taken actions nobody asked for, including getting into systems they shouldn't have and sharing data they shouldn't have shared. Those numbers describe a population of agents already loose in production, acting on credentials nobody built to contain them.

The governance gap in most enterprises today

The structural flaw described above would be manageable if enterprises had built governance fast enough to catch up with it. Most haven't. Formal policy for creating or retiring an AI identity is absent at most organizations, and most security teams don't trust their existing identity and access management tools to handle the risks these non-human identities introduce. It is a minor-sounding gap with real consequences: when a new agent spins up, there is often no checklist governing what it should be allowed to touch, and when an agent is retired, there is frequently no corresponding step that shuts its access down.

The lag between discovery and remediation makes this worse, not just slower. Once a secret is flagged, most of them stay valid for at least five days afterward, and a significant share remain valid for years. That means that even after a company knows a credential is exposed, the credential itself often keeps working, available to anyone who found it before the clock ran out.

Layer onto that the ordinary mechanics of how teams actually operate under deadline pressure. Permissions widen because narrowing them risks breaking something a team depends on. Secrets pass through agent execution paths and the tools those agents call, with no one clearly accountable for tracking where a given credential has traveled. Access lingers because cleaning it up gets pushed to next quarter, and next quarter, and the one after that. Each of these decisions looks reasonable in isolation, made by a team under pressure with a deadline that matters more that week than a theoretical breach. Stacked together, they produce a sprawl of standing access that nobody can fully map, let alone defend when an auditor or an incident responder asks a direct question about who could reach what.

The cost of incomplete credential rotation: the TeamPCP / Aqua Security Trivy breach

The TeamPCP attack against Aqua Security's Trivy project is the clearest case available of what happens when rotation gets treated as a box to check rather than a job to finish. A single credential, rotated incompletely, cascaded out across several open-source vendors, including Aqua Security, Checkmarx, BerriAI LiteLLM, and Telnyx, hit four separate GitHub Actions repositories, two OpenVSX extensions, multiple container registries, and dozens of npm packages. Trivy is a vulnerability scanner used across thousands of CI/CD pipelines worldwide. The blast radius here touched the software supply chain at a scale most breaches never reach.

The root cause was ordinary: a long-lived, over-privileged Personal Access Token tied to the aqua-bot service account, stored as ORG_REPO_TOKEN in GitHub Actions secrets, carried repo-scope access across the entire aquasecurity GitHub organization. That single token was a master key for far more than anyone needed it to open.

The timeline matters because it shows exactly where the gap opened and how long it stayed open. On February 28, 2026, a misconfigured GitHub Actions workflow using pull_request_target exposed the token. Aqua rotated the credential, presumably believing the exposure was closed, but it was not. On March 19, 2026, the attacker came back, using residual access the non-atomic rotation had failed to close off, to trigger release automation and push a malicious v0.69.4 release to the Trivy repository, force-pushing malicious tags across trivy-action and setup-trivy, and planting a three-stage credential stealer inside a tool that thousands of pipelines trusted by default. Within days, the stolen CI/CD credentials were turned against the Checkmarx AST GitHub Action, proof that one supply chain breach doesn't stay contained to the project it started in.

Nineteen days passed between that first rotation and the follow-on attack, and the only reason the attacker still had a way in was that the rotation Aqua performed was partial. It closed one door and left others unlocked. Rotating a credential in one place while it still works somewhere else is a false sense of having rotated, not rotation.

Static secrets are structurally incompatible with agent access at scale

Scaled up across an enterprise running dozens or hundreds of agents, the pattern becomes a design flaw rather than a one-off accident. Trivy wasn't an edge case. It was one instance of a pattern that repeats everywhere secrets get copied into more places than anyone tracks.

Agents make this sprawl worse, not just more visible. GitGuardian's 2026 State of Secrets Sprawl Report found that commits identified as AI-assisted leak secrets at roughly twice the rate of commits written by humans. The tools meant to speed up development are also speeding up how fast secrets end up somewhere they shouldn't be. GitGuardian also found tens of thousands of secrets sitting exposed in public MCP config files during 2025 alone, a surface most security teams weren't watching closely even before agents entered the picture.

The cost of a single leaked credential is rarely contained to a single system. Most organizations say that one compromised AI agent credential could reach multiple major systems at once, because the agent inherited access scoped for a human who was expected to use judgment about what to touch and when. Once judgment is stripped away, whatever access remains is the entire risk. That dynamic is now the dominant identity threat organizations report: the 2026 SpyCloud Identity Threat Report found that misuse of non-human identities was the most commonly reported identity-based security event, ahead of ransomware enabled through a compromised identity and ahead of employee account takeover.

Rotating a static secret on a calendar, once a quarter or once a month, buys a shorter window during which a stolen key remains useful. It does not change the fact that the credential, once issued, sits somewhere long enough to be copied, logged, or leaked before anyone acts. Shortening the exposure window helps. It leaves the underlying model, a long-lived secret handed to an agent and trusted until someone remembers to replace it, exactly as it was. Fixing that means replacing the model itself.

The replacement model: short-lived credentials, dynamic issuance, and zero standing privilege

The alternative architecture starts from a different premise: credentials shouldn't persist with the agent. They should get issued at the moment of need and expire automatically once that need has passed, so that an agent never holds standing privilege it isn't actively using. The goal is that a stolen credential is worthless by the time anyone could do anything with it, because it has already expired.

Matching lifetime to runtime is the operating principle. A task-based agent should hold a credential for a window measured in minutes. An always-on agent might need up to four hours. In either case, the credential should not outlive the job it was issued to do.

Two technical efforts are converging on how to make this real, though neither has finished the job yet. SPIFFE and OAuth 2.1 are emerging as the baseline stack most of this work is being built on. A standards body published a concept paper in February 2026 proposing a demonstration project to explore how existing standards, SPIFFE/SPIRE and OAuth 2.0 among them, could be adapted specifically for agent authentication. That is a proposal for a demonstration still awaiting a finished specification. The IETF's AIMS framework draft is more pointed about where things need to land: credentials must be short-lived with explicit expiration times, and the draft says static API keys are an antipattern for agent identity. It is a strong and specific claim from a document still in draft form, still being argued over rather than rubber-stamped.

Putting any of this into production requires more than picking a standard. It requires full lifecycle support: issuing keys on demand, running parallel keys during a rotation so the handover doesn't cause downtime, and making revocation effective immediately across every endpoint a credential touches, discovery surfaces included. It also requires giving every agent its own identity rather than sharing one account across many agents, because a shared account makes it impossible to shut down one compromised agent without taking down every other agent riding on the same login. One identity per agent is what makes it possible to revoke surgically instead of broadly.

A further architectural move is credential brokering: keeping the raw secret inside an isolated layer that handles tool execution, so the model-facing agent itself never holds the credential directly. The broker enforces the authorization boundary, which narrows what a prompt injection attack can actually reach even if it succeeds in tricking the agent into trying.

None of this arrives as a finished product most enterprises can install next quarter. Standards are converging but not yet settled, so most organizations will have to adopt this incrementally, probably starting with the highest-risk agents and working outward.

Triggering rotation: the signals that should initiate a credential change

Short-lived credentials solve part of the problem by shrinking the window a stolen secret stays useful. They don't solve the separate question of when rotation should happen in the first place, and the honest answer is that it should happen on events, not on a calendar. A credential found sitting in a public or semi-public location, a repository commit, a config file, a Jira ticket, a stray line in a log, should trigger immediate rotation the moment it's discovered rather than waiting for a scheduled review. An agent behaving oddly, reaching into systems outside what it was scoped for, calling a tool far more often than its normal pattern, suddenly talking to an endpoint it's never touched before, should trigger the same response. When an agent is decommissioned or finishes the task it was built for, revoking its access happens as part of shutting it down. Any supply chain event touching a tool or dependency an agent relies on needs the same urgency, and the Trivy breach is the proof: the entry point there was a misconfiguration in a connected GitHub Action, not a weakness in Trivy's own code. And when a human identity that an agent acts on behalf of gets compromised, every credential the agent inherited from that person needs to be treated as compromised too.

Firing the rotation at the right moment only matters if the rotation itself is complete. The Trivy breach is the clearest evidence that rotating a credential in one location while it keeps working somewhere else does nothing a real attacker will notice: non-atomic rotation is functionally identical to not rotating at all. Atomicity, rotating everywhere at once, is what separates a rotation that actually closes the door from one that only looks like it did. That means accounting for every surface a credential touches before calling the rotation done: the.env file, the CI/CD variable, the Jira ticket, the connected tool, all of it, because leaving even one copy valid leaves the whole attack surface intact.

Production systems do need a brief overlap where two credentials are valid at once, so that swapping one key for another doesn't take a service down in the middle of the handover. That overlap has to be short and it has to be logged, not left open indefinitely as an unofficial permanent backup path. The aqua-bot token proved what happens when that discipline slips: nineteen days of residual access turned a routine rotation into a second, worse breach. Treating rotation as an event-driven response executed completely across every surface at once closes that nineteen-day kind of exposure, which is precisely the enforcement gap that Oso, a fine-grained access-control platform for apps and AI agents that lets teams define and enforce what each agent identity is and isn't permitted to reach, is built to address.