Managing API Keys for AI Agents: Rotation, Scanning & Scale

AI agents are joining the pool of things that call your API. Some of that traffic still looks like a developer at a keyboard. Most of it doesn’t. Agents call faster, from more places, and they leave keys in more places too: skill configs, runtime env files, prompt logs, autogenerated repos.

The job of API key management hasn’t changed. You issue a key, validate it on every request, revoke it when something goes wrong. What changes is how much each step costs you when the consumer is an agent instead of a person.

This post covers what Zuplo’s managed API key system does for that traffic, and what it doesn’t.

Agents Are API Consumers, Just Not Like Humans

An agent that authenticates to your API is a consumer. Whatever identity model you use for humans and services works for agents too: a named consumer, a key, and an authenticated identity on every request.

The traffic profile is different. A developer might fetch 20 pages a minute while writing code. An agent orchestrating a multi-step task can hit the same endpoint hundreds of times a minute. That changes what’s acceptable for validation latency, how bad a leaked key gets before you notice, and how hard rotation has to work without breaking a session mid-task.

Four properties of key management start mattering more when your consumers are agents.

Edge Validation Without an Extra Hop

Every agent request needs its key validated. If that validation means a round trip to a central key service, you’ve added a hop to every call. For an agent making hundreds of calls a minute, the latency stacks up fast.

Zuplo validates keys at the edge across 300+ data centers. Keys use a zpka_<random>_<checksum> format, and the gateway verifies the checksum locally with no network call, so typos, truncated copies, and random strings get rejected in microseconds. If the checksum is valid, the edge checks its cache, and only consults the distributed key service if the key isn’t cached. Validated keys cache for a configurable TTL (default 60 seconds).

The policy config to require a valid key on a route is a single block in config/policies.json (or configured via the Zuplo portal):

{
  "name": "my-api-key-inbound-policy",
  "policyType": "api-key-inbound",
  "handler": {
    "export": "ApiKeyInboundPolicy",
    "module": "$import(@zuplo/runtime)",
    "options": {
      "allowUnauthenticatedRequests": false,
      "cacheTtlSeconds": 60
    }
  }
}

Agents send the key the same way any other client does, as a bearer token on the Authorization header. Your backend never sees an unauthenticated request; the edge rejects it first.

The TTL is a latency-versus-propagation knob. Revocations propagate to every edge within seconds, but a key already sitting in an edge’s cache keeps working there until its entry expires. Longer TTL means more requests served from cache and fewer consults to the distributed key service, which suits high-volume agent traffic. Shorter TTL means faster revocation reflection, which suits high-sensitivity APIs.

Keys That Are Scannable by Design

Agent keys end up in more places than human-developer keys: tool manifests, skill packages (the bundled instructions and credentials an agent loads to perform a task), prompt chains, replayed debug transcripts, and autogenerated starter repos committed straight to GitHub.

Zuplo is a GitHub secret scanning partner, and every key Zuplo issues carries a zpka_ prefix with a checksum GitHub’s scanners recognise. If a consumer commits a Zuplo-issued key to a repo GitHub scans, GitHub verifies the checksum and notifies Zuplo. You get the alert via email and in the Zuplo portal. The notification doesn’t include the full key.

That detection path covers the keys you issue. If your agents also hold keys for other providers (OpenAI, Anthropic, AWS), those providers run their own scanning programs for their own prefixes. More on that boundary below. (For the full list of prefix, hashing, and scanning best practices, see API Key Best Practices for 2026.)

Rotation Without Breaking the Session

When a key leaks, the question is how fast you can swap it without breaking whatever’s using it. Agents make this harder: the in-flight session might be mid-task when you rotate, and you don’t want rotation to be the thing that fails the task.

Zuplo’s API Key service exposes a roll-key endpoint that issues a new key for a consumer and optionally sets an expiration on existing keys, giving consumers a transition window. The URL is scoped to an account, a bucket (the top-level group for a given service), and a consumer:

