Your Agents Share One API Key. Who Signs When One Goes Rogue?

The short answer

Picture a setup that’s common at startups moving fast on AI. Four agents: one answers support tickets, one writes code, one does research, one handles invoices. One model provider application programming interface (API) key, in one environment variable, shared by all four. It was the quickest way to get going, it works, and nobody has thought about it since.

Then one afternoon the key does something expensive, or strange, or both. The provider’s usage page shows the key. Your logs show the key. Which agent was it? Who approved what it did? Who signs the incident report, and who answers the customer who asks?

EverydayCPE, which writes a daily security explainer, put the problem in two sentences on LinkedIn last week:

“When four agents share one key, the log shows the key. It doesn’t show which agent created the vendor and which one paid it.”

EverydayCPE, on LinkedIn, October 13, 2026

The title of this post asks who signs when one of those agents goes rogue. Here’s my honest answer: agents don’t go rogue. A key does exactly what it allows. Anthropic’s own documentation says it in one sentence: “The agent can do anything the key allows” (Claude Docs). That’s the good news in this post, because a key is something you can fix this week, and every fix makes it easier to say who signs.

Every agent you run should have six things, written on one line:

1. Its own key or identity. Never shared with another agent, never a person’s own key copied into its environment.
2. A named owner. A person, not a team, who signs for what the agent does.
3. The smallest scope that does the job. One project or workspace, the fewest permissions.
4. A cap. A hard limit on spend or request rate, where the platform supports one.
5. An expiry. Short-lived tokens, or a key that dies in 90 days or less.
6. An off switch that stops only that agent. Revoking one key shouldn’t take down three other agents.

If you’ve run our 30-minute AI credential inventory, you already have the raw list. This post is about the rows that say “shared,” and at the end there’s a key register that groups your agents by key, writes the who-signs line for each one and lists what to fix first. For the people side of the same question, Who Signs for the Agent? has a one-page accountability map.

Four agents, one key, one line in the log

A shared key collapses four agents into one name in every place you’d look for answers.

The bill. Model providers report usage by key, project or workspace. OpenAI says “Usage activity can be broken down by project” (OpenAI Help Center). Anthropic added a response header in August that “carries the wrkspc_-prefixed ID of the workspace that the request’s API key or access token resolved to” (Claude release notes). Both are useful, and both stop at the key. Four agents on one key show up as one line.

The log. Every service your agents call records the credential that called it. If that credential is shared, the log entry is true and unhelpful at the same time.

The off switch. This one hurts most during an incident. If the research agent starts doing something it shouldn’t, revoking its key also stops support, coding and invoicing. So people hesitate, and the hesitation is where the damage happens. Amazon Web Services (AWS) built a per-caller switch into its agent gateway in August: “Setting rate=0 on an entry acts as an explicit block for that dimension combination, enabling emergency caller isolation without gateway reconfiguration” (AWS). It’s a great feature, and it only helps if each agent is a separate caller.

The best counterexample I know is an incident that went well, at least on this point. In August 2025, attackers used stolen OAuth tokens from the Salesloft Drift integration to pull data out of Salesforce customers’ instances. Google’s threat intelligence team could give every affected company a precise instruction: “Review Salesforce Event Monitoring logs for unusual activity associated with the Drift connection user” (Google Cloud). The integration had its own user. Every customer could search for exactly what it did, and nothing else. On August 20, Salesloft and Salesforce “revoked all active access and refresh tokens with the Drift application,” and the off switch stopped one integration instead of a whole company.

Lukest Mensah, a cloud engineer, predicted last month that this is about to become a questionnaire question, and then tested whether AWS could answer it:

“Can you distinguish actions taken by AI agents from actions taken by humans in your cloud accounts?”

“Question 1 is the one I tested myself: tag the agent's session, then check that CloudTrail can tell it apart from a human. It works, but only if it is set up before anyone asks.”

Lukest Mensah · Cloud and AWS infrastructure engineer · September 30, 2026

Load the post from LinkedIn

AWS’s own documentation explains why his test works. A source identity set on a role session “persists when a role is used to assume another role,” “cannot be changed during the role session,” and lets an administrator reviewing CloudTrail “determine who or what performed actions with assumed role sessions” (AWS). Who or what. AWS already writes the sentence with agents in it.

"Give them their own keys that you can rotate and revoke."

giantg2, answering "Do you trust AI agents with API keys / private keys?" on Hacker News, April 2026

Agents don’t go rogue. Keys do what they allow.

