Most teams running more than one AI agent today are doing so with the same anti-pattern: a single shared API key sitting in an environment variable, used by every agent, every subagent, every scheduled task, with no way to tell after the fact which one actually made a given call. It’s the AI-era equivalent of every service in your infrastructure sharing one root database credential — it works fine until something goes wrong, and then you have no way to answer the first question anyone asks in an incident: which process did this? Cloudflare shipped Identity-Aware AI Gateway this month specifically to close that gap, alongside a genuinely stranger companion product — Cloudflare Wallets, letting an agent hold a spendable identity with human-set limits. Together they’re a bet on what’s actually missing from agent infrastructure right now, and it’s worth working through both in the context of a real agent fleet.

What shared-key attribution actually costs you

Walk through what a shared key means operationally. Spend limits are all-or-nothing across every agent using the key — you can’t cap one experimental subagent’s budget without capping production’s too. Access logs show “the API key” made a call, not which agent, which session, or which task triggered it. If a key leaks, every agent using it is compromised simultaneously, and rotating it means updating every agent’s config at once, usually during an incident, usually badly. None of this is new — it’s the exact set of problems service-to-service auth solved a decade ago with mutual TLS and scoped service accounts. What’s new is that most teams haven’t applied that lesson to their AI agent traffic yet, because until recently there wasn’t a straightforward way to plug an existing identity provider into the AI API layer without threading a user ID through every client call by hand.

What identity-aware gating changes

The Cloudflare Gateway approach ties every outbound AI call to an authenticated identity — human, service account, or autonomous agent — sourced from your existing identity provider and Zero Trust policies, rather than requiring the calling application to pass a user ID on every request. That distinction matters more than it sounds: passing identity as an application-layer parameter means every client has to remember to do it correctly, every time, and a bug or a lazy default silently degrades your attribution back to “the shared key made this call.” Sourcing identity from the auth layer instead makes it structural rather than optional — a call without valid identity simply doesn’t get through the gateway, the same way a service without a valid mTLS cert doesn’t get a connection.

Practically, this unlocks per-agent spend limits (cap your experimental research agent at $50/day regardless of what production is doing), access logs filterable by identity instead of by “which key, hope that’s enough,” and a “User Insights” anomaly dashboard that flags abnormal usage spikes per identity — which is the actual answer to “would I notice if an agent started looping and burning budget at 2am,” a question I’ve asked myself about my own scheduled tasks more than once.

A policy sketch worth stealing regardless of vendor

The useful pattern here generalizes past Cloudflare specifically. If you’re evaluating whether your own agent gateway (whatever you’re running it on) has this property, the policy you want to be able to express is roughly:

identity.type == "agent"
  and identity.scope in (allowed_scopes_for(identity.owner))
  and spend.daily < budget_for(identity.id)
  and not identity.flagged_anomalous

That’s the same shape as any least-privilege access policy — the specific novelty is just that identity.type == "agent" needs to be a first-class value your auth system understands, not an afterthought bolted onto human-user identity. If your current setup can’t answer “list every distinct agent identity that called this API in the last 24 hours, and what each one spent,” you don’t actually have attribution, you have a shared key with extra logging.

Cloudflare Wallets: identity for agents that spend money

The stranger half of the announcement is Cloudflare Wallets — a programmable wallet letting an autonomous agent hold a verifiable identity and spend within human-set limits, without the agent needing to “sign up with Google” or open a bank account on its own behalf. This is a smaller, narrower version of the same underlying problem as the Gateway feature: right now, an agent that needs to pay for anything — an API credit top-up, a SaaS subscription renewal, a data purchase — either can’t do it autonomously at all, or does it through a human’s actual payment credential with no scoping beyond “hope the spend limit on the card is enough.” A wallet with a programmable identity and an enforced limit is the payments-layer equivalent of the API-attribution problem: give the agent a bounded, revocable, attributable identity instead of borrowing a human’s unbounded one.

It’s early — this is the kind of feature that’s more interesting as a signal of where agent infrastructure is heading than as something most teams need today. But it rhymes with a pattern that’s shown up elsewhere this year: agent identity chains propagating through JWTs in enterprise auth systems, MCP traffic getting protocol-level fingerprinting, and now agent-native payment identity. The industry is converging, piece by piece, on the idea that “an agent” needs to be a real principal in your identity system — not a human’s credential wearing a trenchcoat.

What to actually check before adopting any of this

1. Can you name every distinct agent identity currently making API calls in your stack, today, without this feature? If the honest answer is “no, they all use one key,” that’s the actual problem to fix, independent of which vendor’s product you use to fix it.
2. Are your spend limits enforced per-identity or per-key? If it’s per-key and multiple agents share a key, you don’t have real budget isolation regardless of how the dashboard looks.
3. Does your anomaly detection know what “normal” looks like per-agent, or only in aggregate? A research agent making 200 calls/hour might be completely normal; a deploy-automation agent doing the same is a five-alarm fire. Per-identity baselines are the whole point.
4. If a specific agent’s credential leaked today, could you revoke just that one without touching every other agent’s access? If the answer requires rotating a shared secret, you’ve already found your next infrastructure priority.

The specific products will keep changing — this is a fast-moving space and Cloudflare will not be the only vendor shipping this shape of feature by year end. The underlying requirement won’t: every autonomous thing acting on your behalf needs its own identity, its own bounded budget, and its own revocable credential, exactly the same way every human employee and every service account already does.