curl -X POST \
  "https://dev.zuplo.com/v1/accounts/$ACCOUNT/key-buckets/$BUCKET/consumers/$CONSUMER/roll-key" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"expiresOn":"2026-04-24T00:00:00.000Z"}'

Calling the endpoint always creates a new key. expiresOn sets the expiration on the old keys; set it to a past date and the old keys revoke immediately. For routine rotation, 24 to 72 hours of overlap is typical; for scheduled rotation in larger operations, 7 to 14 days.

For active abuse, delete the compromised key directly instead of rolling. No transition window, no running sessions allowed to finish. For a deeper look at rotation strategies, overlap windows, and automation patterns, see API Key Rotation and Lifecycle Management.

Zuplo issues the new key and alerts you; how it gets to the consumer is up to your platform. Common patterns: a portal where operators fetch their current key, a webhook your control plane uses to push the update, or a provisioning API your agents poll. The rotation window covers whichever mechanism you use.

Per-Consumer Traceability

When an agent misbehaves, whether a buggy loop, an abusive prompt, or a compromised skill, the first question is “which consumer is this?”. If every agent holds a key tied to a named consumer, that question has a one-line answer.

Zuplo’s consumer model attaches three things to each consumer: a name (the unique identifier within the bucket, exposed to your backend as request.user.sub), metadata (a small JSON blob available at request time), and tags (for management queries). Metadata is where you put what your backend needs for authorization decisions: operator, plan, feature flags, tenant ID, per-model access lists. Tags matter the day “rotate every agent operated by customer X” shows up in your incident channel. If your platform serves multiple tenants that each onboard their own agents, the subaccount API key pattern lets you delegate key provisioning per tenant without exposing your top-level bucket.

Where This Doesn’t Apply

The managed API key system covers one direction of a request, and the other direction gets conflated with it constantly.

Inbound is the key an agent presents to your API. You issue it, the edge validates it, you roll it, and GitHub’s scanners recognise it if it lands in a repo they scan. That is the managed API key system this post has been describing.

Outbound is the credential the gateway presents when it calls something on the agent’s behalf, and the gateway does handle that direction too: a static upstream key read from an encrypted environment variable, a workload identity federation exchange with GCP or AWS so no long-lived cloud key is stored at all, an access token from any OAuth 2.0 client credentials endpoint, a Zuplo-signed JWT your own service validates, or TypeScript you write when the upstream wants something stranger, like a query-string key or a signed request. The cloud policies (GCP, AWS, Azure AD, Zuplo-signed JWT) are Enterprise features in production and free to try in development, and the AWS pair is still in beta. Backends & Resilience has the full set.

The payoff is that the agent stops holding the upstream credential: it presents its gateway key, the gateway attaches the real credential, and there is one copy of that credential instead of one per agent. That takes the credential away from the agent, not the agent’s ability to use it, so what the route allows and what it logs matter as much as the swap.

Storage and lifecycle are still someone else’s job. Zuplo’s only secret store is environment variables: encrypted at rest, write-only, and applied on deploy, so changing a value means redeploying the environment. That is fine for the handful of credentials your own platform owns. It is not a substitute for Vault, AWS Secrets Manager, or Infisical once you are holding a credential per tenant or per end user, or you need audited rotation. If your platform lets agents bring their own OpenAI, Anthropic, or AWS credentials, that is the case those tools exist for, and choosing which one to present per caller is code you write rather than a policy you configure.

Keep three things separate: the keys you issue, which Zuplo manages; the credential the gateway presents upstream, which Zuplo attaches; and the third-party credentials your users hand you, which live in a secrets manager and get read at request time.

Starting Point

If you already issue API keys through Zuplo, your agent consumers inherit the same four properties as everything else on your API. The work is naming consumers meaningfully (one per agent, or one per tenant-agent pair), setting a sensible cacheTtlSeconds, and having a rotation process ready for the day you need it.

If you’re not on Zuplo yet, the entry point is the API key authentication policy: drop it onto a route, create a consumer, and every request is authenticated at the edge before it reaches your backend.