Give Every AI Agent Its Own Badge

Picture a Monday review. A customer’s billing address changed on Friday night, and the customer says they never asked for it. The log has an answer: Priya in finance made the change at 9:47 p.m.

Priya says she was at dinner. (Priya is invented, and so is the scene, but the question it ends on is a real one.)

Then Priya remembers. Two months ago her team set up an AI agent to tidy customer records, and the quickest way to get it running was to let it use her login.

The agent was doing its job, and the log can’t say so. It also can’t say whether the agent was right to make that change. And stopping the agent may mean locking Priya out of her own account.

When an AI agent works through a person’s login, the log may not be able to tell which of them acted, and when that login is the only lever, shutting the agent off can mean shutting the person off. Give the agent its own identity, where the system lets you, and you can get two things back: an answer to “who did this,” and an off switch for that one agent that leaves Priya’s account alone.

Why a borrowed login is an agent problem

An identity is the name a system knows you by. Every action inside a system gets logged under one, which is why the log said Priya.

Letting software run under a person’s login is a familiar shortcut. An agent changes what the shortcut costs.

NIST describes agents as systems “that have the capability for autonomous decision-making and taking action with limited human supervision to achieve complex goals,” and says the scale and range of their actions “has the potential to increase exponentially.” When such a system runs on a person’s login, the access it holds was sized for that person’s role, not for the agent.

One survey puts a number on the borrowing. The Cloud Security Alliance, a nonprofit, surveyed 228 IT and security professionals in January 2026. Aembit, a company that sells identity software for agents, commissioned and paid for the survey and helped write the questions, so read the numbers as a vendor-funded sample of people who work in this area.

In the survey, 31% of respondents said their organization allows agents to operate under human user identities, and 43% said it relies on shared service accounts, which are logins that belong to software and to no single person.

Another 52% said theirs uses what the report calls workload identities, which are identities issued to a piece of software. The shares add up to more than 100%, so some organizations use more than one kind. And 68% said their organization “can’t clearly distinguish between human and AI agent activity.”

EY looked at a related problem. It surveyed 202 senior AI decision-makers at US public companies with at least $1 billion in annual revenue and published the results on September 15, 2026.

About a quarter, 26% of those whose organization uses agentic AI, said their organization cannot detect unauthorized AI agents operating internally. EY reports what executives told it, not a measured test, and the margin of error for the whole sample is plus or minus 7 points, wider for a subgroup like this one.

The US government’s standards body treats agent identity as an open question. In February 2026, the National Cybersecurity Center of Excellence at NIST published a draft concept paper on agent identity and asked the public for comment on a possible demonstration project. It’s a request for input, not guidance.

Among the areas the project would explore are linking agent actions “to the identity of the non-human entity,” and linking specific user identities to agents “to support effective delegation controls and maintain accountability.”

The three describe a gap. What follows closes the part of it you can check yourself.

What a separate badge gives you

Think of a badge. If a contractor borrows an employee’s badge, the door log records the employee, and taking the badge back means the employee can’t get in either. If the contractor has a badge of their own, the log names the contractor, and you can cancel it without bothering anyone else.

An agent with its own identity works the same way. The log names the agent, so you can tell its actions from a person’s, and you can switch off one agent without touching a person. The register adds two more: a named owner who answers for the agent, and access that lapses on a date unless the owner renews it.

The register that holds all this takes five steps to build. Run them on one workflow that touches customer or financial data, because that’s where an unanswered “who did this” is hardest to live with.

Five steps, in this order

1. List the agents in the workflow, and whose login each one uses

Write one line per agent: what it does, and which of three things it logs in as. Its own identity, a shared account, or a person’s login.

You won’t find them all by asking one person.

Ask IT for the accounts in that workflow that aren’t people. Ask each team lead which tools in the workflow have an “assistant” or “agent” feature switched on. And ask the person who set up the workflow what runs without them.

Step 1 comes first because nothing else can be judged until you know whose badge each agent wears.

The question: for each agent in this workflow, whose name is on its actions?

2. Run the attribution test on one logged action

