On 15 May, an investigative reporter told CISA that internal AWS GovCloud keys and other agency material were sitting in a public code repository.

The repository wasn't one of CISA’s official accounts; instead, it belonged to a contractor who copied infrastructure and build code, along with administrative and build credentials, into a personal GitHub repository.

As you might expect, CISA took the repository and its development environment offline, reset the associated credentials and revoked the individual’s access. Then the response widened. The agency rotated credentials across every environment where the contractor had administrator rights, rather than stopping at the credentials known to have been exposed.

CISA said its analysis found no use of the leaked credentials outside its environments and no exposure of customer or mission data. Those are the agency’s findings. The incident itself was a conventional credential exposure, not an AI-agent breach.

It still gives organisations deploying agents a useful question: when one identity’s authority must end, how many places have to agree?

Rotation Took Longer than CISA Expected

CISA published its account on 9 July. It is unusually candid about the operational friction after the initial containment.

The agency said the complexity of its systems, and their connections with federal and industry partners, caused key rotation to take longer than anticipated. It also said it had lacked a GitHub and cloud incident playbook and had to build one during the early stages of the response.

That evidence supports a narrow conclusion. Revocation can become a cross-system recovery job even when the starting point is one public repository. It does not tell us that CISA lacked an access map, or that a particular credential architecture would have prevented the exposure.

The event also separates two things that are often bundled together. An identity is the durable answer to who acted. A credential or entitlement answers what that identity may do now.

%%Retaining the first does not require the second to remain valid. what exactly are you trying to say here%%

CoSAI Separates Identity from Permission

In March, the Coalition for Secure AI approved version 1.0 of its Agentic Identity and Access Management guidance. It recommends treating an agent as a first-class identity with its own lifecycle, rather than hiding its activity behind a shared human or service account.

The same document recommends avoiding long-lived, broadly scoped access. Credentials should be short-lived and entitlements bounded by task and context. An agent’s own baseline rights should remain separate from rights delegated by a user or another system.

For multi-hop work, CoSAI recommends narrowing scope at each hand-off and enforcing the decision at the tool, API or data system that ultimately receives the request. It also recommends invalidating downstream delegations when an upstream delegation is revoked.

These are design recommendations, not evidence that organisations have implemented them successfully. They also allow constrained API keys or service accounts in lower-risk legacy cases, with narrow scope, rotation and monitoring. The point is not that every persistent credential is inherently uncontainable. A stable identity and a standing entitlement solve different problems.

Expiry is not the Whole Answer

A five-minute access token sounds temporary. It may not be a meaningful boundary if a refresh token or workload identity can keep obtaining replacements.

OAuth’s token-revocation standard, RFC 7009, makes the dependency explicit. Whether revoking one token also revokes related tokens and the underlying authorisation grant depends on the authorisation server’s policy. The standard also acknowledges that invalidation may take time to propagate between servers.

Multi-system delegation adds another seam. RFC 8693 allows exchanging one token for another suitable for a downstream service. The exchange does not, by itself, create a tight link between the input and output tokens. Propagating a later revocation depends on the implementation, token type, or deployment.

So a short expiry time answers only one question: when does this token stop working? It does not establish whether the holder can renew it, whether a downstream token remains valid, or whether every receiving service has acted on a revocation event.

Final Perspective

I'd want the identity owner to demonstrate a clean ending: the record of which agent acted, for whom and under which policy remains, while that same agent can no longer obtain fresh authority or exercise a delegation at a downstream service.

A short-lived token cannot prove that on its own. The underlying grant, a renewal path or a token issued further along the chain may outlast it, leaving the actor attributable but still able to act.