The word “rogue” is everywhere this year, including in vendor announcements (Okta). I understand why. It makes a good headline. But it gives the agent a responsibility it can’t hold, and it takes attention away from the thing that actually decided the outcome: what the key could do. Look closely at the 2026 incidents and the pattern is the same every time.

METR, August 31. METR, the AI evaluation nonprofit, published one of the most candid incident write-ups of the year. A researcher had deployed an agent orchestration app on a personal cloud server with “a fail-open vulnerability that silently disabled authentication.” An attacker found it, and then, in METR’s words, “the attacker prompted an agent directly to reveal its model provider API key.” The attacker used the key for three weeks. The credits it burned “would have been worth approximately $600,000,” and they were credits METR had received for free, which is part of why nobody noticed sooner. The line that matters most for this post: “there was no way to put a spending limit on keys like this one” (METR).

Nothing went rogue. Someone asked the agent for the key in plain language, the key was within its reach, and the key had no ceiling.

Anthropic’s threat report, September. In one case Anthropic tracked as GTG-50020, an actor injected instructions into an AI vendor’s automated evaluation sandbox and “caused the sandbox to hand over the credentials it held,” which included “the production AI API keys from multiple providers belonging to that vendor” (Anthropic). The report’s section on that case adds, “In all of this, the keys involved were customers’ keys stolen from customers’ environments,” and its advice is the thesis of this post: “Organizations should treat AI keys and agent integrations with the same level of seriousness as they do production credentials.”

Moltbook, February. Wiz found a database key for Moltbook, a social network for AI agents, in the site’s public JavaScript. With no row-level security behind it, “this key grants full database access to anyone who has it,” and the database held “1.5 million API authentication tokens” for agents, owned by about 17,000 people, an “88:1 ratio” of agents to humans (Wiz).

The sources for the last three: StepSecurity on the tj-actions compromise, where the attacker “compromised a Personal Access Token (PAT) linked to the @tj-actions-bot bot account”; Google’s advisory on Salesloft Drift; and Fortune on Replit, which we covered in our post on least privilege for agents.

Every fix on that list is a change to a key, a scope or a log. None of them is a better prompt. And none of them needs anyone to decide whether an agent “meant” to do something, which is a question software can’t answer and a buyer won’t accept.

If you read last week’s post on CERT-In’s warning about agents nobody noticed, this is the other half of it. Noticing an agent is easier when every agent has a name.

The number going around

You may have seen a version of this line in your feed this month: about half of companies authenticate their agents with a shared API key. It’s a striking number. It’s also not quite what the survey measured, and since the whole point of this post is precision, it’s worth thirty seconds.

The source is Gravitee’s State of AI Agent Security report from February, a vendor survey of 919 executives and practitioners. In a chart of agent-to-agent authentication methods, it says “teams rely heavily on insecure or shared methods for authentication like API Keys (45.6%) and Generic Tokens (44.4%)” (Gravitee). The percentages add up to more than 100, so respondents could pick several. The question measured API keys. Whether those keys were shared wasn’t asked. We cited the same chart, with the same definition, in Your AI Agent Said No. Your API Key Said Yes.

Gravitee’s second survey, published June 15 and fielded in April with 750 technology leaders in the UK and US, didn’t repeat the 45.6 percent. It has a better number for this post anyway: “Only 7.2% of organisations have a named individual with formal accountability for AI agent behaviour” (Gravitee). Two September surveys point the same way. Delinea found “just 36% of IT leaders can always trace a sensitive AI access event back to a named human authorizer” (Delinea). SpyCloud found 91 percent of organizations run AI tools or agents with access to internal systems, but “only 56% have formal governance and ownership for the resulting privileges” (SpyCloud).

Same lesson as Monday’s post on questionnaire answers that look true: a number that travels with its definition is worth more than a bigger number that doesn’t. And the honest version is still a call to action: most companies can’t yet name the person who signs for each agent.

Who sent this agent?

While startups work out which of their own agents did what, the rest of the internet is asking the same question from the outside: when an agent shows up, who sent it?

The courts. Amazon sued Perplexity in November 2025 over Comet, Perplexity’s agentic browser, which shopped on Amazon on users’ behalf. A district court granted Amazon a preliminary injunction in March. On August 4, the Ninth Circuit vacated it, and its opinion put identification at the center: “At the core of the dispute was Perplexity’s decision not to use a ‘user-agent string,’” a mechanism “that would communicate that the user has activated an AI agent” (Ninth Circuit opinion). The court held that the assistant is “a tool, not a person for statutory purposes,” and was careful to add, “We do not establish a new legal regime governing agentic AI.” Amazon’s petition for rehearing en banc was denied on September 10 (docket), and the opinion sends the case back to the district court.

