Identity

Your logs can't tell your agents apart. That's the whole problem

Shared keys don't fail all at once. Attribution, rotation, blast radius and access reviews break in turn, and they share one cause. Find your rung.

By Edwin Ashdown6 minute read

In this post 8 sections
  1. You are probably on the ladder already
  2. Rung 1: “Which agent did this?”
  3. Rung 2: “If we rotate this key, what breaks?”
  4. Rung 3: “If one agent is hijacked, what can it reach?”
  5. Rung 4: “Who owns this agent, and does it still need this?”
  6. Where are you?
  7. What one identity per agent looks like
  8. Sources

The first agent got the service account because it was there. The second got a copy of the same key because the first one worked. By the time there are a dozen, the audit log says one thing about all of them: something with that key did this.

I went looking for the point where this stops working. I expected a number, something like “shared credentials are fine up to five agents”. There isn’t one. I found no postmortem, survey or engineering write-up that ties a failure to an agent count. What I found instead were four questions a team eventually gets asked, each set off by an event, and each one harder to answer because of the one before. They all trace back to the same thing: your logs can’t tell your agents apart.

You are probably on the ladder already

How teams credential their first agents is well documented, because it is what the documentation shows. The Claude Agent SDK’s guide to connecting MCP servers says to “pass credentials through environment variables”, and its worked GitHub example uses a personal access token. CrewAI’s tools read keys like SERPER_API_KEY from the process environment. The local GitHub MCP server authenticates with GITHUB_PERSONAL_ACCESS_TOKEN. None of these is wrong for a first agent. None of them gives the second agent a different identity from the first.

The surveys line up. In a Cloud Security Alliance survey commissioned by Aembit (228 respondents, January 2026), 43 per cent of organisations ran agents on shared service accounts and 31 per cent let agents act under a human’s identity. VentureBeat Research (107 enterprises, June 2026) found 69 per cent had credential sharing somewhere in their agent fleet, and only 32 per cent gave every agent its own scoped identity.

OWASP’s Top 10 for Agentic Applications names the consequence in its entry on identity and privilege abuse: without “a distinct, governed identity of its own, an agent operates in an attribution gap that makes enforcing true least privilege impossible.”

Rung 1: “Which agent did this?”

This is usually the first question, and nothing stops it arriving with the second agent. A bug, an odd write in production, a surprise bill.

The warning sign is a log that shows one service account for everything, a person’s name on actions they never took, or a line like “app X made 50k calls today”. GitHub is explicit that actions taken with a personal access token are “associated with a user”. An agent on your token is you, as far as the record is concerned.

Lazar Milicevic described a team with five workloads on one key that spent “two full days bisecting cron schedules to figure out which of their agents was leaking a system prompt into user output.” In the CSA and Aembit survey, 68 per cent could not clearly tell agent activity from human activity.

Rung 2: “If we rotate this key, what breaks?”

The trigger here is a leaked secret, or the person whose token the agents run on leaving the company.

The warning sign is that nobody wants to rotate the key, because rotation has become an outage. One leak or one resignation takes every agent down at once.

This rung is where attribution failure starts costing you. In its write-up of a November 2023 intrusion, Cloudflare explained that one access token and three service account credentials exposed in an earlier compromise at Okta had not been rotated because “mistakenly it was believed they were unused.” The attacker used them. You cannot safely rotate what you cannot see being used. A third of respondents in the CSA survey didn’t know how often their agent credentials were rotated at all.

Rung 3: “If one agent is hijacked, what can it reach?”

This one exists from the first day. Teams just notice it third, because it stays invisible until an incident: a prompt injection, or a compromised third party.

The warning sign is how the newest agent got its access. If the answer is “we gave it the existing key because it already works”, that key now carries the union of every agent’s needs. Seventy-four per cent of the CSA respondents said agents often get more access than they need. VentureBeat found incidents or near misses at 63.5 per cent of organisations that shared credentials, against 40.9 per cent where every agent had its own identity. VentureBeat calls that an association in a small sample, and so should we.

The clearest public case is Salesloft Drift in August 2025. Attackers used stolen OAuth tokens belonging to the Drift chatbot’s Salesforce integration to export data from customer instances between 8 and 18 August, then searched it for more credentials. Cloudflare, one of the victims, wrote that the incident “affected hundreds of organizations through a single integration point” and rotated 104 API tokens that customers had pasted into support cases. Google’s advice to defenders was to review activity “associated with the Drift connection user”. Every action, legitimate or not, sat under one integration identity. Containment meant revoking every Drift token at once, because there was no finer lever.

Rung 4: “Who owns this agent, and does it still need this?”

The trigger is an auditor, a SOC 2 or ISO cycle, a customer security questionnaire, or the review after an incident.

The warning sign is that no agent has a named owner, service accounts are left out of access reviews, and there are agents nobody remembers still holding keys. OWASP’s Non-Human Identities Top 10 asks that every non-human identity has “assigned owners” and is periodically recertified. In the CSA survey, ownership of agent identities was spread across security, engineering, IT and identity teams, with no group holding even a third of it.

A review needs something to attach to. With a shared account you can only review the account, and the account is the sum of everyone’s needs. It will always look justified.

Where are you?

Here is a test that takes ten minutes and needs nothing new. Pick one agent. Using only your logs, try to answer the four questions for it. Which actions were its own last week? What would break if you rotated its credential today? What could it reach if someone hijacked it this afternoon? Who owns it?

Each question you can’t answer is a rung you are standing on. If you can’t answer the first, you won’t be able to answer the others either, because each one depends on knowing which agent did what. That makes the order of the fix obvious. Give each agent its own identity first. Rotation, scoping and review all become possible once the record can tell your agents apart. I made the longer case for why identity has to come first in identity is the control plane for AI agents, and for the key itself in why your AI agent shouldn’t have your API keys.

What one identity per agent looks like

The end state is plain enough to describe. Each agent has its own identity and only the access it was granted, through short-lived, scoped credentials instead of a key copied from the last agent. Risky actions wait for a person. Every call is recorded against the agent that made it and the person it acted for. At that point, revoking one misbehaving agent takes one agent out of service.

That is what I built AgentValet to do. If you want to see your own agent on its own identity, you can try it.

Sources

Filed under

  • identity
  • agent-security
  • credentials
  • non-human-identity

Give your agent only the access it needs

Grant each agent a narrow set of actions, hold the risky ones for your approval, and keep a signed record of every call.

Protect my first agentWatch your agent’s calls live, no signup
All posts

Least agency

The 9 security review questions that keep agents out of production

Your agent works in staging and security keeps sending it back. Nine questions they ask, the weak answers, the strong ones, and the evidence to bring.

7 min read

Incidents

17,000 actions inside Hugging Face: reading an agent breach as a containment problem

An autonomous agent ran more than 17,000 actions inside Hugging Face, harvested stored credentials, and moved across internal clusters over a weekend. Here is the breach stage by stage, and what a governed agent layer changes at each one.

6 min read