--- title: "Managing API Keys for AI Agents" description: "AI agents are calling your API now. The job of key management hasn't changed, but the scale, leak profile, and rotation windows have. Here's what Zuplo's managed API key system does for agent traffic, and where the boundary is." canonicalUrl: "https://zuplo.com/blog/2026/04/20/managing-api-keys-for-ai-agents" pageType: "blog" date: "2026-04-20" authors: "martyn" tags: "API Key Authentication, AI" image: "https://zuplo.com/og?text=Managing%20API%20Keys%20for%20AI%20Agents" --- 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__` 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): ```json { "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. Assuming a key only leaks through the channels you control. Agent runtimes replay tool-call arguments, error messages, and context windows in places that were never designed for secrets. A scannable key prefix is insurance against all of them. 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. ## 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: ```bash 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; omit it 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. 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 subject (the unique identifier your backend sees), 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. ## Where This Doesn't Apply Zuplo manages the keys you issue to consumers of your API. It doesn't manage the keys those consumers hold for _other_ APIs. If your platform lets agents bring their own OpenAI, Anthropic, or AWS credentials, those belong in a secrets manager (Vault, AWS Secrets Manager, Infisical) with per-agent encryption and provider-specific rotation. A gateway doesn't solve that problem, and any vendor telling you it does is conflating two categories. Keep the boundary clear: keys you issue, Zuplo handles. Third-party keys your users hand you, a secrets vault handles. ## 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.