Est.

Revoking and Rotating Agent Access Credentials

Credential Exposure Compounds Faster Than Anyone Is Rotating. GitGuardian's State of Secrets Sprawl 2026 found 28.65 million new …

Columnist · · 11 min read
Cover illustration for “Revoking and Rotating Agent Access Credentials”
Access Control for Agents · July 20, 2026 · 11 min read · 2,494 words

Credential Exposure Compounds Faster Than Anyone Is Rotating

GitGuardian's State of Secrets Sprawl 2026 found 28.65 million new hardcoded secrets in public GitHub commits in 2025, a 34% year-over-year increase and the largest single-year jump on record. AI-related credential leaks surged 81.5% year-over-year, with surrounding AI infrastructure leaking five times faster than core LLM providers. Within the MCP ecosystem alone, GitGuardian found roughly 24,000 secrets sitting in MCP configuration files on public GitHub. That exposure surface did not exist at meaningful scale two years ago.

The more corrosive number: 64% of valid secrets leaked in 2022 remain valid and exploitable today. You can detect a problem and document it meticulously and still have done nothing about it.

The Internet Archive breach makes the stakes concrete. An access token sat exposed in a GitLab repository for 22 months before attackers used it to exfiltrate seven terabytes of data. That token also provided access to long-lived Zendesk credentials, extending the blast radius. The threat is rarely just the one leaked key. It's the cascade, where one credential opens the door to the next — like a master key that also happens to be a skeleton key for everything down the hall.

Agents accelerate that cascade in two specific ways. First, they touch many services within a single workflow, so a compromised agent credential isn't scoped to one function but to everything that agent was authorized to reach. Second, agents can create, consume, and occasionally replicate credentials faster than any human-managed rotation cycle was designed to track. The exposure trajectory compounds before anyone notices it has started.

Most Organizations' Governance Hasn't Kept Pace with the Agents Already Running Inside Them

Between 82 and 144 non-human identities already exist per human identity in the average enterprise environment, and AI agent deployments have roughly doubled since late 2025. The governance structures managing those identities have not moved at a comparable rate. That gap is now wide enough to drive a breach through.

The Cloud Security Alliance's 2024 State of Non-Human Identity Security report found that only 20% of organizations have formal processes for offboarding and revoking API keys. The 2026 CSA follow-up found the gap had widened: fewer than 25% have documented, formally adopted policies for creating or removing AI identities, despite the scale of expansion already underway. An Okta survey of 260 executives found that only 10% of organizations have a well-developed strategy for managing non-human and agentic identities at all.

These are not aspirational benchmarks that organizations are striving toward and falling short of. They are baseline hygiene metrics.

Entro Security's 2025 State of Non-Human Identities and Secrets report found that 91% of former employee tokens remain active after offboarding. Every one of those tokens is a potential agent entry point that outlived the human who provisioned it. Only 44% of organizations use a dedicated secrets management system, which means the majority are relying on practices that were not designed for non-human identity volume at anything close to current scale.

Here is what is strange about the current moment: industry confidence in AI security has risen while monitoring coverage, accountability structures, and pre-deployment controls have barely moved. Organizations have become more comfortable deploying agents without becoming materially better at governing them. Those two trends are on a collision course — and when they meet, the wreckage won't be subtle.

OWASP's Non-Human Identity Framework Is Quite Direct About What Breaks First

OWASP's Non-Human Identities Top 10, published in 2025, places Improper Offboarding at NHI1:2025, the single highest-ranked risk in the entire framework. The definition is precise: inadequate deactivation or removal of non-human identities, including service accounts, API keys, OAuth tokens, and certificates, when the human who created or managed them leaves the organization. It earns the top spot because it is simultaneously common and consequential, a combination that tends to break things at scale.

Other high-priority failures in the framework bear directly on agent credential hygiene: secret leakage, overprivileged machine identities, insecure authentication methods, long-lived secrets. NHI reuse across applications amplifies all of them at once. One shared compromised credential lets an attacker move laterally across every service relying on the same identity, with no need to compromise anything else along the way.

The 2025 UNC6395 incident shows what that lateral movement looks like when it actually plays out. Attackers exploited compromised OAuth tokens tied to a sales application, spent ten days exfiltrating Salesforce data, then searched within the stolen dataset for AWS keys, Snowflake tokens, and additional user credentials. They deleted query jobs to complicate detection. One token, one entry point, a ten-day harvest before anyone noticed. It's the kind of story that ends with a postmortem nobody wanted to write.

