Most organisations first meet AI agents as a product feature: an assistant that can now book, file, query or update on a user's behalf. The conversation that follows is usually about capability and cost. The more important question is quieter. When an agent acts, whose authority is it using, and who could tell if that authority were misused?
Agents are not users and they are not conventional service accounts. They choose their next action at run time, they call tools in sequences nobody wrote in advance, and they can be steered by content they read along the way. That combination places them in a category most identity and access programmes were never designed for.
The gap is already visible
Security practitioners have been documenting this gap throughout 2026. Research published by the Cloud Security Alliance in April described enterprise identity infrastructure that does not account for non-human principals operating at scale, and survey data in which most large-enterprise security leaders reported limited visibility of the identities their AI systems use. IBM's October 2026 study of organisations in Europe and the Middle East found that only a minority described their governance as designed to scale with agentic deployment, and no clear consensus on who is accountable when an agent causes harm.
The pattern behind those figures is familiar. Agents are connected through whatever credential is quickest: a developer's token, a shared integration account, a broadly scoped API key. The agent then inherits every permission attached to it, including the ones its task never needed.
Four questions to settle before an agent goes live
- Who is the agent? Each agent should have its own identity, registered, owned by a named role and distinguishable in logs from the people and systems around it.
- What may it touch? Permissions should be scoped to the task, not to the integration. Read access and write access are separate decisions, and so are reversible and irreversible actions.
- On whose behalf? Where an agent acts for a user, the user's own entitlements should bound what it can do. An agent should never become a route to data the requesting person could not reach directly.
- How is it stopped? There should be a tested way to suspend an agent, revoke its credentials and see what it did, within minutes rather than days.
Least privilege has to be designed into the tools
Much of an agent's real authority lives in its tool definitions. A tool called update_record with no constraints is a general write permission, however carefully the surrounding prompt is phrased. Narrow tools with explicit parameters, server-side validation and hard limits on volume and value do more to contain an agent than any instruction it is given. Where an action cannot be undone, the tool itself should require a confirmation step that sits outside the model's control.
Logging is part of the identity
An agent identity is only useful if its actions can be traced back to it. That means recording which agent acted, under which delegation, with which inputs, and what changed as a result. This record is what allows an organisation to answer an auditor, investigate an incident or simply understand why a workflow produced a surprising outcome. It also has to be designed with privacy and retention obligations in mind, which is a governance decision rather than a technical default.
Where to start
For most organisations the practical first step is an inventory: which agents exist, which credentials they hold and who owns each one. Shadow agents, built quickly by a team to solve a local problem, are common and are usually the most over-privileged. From that inventory, the highest-risk agents can be moved onto dedicated identities with scoped permissions, and the rest brought into the same pattern over time.
None of this requires new categories of technology. It requires applying the discipline organisations already expect for privileged human access to a new kind of actor, and doing so before the number of agents makes it difficult.