Every AI agent an organisation puts into production needs an identity of its own: credentials to call internal APIs, a service account to reach a database, a token to trigger a workflow in another system. Individually, each of these looks like a small provisioning task. Collectively, across dozens of agents and the tools and sub-agents they in turn call, they add up to a population of non-human identities that grows faster than most identity teams are staffed to manage, and behaves differently enough from human accounts that existing IAM processes only partly cover it.
Stop treating agent credentials as an extension of service accounts
Most enterprises already have a service account sprawl problem, and the instinct when standing up an AI agent is to reuse that same pattern: create an account, grant it broad access to be safe, and move on. Agents make this worse than traditional service accounts do, because an agent's behaviour is probabilistic rather than fixed, so the credential it holds is exposed to a wider and less predictable range of actions than a service account built for one integration ever was. Treat every agent identity as its own governed entity from the start, with an owner, a defined purpose, and a review cycle, rather than as a variant of infrastructure you already know how to provision.
This distinction matters most at the point of incident response. When an agent misbehaves or is compromised, the first questions are what it could access and who is accountable for its identity. Organisations that provisioned agent credentials informally frequently cannot answer either question quickly, which turns a contained incident into a much longer investigation.
Scope every agent identity to what the task actually requires
The default failure mode is granting an agent identity the access of the team that built it, because scoping access precisely takes more work than reusing an existing role. Build agent identities around the specific tools and data the agent's task requires, and prefer short-lived, narrowly scoped credentials issued per session over long-lived static keys that sit in configuration for months. Where an agent delegates to sub-agents or external tools, each of those should hold its own scoped identity rather than inheriting the parent agent's full access by default.
This is particularly important for agents that call multiple internal systems, since the combination of access across those systems is often more sensitive than any single grant, even when each individual scope looks reasonable in isolation. Review the combined blast radius of an agent's access, not just each permission on its own.
Build a registry that survives agent proliferation
Identity teams that rely on the same discovery processes built for human joiners and leavers consistently lose track of agent identities, because agents are provisioned by engineering teams outside traditional onboarding workflows and are rarely deprovisioned with the same discipline when a project ends. Stand up a dedicated inventory of agent identities that records what each one is for, what it can access, who owns it, and when it was last reviewed, and make registration a precondition for issuing credentials rather than a step teams are asked to remember afterwards.
Pay close attention to orphaned identities left behind by agents that were retired or superseded. These are consistently among the highest-risk items in an identity estate, since nobody is actively monitoring them, yet their credentials frequently remain valid until someone notices and revokes them.
- Govern every agent identity as its own entity, with an owner and defined purpose, not as a reused service account.
- Scope credentials to the specific task and prefer short-lived, session-issued access over long-lived static keys.
- Give delegated sub-agents and tools their own scoped identities rather than inheriting a parent agent's full access.
- Maintain a live registry of agent identities, tying registration to credential issuance rather than treating it as optional.
- Deprovision agent identities on a fixed schedule tied to project and agent lifecycle, not on an ad hoc basis.
- Review the combined access an agent holds across systems, not only each individual permission in isolation.
Monitor behaviour, not just access grants
A credential that was correctly scoped at provisioning time can still be misused if the agent's behaviour drifts, or if the credential is exfiltrated and used outside the agent's normal pattern of activity. Extend monitoring beyond who has access to what, into what each agent identity is actually doing: which systems it calls, at what volume, and whether that pattern is consistent with its stated purpose. An agent identity making calls it has never made before is a stronger signal than any static access review will surface.
Where possible, correlate this behavioural monitoring with the trace-level observability already being built for agent debugging, so the same instrumentation that helps engineers diagnose a faulty agent also gives security teams a way to detect a compromised one.
Common pitfalls
The most common failure is provisioning agent credentials through the same informal process used for one-off scripts, which skips the ownership and review steps that make an identity governable later. A second is granting broad access at build time with the intention of narrowing it before production, a step that is reliably skipped once the agent is working and the deadline has passed. A third is leaving agent identities active long after the agent itself has been retired, because deprovisioning was never made part of the agent's own lifecycle.
Programmes also stumble when identity governance for agents is owned entirely by engineering teams building the agents, with no independent review from security or identity functions. Build agent identity governance as a shared responsibility from the outset, not as something bolted on once the first serious incident forces the issue.
Agent identities are now a permanent and growing part of the enterprise identity estate, and they need the same rigour, ownership and lifecycle discipline as any other credential with access to production systems. Need support building a non-human identity programme for your AI agents? Email sales@halfteck.com.