Compliance floors are rising in parallel. FedRAMP PS-4 sets a four-hour revocation window. SOC 2 CC6.1 and ISO 27001 Annex A 6.5 treat same-day revocation as a minimum. PCI DSS 4.0 requirements that became mandatory as of March 31, 2025 now explicitly require managing and monitoring non-human identities and enforcing least privilege. Regulators, it appears, have read the governance surveys.

Standard Rotation and Offboarding Processes Break in Predictable Ways for Agents

The single-sign-on blind spot is the most structurally underappreciated failure in the whole stack. AI coding assistants and automation tools connected via MCP store API keys locally: in.env files, shell profiles, or the tool's own credential store. Disabling an employee's IdP account does not touch those keys. Virtually every offboarding checklist written before 2025 omits this step entirely, because before 2025, the step didn't need to exist.

Shared credential attribution makes the next problem worse. When multiple agents share a single service account, the audit trail shows which account acted, not which agent or which user delegated the task. Revoking access for one misbehaving agent means revoking it for all of them, which creates operational pressure to do nothing. That pressure wins more often than it should.

There is also the context window problem, which is easy to underestimate until it bites you. Agents silently ingest context from their environment, including files that contain secrets, without the developer seeing precisely what was absorbed. A credential can enter an agent's context window with no log entry, no inventory record, and no revocation trigger when the session ends, because nobody knew it was there.

In multi-agent systems, a single agent may hold active sessions across many services simultaneously. No single revocation action closes all of them, and traditional session-based protocols were not designed for comprehensive cross-system teardown. That fragmentation is architectural. It doesn't go away by trying harder.

Underlying all of this is an operational load problem that rarely gets named directly. Nearly half of security teams report spending more time maintaining their tools than defending their organization. Manual rotation at agent scale isn't a viable strategy; it's a performance of one. Every failure mode described here traces back to the same root cause: applying human-era assumptions to entities that multiply across systems faster than any manual process can follow.

Rotation Reduces Risk, Until It Doesn't

Rotation limits the useful life of a stolen credential. Industry guidance recommends rotating tokens every 15 to 60 minutes for high-risk agent contexts, which meaningfully compresses the window an attacker can exploit a compromised key. That is worth doing.

Three strategies are worth distinguishing. Time-based rotation operates on a scheduled expiry cadence. Event-based rotation triggers when an agent accesses a new resource or when an anomaly is detected. Vault-based rotation relies on automated issuance and expiration with no human handling, eliminating human error from the rotation cycle entirely. Each solves a different slice of the problem.

Rotation is not sufficient on its own when credentials are shared across multiple agents or applications. Rotating a shared secret refreshes the blast radius without reducing it — the scope of exposure stays identical; only the key value changes. This is a common mistake with an expensive correction.

The cache propagation problem is equally limiting, and it gets less attention than it deserves. A rotated key that still lives in agent memory, conversation transcripts, crash dumps, or error reports transmitted to third-party vendors isn't actually rotated. It exists in those locations with the old value, and those locations are frequently neither inventoried nor cleared. Every cache location must be explicitly addressed, or the rotation is incomplete by definition.

What rotation is actually trying to approximate: every credential should be disposable, narrowly scoped, and traceable to a single workload or task. Rotation is a mechanism toward that goal, not the goal itself. Organizations that conflate the two tend to discover the distinction at an inconvenient time.

Revocation Should Happen Across an Agent's Entire Lifetime, Not Just at the End

Rotation vs. Revocation in Agent Credential Security

The timing principle is not complicated: revoke credentials when the job ends, not when the next rotation window arrives. Scheduled rotation and revocation-on-completion solve different problems. Treating one as a substitute for the other is how dormant credentials accumulate.

Trigger-based revocation connects monitoring to access control in real time. When an agent attempts unauthorized commands, reads restricted files, or makes unexpected network calls, the system should revoke associated credentials immediately rather than queue an alert for later human review. This matters specifically for agents because misbehavior can propagate across many systems within seconds. The window between detection and manual response is a window an agent can fully exploit.

Orphaned credential risk is highest in ephemeral agent architectures, where agents are frequently created and destroyed and the identities they held are rarely cleaned up systematically. Each orphaned identity is a dormant entry point: no owner, no expiry, no scrutiny.

A practical frame for revocation triggers: task completion initiates automatic revocation; anomaly detection initiates immediate revocation; agent retirement initiates comprehensive teardown across every system the agent touched. The timescales differ, but the automation requirement is the same for all three. Any revocation process that depends on a human remembering to initiate it will be executed inconsistently, which is functionally equivalent to having no process.

Architectural Patterns That Make Short-Lived, Scoped Credentials the Default

