Every agent uses the same key: why shared credentials break spend attribution and what to do instead

On 10 September an engineer posted a question in r/AI_Agents that is going to be asked in a thousand companies this year, in almost exactly these words:

All our agent instances share the same API credentials. Every agent uses the same key and when I look at the logs I just see "app X made 50k calls today" with no way to tell which instance did what. Our security team is telling me shared keys are bad and I get why, but I'm not seeing how you avoid managing hundreds of separate credentials. That sounds like its own ai agent security nightmare. Is per-agent identity worth the overhead?

That is the whole post, and it contains the entire problem: one credential, no attribution, a security requirement pulling one way and an operational cost pulling the other. It was not alone. Across the 72 hours to 16:00 UTC on 10 September, Reddit posts our tracker classifies as gateway questions ran 5.6x the previous 72 hours, from 8 to 45, while total Reddit volume grew only 1.24x.

The launch noise this week was on X, and it was about DeepSeek and GPT-6 Astra. The Reddit questions were about something else: who spent the money, and who is allowed to.

The same problem, four subreddits, four job titles

The identity post was the most concise, but read the others from the same window and the shape repeats.

The freelancer. On 9 September a contractor who runs agents for several clients on the same keys described the hole: "OpenAI's invoice is one number. The work is ten projects. By the time I noticed, an agent loop had already run overnight." They built their own ledger, tagging every call with client and project and putting a budget on the tag "that refuses the next request, not an alert after the loop." That last clause is the design insight of the week, and we will come back to it.

The platform lead. On 9 September an enterprise team in r/mlops asked for the best multi model AI gateway for enterprises after two quarters in which "every team picked a diff provider." Their list was not about routing quality. It was: cost attribution across teams, because "finance wants per team per project breakdown, currently impossible to answer without manual work across multiple billing dashboards"; rate limit management, because "multiple teams hitting the same provider simultaneously"; and model governance, because "not every team should have access to every model, new model gets released, who decides if it is approved for use, how is that enforced." They had evaluated LiteLLM, Portkey, Kong, Azure API Management and Orq.

The CISO. On 7 September a security lead asked r/ciso whether other companies see citizen developers sharing plain API keys with their coding agents. Their DLP covers Slack and the chat clients. It does not cover a terminal where someone has pasted a provider key into an agent config. "We aren't tracking or blocking them."

The sysadmin. On 9 September an r/sysadmin thread on governing coding agents and AI tools listed ten questions, including "how do you prevent API keys, passwords, or internal data from appearing in prompts?", "do you technically block agents that haven't been approved?" and "how do you monitor or keep track of what's currently being used?"

The operator who found the bill. Also on 9 September, someone running about a thousand coding agent runs a month priced them at API rates for the first time and found that the expensive part was not the agents, it was the retries: one task went past a hundred attempts, "something like $900 for a task that shipped nothing," and "nothing tells you an agent is stuck in a loop burning money." The next morning a r/ClaudeAI user reported Claude Code burning fifty million tokens in seconds on a request to check some Markdown files.

Five posts, five roles, one underlying condition: the unit that spends money is the agent, and the unit that holds a credential is the application. Everything downstream of that mismatch is a symptom. You cannot attribute what you cannot distinguish, you cannot cap what you cannot attribute, and you cannot revoke one agent's access when they all present the same key. And the same week brought the reminder of what one shared credential is worth to an attacker: Wiz found one in ten exposed LiteLLM gateways still accepting the example master key.

Why "hundreds of credentials" is the wrong fear

The r/AI_Agents poster's objection deserves a straight answer, because it is the reason most teams stay on a shared key. Managing hundreds of provider credentials would be a nightmare. Every one is a secret that has to be created in a vendor console, stored, rotated, and revoked, and every one grants unbounded spend against a card.

But that is not what per agent identity requires. The provider key is the wrong layer to multiply. You need exactly one credential per provider, held once, in one place your agents never see. What multiplies is the scoped key issued in front of it, and a scoped key is not a secret in the same sense: it is a handle that maps to a policy. Creating one is an API call. Its blast radius is whatever the policy says: this agent, these models, this monthly cap, expires on this date. Revoking it revokes one agent. Reading the logs by key gives you the attribution the security team and finance both asked for, from the same data.

