Every enterprise security team eventually learns the same lesson about service accounts, usually from an incident report. The accounts multiply quietly, one per integration, per script, per vendor, until non-human identities outnumber employees ten to one. Nobody owns them. Their credentials never rotate. Their permissions were scoped generously in 2019 to get it working and never revisited. Then one of them turns up in a breach chain, and suddenly everyone is an expert on least privilege.
We are now minting a new class of non-human identity at a pace that makes service-account sprawl look disciplined: AI agents. Copilots with mailbox access. Automations with CRM write permissions. Coding agents with repository credentials. And in most organizations I talk to, they are being deployed with none of the identity discipline the last decade of incidents taught us, because they arrive through product features and business units rather than through the IAM program.
The property that changes everything: initiative
A service account is dangerous but predictable. It does exactly what a script tells it to, every time. An agent is different in one fundamental way: it decides what to do next. Give it a goal and a set of tools, and it composes its own sequence of actions, including sequences nobody anticipated and no test exercised.
Credentials plus tool access plus initiative is not a cron job. It is a privileged user, one that works at machine speed, never gets suspicious, and can be socially engineered through its inputs by anyone who can get text in front of it. That last part deserves emphasis. Prompt injection means every document, email, and webpage your agent reads is a potential instruction source. An agent's attack surface is its entire input stream.
The governance model, ported from IAM
The good news is that we are not starting from zero. Twenty years of identity governance translate directly, if someone bothers to apply them.
- Inventory first. You cannot govern what you have not found. Every agent gets an entry: owner, purpose, credentials, tool access, data reach. This is the AI asset register, and in most organizations, building it surfaces double-digit agents nobody central knew existed.
- Least privilege by tool, not by account. Do not ask what this agent's account can access. Ask what actions it can invoke, in which contexts. The agent that drafts responses does not need the tool that sends them.
- One write path, gated. Every action that changes state should flow through a single, schema-validated gate that can log, throttle, or deny, never through N ad-hoc integrations. When we built this into our own product, the discipline of a single mutation path did more for safety than any prompt instruction ever did.
- Blast radius before deployment. Define what the agent may do autonomously and what requires human approval, by action type, data class, and dollar value. Pre-approved containment for agents mirrors pre-approved playbooks in the SOC.
- Flight recorder logging. Full tool-call transcripts, retained and searchable. When an agent does something strange, the question of what exactly it did, in what order, prompted by what input, must be answerable in minutes.
- A kill switch someone owns. Credential revocation for an agent should be one action, tested, with a named owner, not a scramble through five vendor consoles during an incident.
Start before the incident does
There is a familiar rhythm to how enterprises adopt identity discipline: sprawl, incident, program. With service accounts, that arc took a decade. With agents, the sprawl phase is compressing into quarters, and the incident phase will arrive on schedule.
The organizations that will skip the painful middle chapter are the ones treating agents as what they are: privileged identities with initiative, subject to the same joiner-mover-leaver lifecycle, access reviews, and monitoring as any human administrator. The playbook exists. It just needs to be applied before the incident report writes itself.