Who governs the AI agent?
For most of my career, identity security has had two kinds of subjects: people and machines. People join, move and leave, and we have mature processes for each step. Machines (service accounts, app registrations, workload identities) were always harder, but at least they did predictable things.
AI agents don't fit either category. An agent can read your email, raise a ticket, query a database and call an API, sometimes in one chain, and the path it takes depends on reasoning we don't fully see. That makes it a new kind of actor in the enterprise, and most organisations are giving these actors access before they've decided who is accountable for them.
If an agent can act, it needs an identity. If it has an identity, someone has to own it.
Why the old models break
Treat an agent like a user and you get interactive sign-in, MFA prompts nobody can answer, and licences assigned to something that isn't a person. Treat it like a traditional service account and you get the problem we've had for twenty years: long-lived secrets, broad standing permissions, and an owner who left the company three reorganisations ago.
Agents also make that old problem worse. A service account usually does one job. An agent has general reasoning, so whatever you grant it, it may find a use for. Over-privilege that used to be latent risk becomes something the agent can actually exercise.
Five questions before any agent goes live
I don't think we need an entirely new discipline. We need to apply identity governance fundamentals with more rigour. These are the questions I'd want answered first:
- Who owns it? Every agent should have a named human owner and a business sponsor, recorded in the same place you track every other identity, and reviewed when either of them moves on.
- Whose authority is it using? Is it acting as itself, or on behalf of a user? Delegated and application permissions carry very different risks, and the answer should be a design decision, not whatever the quick-start guide used.
- What is the least it needs? Scope permissions to the task, not the platform. Prefer just-in-time and time-bound access over standing grants, especially for anything that writes, deletes or sends.
- How does it prove who it is? No secrets in config files. Use managed identities or workload identity federation wherever possible, so there's no credential to leak or forget to rotate.
- Can we see it and stop it? Its actions should be logged as the agent, not blurred into a user's activity. Someone should be able to disable it in minutes, and you should have tested that you can.
A lifecycle, not a launch
The failure I see most often isn't a dramatic breach. It's drift. A pilot agent is created with generous access "just for testing", the pilot succeeds, the agent quietly becomes production, and nobody revisits the permissions. Six months later it's an orphaned, over-privileged identity with a secret that never expires.
| Stage | What good looks like |
|---|---|
| Request | Owner, purpose, data touched and permissions justified up front |
| Build | Managed identity, least privilege, no secrets in code |
| Operate | Agent-attributed logging, anomaly alerts, a tested kill switch |
| Review | Periodic access review like any privileged identity |
| Retire | Disable, revoke credentials and delete, with a record of why |
The leadership question
Ultimately, this isn't a tooling problem. Platforms are adding agent identity features quickly, and that helps. But the hard part is organisational: deciding that agents are in scope for identity governance, giving them owners, and making "who governs this agent?" a question every team can answer before it ships.
The organisations that get this right won't be the ones that slowed AI down. They'll be the ones that gave their agents the same clear identity, ownership and boundaries we already expect of everyone else.