March 7, 2026 • Marcus Chen, Head of Security Research
A 90-day API key rotation policy made sense when the consumer was a developer who checked a key into a config file, used it for three months, and then ran a manual rotation script. It makes no sense for an AI agent that might make ten thousand API calls in a single hour and then terminate forever. The threat model is different. The credential lifetime should match.
Long-lived credentials create a window of exposure. If a key is valid for 90 days and it is leaked on day one, the attacker has 89 days of authenticated access before anyone notices. In practice, detection often takes weeks or months, meaning the effective exposure window can be the full credential lifetime.
AI agent pipelines make this problem worse in three ways. First, the attack surface is larger: every agent instance that loads the credential is a potential leak point. A pipeline running 200 concurrent agents each hour creates 200 memory contexts that could be dumped. Second, agents often call external APIs that log request headers, meaning the credential may be present in third-party logs you do not control. Third, agents may write their configuration to shared storage or caches that persist longer than the agent itself.
For most agent workloads, the right credential lifetime is the expected lifetime of the agent itself — plus a small grace period for shutdown. If your agents run for an average of 4 minutes, issue credentials valid for 10 minutes. If you run long-running agents that persist for hours, issue credentials with 2-hour lifetimes and implement a refresh mechanism that the agent uses before the credential expires.
This approach, sometimes called SPIFFE/SVID-style identity in the service mesh world, treats credentials as temporary assertions rather than long-lived secrets. The identity authority (not the agent) controls when a credential is issued and when it expires. Credential theft becomes much less valuable: the attacker has a key that is valid for 10 minutes, by which time the agent has already terminated.
The obvious objection is scale. If you issue a new credential per agent instance, and you run 500 agents per minute, your credential issuance system needs to handle 500 cryptographic operations per minute. That is not demanding by modern standards — a single instance of HashiCorp Vault handles tens of thousands of operations per second — but it does require the identity infrastructure to be sized and operated as a production dependency, not as an afterthought.
The Riptides architecture handles this by embedding credential issuance into the agent spawn event. The orchestrator calls a single Riptides API endpoint as part of starting the agent. The response includes the short-lived credential, the policy scope, and the expiry timestamp. The agent never touches a long-lived secret store. There is no separate secrets-fetch step that can fail or be bypassed.
A common intermediate step is to give each agent type a distinct credential, rather than a per-instance credential. This is better than a single shared key for all agents, but it still leaves the "lateral movement" problem open. If the credential for the "document-processing agent" type is compromised, every instance of that agent type is affected simultaneously.
Per-instance credentials mean that a leaked credential from one agent instance has a blast radius of exactly one agent's remaining lifetime. The compromise is contained by construction, without requiring any detection or incident response action. The credential expires on schedule regardless of whether anyone noticed the leak.
The harder problem is credentials for external services that do not support short-lived tokens. Your agents may call OpenAI, Anthropic, Stripe, or Salesforce, all of which issue long-lived API keys. You cannot control the lifetime of these credentials.
The solution is to proxy these credentials through a credential broker rather than giving them directly to agents. The agent requests a scoped token from the broker, which issues a token valid for one request or one session. The broker holds the long-lived third-party key and is the only component that ever presents it to the external service. The agent never sees the real key — it sees a proxy token that the broker exchanges for the real credential at request time.
Rotating the underlying third-party key then becomes a broker operation, completely transparent to the agents. A breach of the agent layer does not expose the long-lived third-party keys because the agents never had them. That isolation is worth the additional architectural complexity.
Marcus Chen leads security research at Riptides. Questions: hello@riptidesio.com