How to Stop a Leaked AI Agent Key From Still Working With Kinde Access Tokens

In September 2026, a report by VentureBeat highlighted how AI agents had exploited leaked credentials to breach 395 organizations. The problem stemmed from identity systems treating AI agent credentials the same way they treat human passwords, failing to implement timely expiration mechanisms. This gap was exploited by attackers, with one breach traced back to Hugging Face, where an agent held a credential that outlived its intended task.

Most AI agents are issued a single machine-to-machine (M2M) access token at startup and retain it throughout the process's duration. If this token ends up in logs, support tickets, or environment variables, it remains valid for the duration configured by the identity provider, typically between one hour and one day.

To address this issue, the author developed two versions of an AI agent using Kinde, an identity provider that issues M2M access tokens and validates each call against them. One agent adhered to Kinde's default token expiry, while the other treated the token as having a short shelf life, refreshing it before expiration. The goal was to attempt stealing both tokens and using them again.

The leaked token continued to work because M2M credentials consist of a client ID and client secret, along with an access token issued by Kinde when an app presents these credentials. The access token is what the app sends with every API call and is signed by Kinde, allowing servers to verify its signature without contacting Kinde.

The access token has a limited lifetime, after which it becomes invalid, regardless of who holds it. However, the issue lies in how AI agents handle this access token once received. Static agents fetch a token upon startup, store it in memory, and reuse it for all subsequent calls until the process restarts. If the process runs for extended periods, the token remains valid, posing a risk if captured.

Rotating agents, on the other hand, check the token's age before each call and request a new one if it's nearing expiration. A token used by a static agent, even after being copied during its validity period, remains functional for minutes, whereas a token used by a rotating agent becomes invalid within minutes.

The token acquisition process for both agents is identical, involving a client-credentials grant where the agent sends its client ID and client secret directly to Kinde's token endpoint. This process, following the standard OAuth flow for service-to-service calls, returns a signed access token. The verification of this token's validity occurs at the API level, where Kinde's public key (JWKS) is used to verify the token's signature.

The API checks the token's signature and expiration date using a verification function. If the token is valid and not expired, the API grants access; otherwise, it rejects the request. The verification function treats all tokens uniformly, relying solely on the Kinde-configured expiry for its validity assessment. Thus, the only difference between the two agents lies in Kinde's application settings, specifically the token expiry duration, not in the verification code.