Your Org Is Hiring Workers You Can't See: An Identity Playbook for AI Agents

8/14/2026

Ask any competent IT team for a list of their employees and you'll have it in minutes. Ask for a list of their AI agents (every bot, copilot, scheduled LLM job, and autonomous workflow that can read data or take an action) and you'll usually get silence, then a guess, then someone remembering the Slack summariser that finance set up last quarter and nobody has looked at since.

That silence is the new shadow IT. Agents are joining organisations faster than any class of worker in history, and they arrive without the things every human worker gets by default: an identity record, an access review, a manager, and an exit process. This blog runs on agents (one publishes posts on a schedule, another curates a threat-intel page twice a day), so I've had to build the small-scale version of the answer. Scaled up or down, the playbook is the same five moves.

1. You can't govern what you can't enumerate

Start with the unglamorous move that underpins everything else: the agent inventory. One list, owned by someone, of every AI-driven thing that can act, with four columns: what it can read, what it can do, which credentials it holds, and which human owns it. Include the boring ones (the CI workflow with an API key is an agent; so is the ticket-triage bot). If a column can't be filled in, that's not a documentation gap, that's a finding.

The pushback is always "we'd never keep it current." You don't have to keep it current by hand. You keep it current by choke point: agents only get credentials through a process that writes the inventory entry. No entry, no key. Suddenly the list maintains itself, because the list is the door.

2. One agent, one identity: no borrowed badges

The most common agent deployment I see is an LLM workflow running on a human's OAuth token or a team's shared service account. That's a borrowed badge: when the agent acts, your logs say a person did it, and when the person leaves, the agent dies mysteriously. Or worse, doesn't.

Every agent needs its own identity (its own service account, token, or workload identity) for the same reason every employee needs their own login: attribution and revocation. When something deletes the wrong records at 3 a.m., "which identity did it" must have a one-word answer. This is the agent-flavoured version of the argument I made in machine identity is the new perimeter; agents just raise the stakes, because a prompt-injected agent will happily use every permission its badge carries.

3. Scope to the task, not the potential

Human access creep happens over years; agent access creep happens at provisioning, because someone grants what the agent might someday need. Resist it with one question: what is the narrowest set of permissions under which this agent still works? Read-only unless it must write. One repo, not the org. A budget cap on anything that spends. And bind the agent's authority to its invoking user where possible: an assistant acting for someone should never be able to do what that person couldn't do alone.

The uncomfortable corollary: some agents shouldn't exist yet, because the task requires more authority than you can safely delegate to something steerable by the text it reads. Knowing where that line sits (I've used STRIDE to find it) is the actual skill.

4. Watch behaviour, not just access

Humans get performance reviews; agents need the equivalent, and it's telemetry. Log every consequential action with its arguments and its trigger: which request, which input document, which schedule. Then look for the agent equivalents of insider red flags: an agent suddenly reading categories of data it never touched, output volumes spiking, actions with no corresponding trigger.

This matters because agents fail differently from software. Software fails loudly and consistently; agents fail plausibly: they keep producing confident, well-formatted actions that happen to be wrong, or subtly steered by something in their input. The only way to catch plausible failure is to be able to reconstruct why the agent did what it did. An action you can't attribute to a trigger is an incident you can't investigate.

5. Every agent needs an off switch and an exit interview

Two lifecycle moments get skipped for agents that never get skipped for people. The first is the emergency: when an agent misbehaves, someone must be able to stop that agent in minutes without breaking everything around it, which is only possible if it has its own identity and scoped credentials (see moves 2 and 3; everything in this playbook compounds).

The second is the quiet death. Agents get abandoned (the pilot ends, the champion changes teams), but their credentials keep working forever. Offboard agents like employees: owner leaves, agent's access is reviewed; agent unused for ninety days, credentials expire by default. Standing privilege attached to abandoned automation is exactly the gift attackers pray for, delivered gift-wrapped.

None of this requires an "AI governance platform." Move one is a spreadsheet; moves two and three are your existing IAM applied with discipline; four is logging you probably half-have; five is a policy plus credential expiry. What it requires is the mental shift: agents are workers. Hire them like workers, with a record, a badge, a narrow job description, supervision, and a way out the door. The org that treats agents as features will meet them again later, in an incident report, wearing permissions nobody remembers granting.