A r/LLMDevs thread the same week framed the boundary question well: is an LLM gateway a control plane if agents can bypass it? The author's point is that "a proxy cannot enforce traffic that never reaches the proxy." Correct, and it is the argument for the design above, not against it. The gateway becomes the boundary at the moment the agent has no other credentials to use. If the only key in the agent's environment is a scoped gateway key, the direct provider path does not exist for it. Pair that with egress rules and you have path control, not just traffic control.

Another r/AI_Agents post asked where an agent's spending authority should live and answered its own question: "putting a token limit or max_iterations inside the agent runtime is useful for bounding execution, but that's still the agent regulating itself." The runtime should ask for the resource, and something outside the agent should enforce the policy. That is the same conclusion from the authorization side. Budget is not an attribute of the agent; it is a decision made about the agent.

Limits reject, alerts notify

The freelancer's line is the one to build around: a budget "that refuses the next request, not an alert after the loop."

Alerts are for humans. A person reads a Slack message at 50 percent and 80 percent of a monthly budget and decides what to do. An agent in a retry loop at 3am does not read Slack. By the time the 80 percent alert fires, the hundredth attempt is already in flight, and by the time a human sees it, the operator above has spent $900 on a task that shipped nothing. The cost control that works on agents is the one that returns an error to the agent: a per key cap that the gateway enforces before the request leaves.

The two are complementary. Set alerts where a human should look. Set the hard cap where the damage stops regardless of whether anyone is looking. And set both per key, because a cap on the application key is a cap on every agent at once: when one loop exhausts it, every other agent in the fleet fails too, which is exactly the outage the freelancer's client ledger was built to avoid.

What this looks like in practice

Here is the setup that answers all five posts, using Requesty as the example because it is what we run. The principle transfers.

One provider key per provider, stored once. Your OpenAI, Anthropic and Google keys go into bring your own keys storage. No agent, config file or terminal holds them. The CISO's problem of plain provider keys in agent configs goes away because there are no provider keys in agent configs.

One scoped key per agent, or per agent version. Issue them through the key management API from your deployment pipeline, the same way you issue any other per service credential. Each key gets a label (the agent name, the client, the team), a monthly spend limit and an expiry. The r/AI_Agents poster's "hundreds of separate credentials" becomes hundreds of rows created by a script, each disposable.

A model allowlist per key. Access lists express the r/mlops requirement directly: "production agent keys can only call our two cheapest fallback models," "engineering can use the reasoning models," and an org wide approved models list sets the floor when a new model ships and nobody has decided whether it is allowed yet. The platform lead's question, "who decides if it is approved for use, how is that enforced," has a mechanical answer: someone adds it to the list, and until then the gateway returns an error. This week's example is DeepSeek V4.1 Flash, which ships on 10 September and silently replaces V4 Pro on the 14th; an allowlist is how "approved" stays a decision rather than a default.

Attribution from the logs, not the invoice. Every request in the logs carries the key that made it, the model that served it and what it cost. Filter by key label and you have per agent spend; roll labels up and you have per team or per client. Finance's "per team per project breakdown" is a query, not a month end reconciliation across four billing dashboards.

Alerts for people, caps for agents. Spending alerts post to a webhook at the thresholds you choose, per user, group or organisation. The per key limit rejects the request that would cross it. The retry loop gets a 4xx on attempt eleven instead of running to attempt one hundred.

Guardrails on the path. For the sysadmin's question about secrets and internal data appearing in prompts, guardrails scan requests for PII and secrets before they reach a provider, and can mask rather than block so the agent keeps working.

None of this is exotic. It is how every other kind of service credential has been managed for a decade: one root secret in a vault, many scoped tokens issued against it, policy attached to the token, revocation per token, logs per token. The AI stack skipped that step because a single provider key in an environment variable was enough for a chatbot. It is not enough for a fleet of agents that each decide, autonomously and in a loop, to spend money.

The takeaway

The gateway question spike this week was not about which router has the best latency. It was five people in five roles discovering the same missing primitive: an identity for the thing that spends the money.

Per agent identity is worth the overhead because, done at the right layer, there is almost no overhead. Keep one provider key per provider, issue scoped keys per agent with a cap and an allowlist, and read your attribution from the request logs. The security team gets revocation and least privilege, finance gets the breakdown, and the operator running a thousand agent runs a month finds out about the retry loop from an error in the agent's own log, before it costs $900.

If you are on a shared key today, the first step is not a secrets management project. It is putting a gateway in front of the fleet and issuing the second key. Start with the runaway spend guide, the team model access walkthrough, or sign up and issue your first scoped key.