The just-in-time access pattern mints permissions on demand for each task, scopes them to that task, and retires them automatically on completion. Workload identity federation, short-lived OIDC tokens, and STS assume-role flows are the implementation mechanisms. The security property being established is that no standing privilege exists between tasks; there is nothing dormant to steal because there is nothing sitting around.

HashiCorp Vault's dynamic secrets engine is the most widely deployed implementation of this pattern. Secrets do not exist until requested and are revoked automatically when their TTL expires. This eliminates the "forgotten credential" category entirely, which is presently responsible for a substantial share of the leaks described in this piece.

Agents should never handle raw downstream credentials directly. When an agent needs to call an external service, a credential vault should manage the OAuth token, its scopes, its refresh cadence, and its storage. The agent receives a reference, not the secret. This is not a subtle architectural distinction; it is the difference between an agent that can exfiltrate credentials and one that cannot, because it never held them.

Agent identity separation is a prerequisite for any of this to function. Agents need their own service identity, their own credentials, their own audit trail, and their own lifecycle. Reusing a human user's session cookie or long-lived API key eliminates the ability to revoke agent access independently of human access, which collapses meaningful access control into a single point of failure.

For agent-to-agent authentication, mutual TLS with automated certificate issuance, rotation, and revocation via internal PKI or service mesh provides cryptographic verification without static secrets. SPIFFE/SVID workload identity extends this further, providing cryptographically verifiable identities across platforms, clouds, and organizational boundaries without relying on network location as a trust signal. HashiCorp Vault Enterprise now supports SPIFFE natively.

Cloud-native equivalents exist across major platforms: GKE Workload Identity, AWS IAM Roles for Service Accounts, and Azure Workload Identity all connect compute-platform identity to short-lived credentials without static secrets on disk. The tooling exists and has for a while. Adoption is the actual bottleneck.

One forward-looking consideration worth building for now rather than retrofitting later: NIST finalized its first post-quantum cryptography standards in August 2024, designating FIPS 203, 204, and 205. Machine identity infrastructure issued today will still be running when these standards become operationally relevant. Designing for migration is considerably cheaper than emergency remediation after the fact.

What a Lifecycle-Aware Credential Program Actually Looks Like

Agent Credential Lifecycle: Key Controls by Stage

Provisioning is where discipline either starts or fails. Every agent receives its own identity at creation, scoped to the minimum permissions its task requires, with a defined TTL and an owner of record. No shared credentials, no inherited human sessions. This is not a technically complex requirement — it is a policy decision the majority of organizations have not made.

During active use, short-lived tokens rotate on a 15- to 60-minute cadence or on task boundaries, whichever comes first. The credential vault handles issuance and retirement automatically. Agents receive references to credentials, not the credentials themselves. Monitoring tracks runtime behavior against expected patterns, and unexpected resource access, unusual data volumes, or policy violations trigger immediate revocation rather than an alert that will be reviewed at some point tomorrow.

Offboarding should be automated and comprehensive. When an agent's task ends or the agent is retired, all credentials are revoked, all sessions are torn down across every system the agent touched, and all cached values, including memory, logs, and transcripts, are cleared. This happens as an automated teardown triggered by task completion or agent decommission, not as a manual checklist that someone completes when they get to it.

Human departure must now be treated as an agent event. When an employee leaves, the offboarding process must enumerate every agent that employee provisioned, every MCP configuration file on their devices, and every API key stored outside the identity provider. This is the gap that the overwhelming majority of organizations currently have no documented process for closing. It is also, not coincidentally, exactly what NHI1:2025 was written to name.

The inventory requirement underlies all of this. None of these controls work without knowing what agents are running, what credentials they hold, and what systems they can reach. Discovery and visibility are the prerequisite, not an afterthought to be addressed after the architecture is already in production. An organization that cannot answer those three questions cannot revoke anything with confidence, because it doesn't know what needs revoking.

The situation has a particular absurdity to it that is hard to ignore after staring at these numbers for a while: the industry built increasingly capable autonomous agents and then left them running on governance infrastructure designed for a world where a human being was the relevant unit of access. Agents don't respect that framing. They accumulate access in the gaps between human-era assumptions, and they do it at a speed that makes the whole thing look inevitable in hindsight. A lifecycle-aware credential program is the correction. Building it after the cascade is still an option — but a more expensive one.

Sources

  1. knostic.ai
  2. nhimg.org
  3. descope.com
  4. prefactor.tech
  5. prefactor.tech
  6. nhimg.org
  7. nhimg.org

More in Access Control for Agents