Take one action you know the agent took last week, a record it changed or an invoice it sent. The agent tool’s own run history usually shows one. Then find that action in the log and say from the log alone whether it shows a person or the agent.

If the log shows a person’s name or a shared account’s, or you can only tell by asking or by the time of day, that agent fails.

It’s a spot check, and one action can’t tell you the rest are fine. What it does is turn step 1 into something you can feel, and it sorts the list. The agents that fail go first.

The question: from the log alone, who did this?

3. Give each failing agent its own identity, an owner and an expiry date

The identity comes from IT. The agent gets its own login, in a name the log will show as the agent, such as “invoice-agent” instead of a person’s.

The owner is a person who answers for the agent: who gets called when it does something odd, and who decides what it may do. It should be someone close to the work. For the wider question of who manages agents day to day, see Already On Your Payroll.

The expiry date is a day after which the agent’s access lapses unless the owner renews it. Pick a date and put it in the register, and a quarter is a reasonable start (that figure is ours, not from any of the sources).

Ask IT to set the login to expire on that date, or the date is only a reminder. It’s only as good as the renewal habit, but an agent nobody renews is one nobody was watching, and the lapse tells you so.

These come as a set because identity, owner and expiry together are what keep the register true after the first week.

The question: if this agent does something unexpected tomorrow, whose phone rings?

4. Write down what it may touch, and make its actions readable under its own name

Start from nothing and add what this workflow needs. Write the list down next to the agent’s name, with the systems it may log into, send to or change. How to block everything else is covered in Build the Stop Outside the Agent, so this step only records the list.

Then check that the agent’s actions show up in the log under its own identity, and that its owner can read them. NIST’s draft lists the same thing as an area to explore, actions linked to the agent’s identity so there’s “effective visibility into the actions taken, data generated, and outcomes.”

Step 4 follows because it needs the identity from step 3.

The question: can the owner see, without asking IT, what this agent did yesterday?

5. Switch one agent off, and watch what happens

Pick one agent with its own identity and disable it, in a quiet hour, with its owner watching. Then check two things:

• The person who used to share its login still works normally.
• IT tries the agent’s own login on a system on its step 4 list, and it no longer works.

Step 5 is last because it needs steps 3 and 4, and because it’s the proof.

In the Cloud Security Alliance survey, the most common containment actions were disabling identities or revoking tokens, at 49% of respondents, and 42% reported terminating the compute environment where an agent runs. Our reading, not the survey’s: disabling an identity is the targeted option, and it needs the agent to have an identity of its own. Terminating the environment stops the agent whatever login it used, along with anything else running there.

The question: if we had to switch this agent off right now, what else would stop working?

The register, one row per agent

When the five steps are done, each agent in the workflow has one row with six fields:

• Its own identity
• A named owner
• An expiry date
• What it may touch
• Where its actions are logged, and who can read them
• The date its off switch was last tested

Keep this page. It’s short enough to fit on one page, and a month from now it tells you which agents are current and which ones nobody has looked at.

Where this stops being honest

The list in step 1 holds only the agents someone knows about. EY’s 26% is about unauthorized agents a company can’t detect, so the register is a start, not a way to detect strays.

Step 5 shows that the agent’s identity can be switched off. It can’t show that no copy of its keys lives somewhere else.

And a bought agent that runs inside a vendor’s software may not let you give it an identity at all. If so, the register records that as the finding.

The three sources describe three different things: large US public companies (EY), a vendor-funded sample of 228 IT and security people (the Cloud Security Alliance), and a draft request for comment (NIST). EY’s companies each have at least $1 billion in annual revenue, far larger than the companies this article is written for, and none of the three shows that separate identities reduce incidents.

The claim here is narrower, and you can check it yourself. For each agent you give its own identity, you can tell which actions were its own, and you can switch it off without touching a person.

This week

Pick one workflow that touches customer or financial data. Do steps 1 and 2 first, before anyone changes anything. When the attribution test comes back, you’ll know how many agents in that workflow need a badge, and which ones to start with.

An actor inside your systems should have a name of its own on the record. People do, and for some agents today the name on the record is still a person’s.