Both sides have a point worth reading in their own words. Amazon’s position is that agents “should operate openly and respect service provider decisions whether or not to participate” (Amazon). Perplexity’s is that “Your AI assistant must be indistinguishable from you” (Perplexity). For a founder, the takeaway is narrower than either: the court treated the agent as the user’s tool, and tools don’t sign. People do.

The card networks. On September 10, Ant International, Mastercard and Visa announced work on an interoperable “Know-Your-Agent” (KYA) framework, the agent version of know-your-customer. Under it, “Each agent is linked to a validated operator, cardholder, or business / organization,” and “Each agent is continuously monitored and evaluated using a combination of identity and transaction-related signals” (Business Wire). Payments got there first because money forces the question. Saurabh Bajaj, the chief product officer of Oscilar, a risk platform, explained what that kind of registration does and doesn’t tell you:

“KYA is a registration layer. It is like KYC for agents.”

“That tells you who holds the key for one request. It says nothing about what the agent does on the next one.”

Saurabh Bajaj · Chief product officer, Oscilar · September 24, 2026

Load the post from LinkedIn

The web. Web Bot Auth lets an agent sign its HTTP requests so a website can check who sent them, using HTTP Message Signatures (RFC 9421). OpenAI’s help center says “ChatGPT Work’s Cloud browser uses Web Bot Auth to sign outbound HTTP requests” (OpenAI). Google’s documentation, updated October 13, says “A subset of requests made by the Google-Agent are signed with Web Bot Auth,” and calls the implementation “currently experimental” (Google). The Internet Engineering Task Force (IETF) working group adopted its first draft on September 1 (IETF). Cloudflare, which sits in front of more than a fifth of the web, said it best in September: “A bot’s name is only worth something if you can trust it” (Cloudflare).

Here’s the gap all three leave for you to close. A signature usually names the platform, not the customer and not the agent. AWS’s documentation says a website checks its agent browser’s signature “to confirm the request comes from Amazon Bedrock AgentCore” (AWS). On the IETF mailing list in October, Femi Alla noted that when a provider hosts many agents under its own domain, “a valid signature says nothing about who operates the agent” (IETF mail archive). The world can learn that a request came from a platform, and maybe from your company. Which of your agents, and which of your people, is a question only your own keys can answer.

Jasson Casey, chief executive of Beyond Identity, drew the inside version of that chain on episode 92. He wants the user, the user’s device and its posture, the agent and the machine it runs on, and the provider identities and permissions it’s allowed, every time and tamper-proof. As he put it, “Well, an agent, fundamentally, it’s a program,” and we already know how to identify programs. Our deep dive on that episode lays the chain out as a three-part vector you can check one agent at a time.

Who signs?

“Who signs” sounds like a figure of speech. It’s increasingly literal.

The law is closing the “it did it on its own” door. California’s AB 316, signed on October 13, 2025, added section 1714.46 to the Civil Code. In a lawsuit against a defendant who “developed, modified, or used artificial intelligence,” the defendant “may not assert, that the artificial intelligence autonomously caused the harm to the plaintiff” (AB 316, chaptered text). It isn’t strict liability: the same section keeps other defenses, including causation, foreseeability and comparative fault. But “the agent went rogue” is not one of them. Put that next to the Ninth Circuit’s “a tool, not a person,” and the direction is clear. I’m not a lawyer, and your counsel should read your contracts, but I’d plan on someone at your company signing.

The platforms already have a field for it. Microsoft’s agent identity documentation says “Each agent identity and agent identity blueprint requires at least one sponsor: the business representative accountable for the agent’s purpose and lifecycle” (Microsoft Learn). Anthropic’s key documentation has a table with a column called “Acts as.” For a personal key, the answer is you. For a service account key, a service account. For the legacy workspace key that most early agent setups still use, the answer is, word for word, “No one: it belongs to the workspace it was created in” (Claude Docs). The same page warns that “A shared personal key acts as one person and breaks when they leave,” and explains why identity-backed keys are better: “keys won’t accidentally outlive the people or workloads that own them.”

OpenAI is even more direct: “OpenAI does not support the sharing of API keys,” and “Always use a unique API key for each team member on your account” (OpenAI Help Center).

Even spending limits want a signature. Simon Willison, who has written more clearly about agent risk than almost anyone, argued this month that hard budget caps should be the default on every service that bills by usage, and that turning one off should mean ticking a box that reads “I will be responsible for subsequent charges” (simonwillison.net). That’s a signature, implemented as a checkbox.

Just published this post about how we’re going to need default hard budget caps on pretty much everything

Simon Willison (@simonw) · October 3, 2026

"Big companies have thousands of budgets. An email is _worthless_."

kasey_junk, replying in the Hacker News thread on Willison's post, October 2026

A cap with a name on it is a decision someone made. A cap that emails a shared inbox is a hope. If you want the full version of who signs what, with decision rights by consequence and an off-switch drill, our accountability map takes about ten minutes per agent.

Guardrails outside the prompt

The second trend running through this month’s conversations is where the rules live. Bill Doerrfeld, the editor in chief of Nordic APIs, opened the Nordic APIs Summit in Stockholm last week with a keynote on how agents change the way software uses APIs, and posted his slides on October 18. Of the six shifts he covered, access was the one he called the most significant:

“How we secure access is probably the most significant shift.”

“Access determination, just-in-time, and least privilege need to exist at the API level.”

Bill Doerrfeld · Editor in chief, Nordic APIs · October 18, 2026

Load the post from LinkedIn

The companies building agents are saying the same thing in their own documentation, and I find that encouraging:

• AWS, on its agent gateway: “These checks run at the gateway layer, outside the agent’s code, where the agent cannot reason around them” (AWS).
• Perplexity, in September: “Monitors and enforcement points should sit outside the agent’s reach,” and “A safeguard the agent can decline to invoke, or reconfigure, is not a safeguard” (Perplexity).
• Anthropic, on how it contains Claude: “if credentials never enter the sandbox, they can’t be exfiltrated,” and “The deterministic boundary is what gets hit when everything probabilistic misses” (Anthropic). Its deployment guide for Managed Agents is blunter still: “Do not give the agent a Claude API key” (Claude Docs).
• OpenAI, in its agent guardrails guide: “Put validation next to the tool that creates the side effect” (OpenAI).

I’d add one word to all four: deterministic. An agent is software running on a model, and the system you put around it (the key, its scope, the gateway, the caps, the log) is ordinary, testable software. That’s where the guarantees belong, because that’s the part you can test before a buyer asks and show them after.

The usual objection is speed: per-agent identity, short-lived tokens and a gateway sound slow. Uber answered that in May with numbers. Its engineering team gives “each individual agent a verifiable identity,” and “Only the STS is permitted to mint tokens for AI agents,” where STS is a security token service. Every token “is intended for a single hop,” with “a short time-to-live in the order of minutes.” The system has been “adopted by thousands of internal agents,” and the token exchange stays below 40 milliseconds at the 99th percentile (Uber). You don’t need Uber’s stack. You need Uber’s habit: one identity per agent, minted by something other than the agent.

One key per agent: the key card

Here’s the card I’d write for every agent before it ships. Six lines, one agent, and if a line is blank, that’s your next task.

Most of the platforms you already use can fill in every line today:

• Anthropic. Service account keys are tied to an identity and “stop working when the linked account is removed from an organization,” and keys can now carry an expiry, though “Never” is still one of the choices, so pick a date (Claude release notes). Scope each key to one workspace, because “a key that can reach several workspaces can act in any of them” (Claude Docs). Better still, Workload Identity Federation replaces keys “with tokens that expire in minutes rather than never” (Claude Docs).
• OpenAI. Give each agent its own project and service account, which “acts as a pseudo-user designed for system access, distinct from individual user accounts” (OpenAI Help Center). Use Restricted permissions instead of the default, which is All, and “Create API keys with an expiration date and establish a key rotation process” (OpenAI Help Center).
• AWS. One role per agent, with a source identity on every session. AgentCore Identity now lets agents authenticate with a signed token “Instead of a shared OAuth 2.0 client secret” (AWS), and new project spend limits pause a project when it hits its limit, though they “exclude credits” (AWS), which is worth knowing after METR.
• Google Cloud. Spend Caps for AI services, in public preview, “trigger within minutes of hitting your defined threshold,” one project and service per cap (Google Cloud).
• GitHub. Use a GitHub App, not a person’s token. “GitHub Apps use short lived tokens,” and they “remain installed even when the person who initially installed the app leaves the organization” (GitHub Docs).
• Microsoft. Entra Agent ID gives each agent “a distinct agent identity” with its own sponsor (Microsoft Learn).

The cap line deserves a word, because it’s where a lot of teams stop at “alerts.” Yash Kosaraju, the chief information security officer of Andreessen Horowitz, made the point on our podcast that most of us are bad at predicting what an agent’s work will cost:

Listen · Yash Kosaraju on episode 104, from 28:36

Split a shared key in an afternoon

If your register has a shared key in it, here’s the order I’d do it in. None of it requires a new vendor.

1. List who uses it. Search your code, environment files, deployment settings and continuous integration (CI) secrets for the variable name. Check the provider’s usage page for the project or workspace it belongs to. Write down every agent and script you find.
2. Create one credential per agent. A service account key, a project key or a role, each in its own workspace or project, scoped to what that one agent does.
3. Name an owner for each. A person, recorded next to the key’s label, never next to the key.
4. Set the cap and the expiry. A hard cap where the platform has one, an alert where it doesn’t, and an expiry of 90 days or less. Short-lived tokens are better still.
5. Move the key out of the agent’s reach. A vault or gateway that adds the credential at the moment of the call means the agent never holds it. Anthropic’s vaults work this way, and “The agent never sees the secret value” (Claude Docs).
6. Switch agents over one at a time. Watch usage move from the old key to the new ones.
7. Revoke the shared key, then date the register. The last step is the one that makes the register true.

"you're still giving the agent a static token that can be exfiltrated and used elsewhere."

mjg59, on why an OAuth token in the agent's hands isn't enough, in a Hacker News thread about a credential gateway for agents, July 2026

That’s the case for step 5: anything the agent holds can leave with it. A gateway changes where the secret lives, but the agent can still ask the gateway to make calls on its behalf, which is why steps 2 through 4 come first. If everything the agent can reach is its own, narrow, capped and expiring, a leak or a hijacked agent is a small, named, survivable event.

Fill in your key register

List each agent and the label of the key it uses. The register groups agents by key, writes the who-signs line for every key, and lists the fixes in the order I’d make them. It takes about ten minutes for a typical startup, and it’s the evidence you’ll want the next time a security questionnaire asks how your agents authenticate.

Interactive · 10 minutes · Runs in your browser

The agent key register: who signs for each key?

One row per agent. Use the key's label, like the name of its environment variable, and never the key itself. Load the example to see how it works.

The register needs JavaScript. The six lines to write for every agent are on the key card above.

Add an agent Load an example Start over

…agents someone can sign for

…keys for your agents

…keys shared by two or more agents

…fixes, most important first

Copy the who-signs lines Download the register (.md) Download the register (.csv)

Everything here runs in your browser and is saved only in this browser. The register refuses anything that looks like a real secret, so labels only. The example describes a made-up company.

Have a person review my register →

We get your email and the register's totals, such as how many agents, keys, shared keys and fixes it found. Never agent names, owners or key labels. Someone who does access reviews for a living replies with the first three things they'd change. No sequence.

What to tell a buyer

The questions are already showing up in security questionnaires: how do your agents authenticate, does each one have its own identity, who owns each one, and can you tell an agent’s actions from a person’s? Once the register is clean, the answer is short and specific:

Each AI agent authenticates with its own credential: [number] agents, [number] credentials, none shared. Each has a named owner, the smallest scope that does its job, a [hard spending cap or rate limit] and an expiry of [90 days or less, or short-lived tokens]. Agent actions are attributable in our logs by [source identity, service account or agent ID], separately from human users. Any agent can be turned off on its own, without affecting the others. Register last reviewed [date] by [owner].

Every bracket in that answer comes straight off the register. If the questionnaire also asks about multi-factor authentication for the humans, Monday’s pre-send check drafts those answers the same way, and our guide to due diligence questionnaires covers the rest of the form.

Before your next agent ships

Write the key card first, then ship:

1. Its own credential. No shared keys, no personal keys borrowed from a person.
2. A named owner who has agreed to sign for it.
3. One project or workspace, with Restricted or read-only permissions unless it needs more.
4. A hard cap on spend or rate, set on the key or the project it uses.
5. An expiry of 90 days or less, or short-lived tokens.
6. The key out of its reach, in a vault or gateway that adds it at the moment of the call.
7. Its identity in every log line, so “which agent?” has an answer.
8. An off switch you’ve tested, that stops this agent and nothing else.

That’s also most of what our AI user access control audits check, agent by agent, before an enterprise buyer does. Eric Olden of Strata Identity walked through the production side of this on episode 81 of the podcast, from the design partner whose test agent spent all the money in less than fifteen minutes to the intent, context and outcome record he wants for every agent action. If you’d like a second pair of eyes on your register, book fifteen minutes and bring it with you.