AI agent identity is outgrowing service account governance

At a glance

What this is: This analysis argues that AI agent identity cannot be governed as static NHI alone because agents inherit, chain, and delegate access at runtime.

Why it matters: IAM, IGA, PAM, and NHI teams need a governance model that covers ownership, delegation, and runtime behaviour before agent sprawl turns into uncontrolled access.

By the numbers:

• Companies we work with typically discover 10 to 100 times more of these agents than they expected.

👉 Read Noma Security's analysis of AI agent identity and access control

Context

AI agent identity is the governance problem created when software can inherit access, choose tools, and take action on behalf of a user at runtime. The article argues that treating these systems as ordinary service accounts or API keys only covers a narrow slice of the risk, because the real control failure is not static access but changing delegation, chained actions, and unclear accountability.

That distinction matters for identity programmes because the same access model does not fit homegrown agents, SaaS agent builders, and developer copilots. Each of those environments creates different blast radius, owner, and delegation problems, but they all break the assumption that non-human access stays fixed long enough to be reviewed, scoped, and certified in the usual way.

Key questions

Q: How should security teams govern AI tools that inherit user permissions on endpoints?

A: Treat each OAuth-connected assistant, plug-in, or local model as a non-human identity with delegated authority. Map what it can read, change, or trigger, then bind it to ownership, review, and revocation controls. If the tool can act on behalf of a user, it belongs in the same governance cycle as other privileged access, not in an informal exception path.

Q: Why do AI agents create more identity risk than ordinary SaaS integrations?

A: AI agents can operate continuously, chain multiple tools, and act on delegated permissions with little human oversight. That makes their effective privilege broader than the original approval suggests. The risk is not only access, but the speed and persistence with which the agent can turn access into credential exposure or lateral movement.

Q: What breaks when agent access is approved but never monitored at runtime?

A: A registry can confirm that access was allowed, but it cannot show whether the session used that access safely. Without runtime monitoring, a sequence of ordinary actions can become data movement, privilege abuse, or uncontrolled delegation. The control failure is blind trust in the approved state after the session begins.

Q: How can organisations reduce risk from shadow AI agents already inside the enterprise?

A: Organisations should combine continuous scanning, access reduction, and credential revalidation for any agent found outside formal governance. The priority is to move unknown agents into a managed state, then decide whether they are sanctioned, constrained, or removed. That sequence is more effective than waiting for a full platform redesign.

Technical breakdown

Why AI agent identity is not the same as service account governance

Service accounts are deterministic. They authenticate a workload, call a known system, and usually stay within a stable purpose. AI agents are different because their runtime behaviour can vary by prompt, context, tool availability, and prior session state. That means the identity boundary is not just authentication, but also decision sequence, delegation chain, and tool selection. A static access model can describe who issued the credentials, but it cannot fully describe what the agent will do with them once the session starts. For identity teams, the technical problem is that the same credential can produce different operational outcomes depending on the agent’s instructions and connected tools.

Practical implication: classify AI agents separately from ordinary service accounts and map their runtime decision paths before granting access.

How maker identity and OAuth delegation create hidden privilege expansion

The article’s Maker’s Identity problem shows how delegated access can silently expand when the agent runs under the builder’s permissions instead of the current user’s. OAuth can scope delegated access correctly, but in practice the scope is often broader than the task, and downstream systems rarely verify whether each action still fits the original intent. Once an agent can chain tool calls or trigger sub-agents, the privilege model becomes harder to reason about because each hop may preserve, expand, or obscure authority. The technical risk is not only over-permissioning, but also loss of traceability across a multi-step delegation chain.

Practical implication: require per-user, per-tool scoping and traceable delegation so inherited permissions do not outlive the original task.

Why runtime detection must sit beside access approval for AI agents

The article correctly separates approval from safety. An access registry can tell you which agents and tools are authorised, but it cannot tell you whether a session is drifting into unsafe behaviour once approved access is in use. Runtime behavioural detection fills that gap by examining action sequences, not isolated events. That matters because reading records, sending messages, and updating systems can look benign one by one while forming an exfiltration path in combination. Identity governance for agents therefore needs two linked views: what was allowed at entry and what the session actually did after entry.

Practical implication: pair agent approval with session-level behavioural monitoring so policy and actual use can be compared continuously.

NHI Mgmt Group analysis

AI agent identity is creating a governance class that service-account thinking cannot fully absorb. Static NHI controls assume a workload will behave consistently enough for provisioning, review, and revocation to keep pace. The article shows that agents can change behaviour at runtime, chain tools, and delegate work without a human rewriting the policy in real time. The implication is that identity governance now has to treat runtime choice as part of the identity problem, not as an application detail.

Maker identity is a specific privilege-amplification pattern, not just a delegation inconvenience. When an agent inherits the builder’s credentials, every downstream user can operate through that original access context. That means ownership, task assignment, and actual authority diverge the moment the agent is shared. For IAM and IGA teams, the practical conclusion is that delegation cannot be certified only at creation time; its blast radius must be tracked through the full sharing lifecycle.

Access approval is no longer sufficient when the same approved session can execute an unpredictable sequence of actions. The article’s distinction between registry control and runtime monitoring exposes a broader truth: pre-authorisation models assume the meaningful risk happens before entry. AI agents move risk inside the session, where tool chaining and sub-agent delegation can create harmful outcomes without any single action looking suspicious. Security teams need to recognise that the governance boundary has shifted from entry approval to session behaviour.

Runtime governance gap: identity programmes built around fixed permissions are failing to account for agent behaviour that changes with context. That assumption was designed for stable workloads, not for software that can decide which tools to call and when to call them. The implication is that identity architecture must be rethought around behaviour, not just credentials.

Agent sprawl is an inventory problem before it is a control problem. If organisations are discovering 10 to 100 times more agents than expected, the first failure is visibility, not policy design. Hidden agents mean hidden owners, hidden tool paths, and hidden accountability gaps. Practitioners should read this as a warning that governance models collapse quickly when discovery lags deployment.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how weak the discovery baseline still is for non-human identity governance.
• For a broader threat view, read 52 NHI Breaches Analysis for recurring exposure patterns and root causes.

What this signals

The immediate programme signal is that agent governance cannot be folded into existing service-account reviews without losing material risk context. As agents spread across internal builders, SaaS platforms, and developer endpoints, teams need a single inventory model that captures owner, delegation path, tools, and downstream dependencies before access reviews can mean anything.

With 80% of identity breaches involving compromised non-human identities, according to the Ultimate Guide to NHIs, the gap is not theoretical. The next governance step is to combine discovery with continuous session monitoring so approved access and actual behaviour are evaluated together.

Delegation chain visibility: this is the control concept practitioners should sharpen now. If you cannot show who created an agent, who shared it, and which sub-agents it can trigger, you do not have accountable identity governance.

For practitioners

• Inventory all agent entry points Map homegrown platforms, SaaS builders, and developer copilots separately so you can see where agents exist, who owns them, and which systems they can reach.
• Separate maker credentials from user delegation Reject shared builder identity patterns and require the current user's scope to control what the agent can do on each tool and each session.
• Trace the full delegation chain Record who created the agent, who shared it, which tools it can invoke, and whether any sub-agent inheritance expands access beyond the original approval.
• Add session-level behavioural monitoring Watch action sequences across the entire session so benign individual steps can be evaluated in context for exfiltration, misuse, or scope drift.
• Prioritise high-blast-radius prebuilt agents first Start with coding assistants and endpoint-connected agents because they combine broad developer permissions with external tool access and limited review.

Key takeaways

• AI agents are not just another NHI because their runtime decisions can change the meaning of the access they inherit.
• The article’s central warning is that hidden agents and maker-identity delegation create a governance gap before most teams realise agents are present.
• Identity teams should move from static approval lists to discovery, per-user scoping, and session-level monitoring if they want control that survives agentic behaviour.

Key terms

• Agent Identity: An agent identity is the set of attributes, credentials and permissions assigned to an autonomous software entity. It is treated as a non-human identity because it can authenticate, act on systems and accumulate access over time, which creates governance, audit and lifecycle obligations similar to other production identities.
• Maker's Identity: A delegation pattern where an agent runs under the identity of the person who created it rather than the person using it. This is especially risky in shared agent platforms because every downstream user can inherit the maker's broader permissions and data access.
• Context-Based Behavioural Detection: Context-based behavioural detection flags suspicious identity actions by combining behavioural signals with the data and systems involved. It is stronger than simple anomaly detection because the same action can be harmless in one workflow and dangerous in another depending on what the identity can reach.

What's in the full article

Noma Security's full article covers the operational detail this post intentionally leaves for the source:

• Environment-by-environment examples across homegrown agents, SaaS agent builders, and coding assistants.
• Operational discussion of discovery, access control, and runtime behavioural detection working together.
• Concrete guidance on tracing ownership, delegation, and tool paths across agent sessions.
• Examples of the highest-risk prebuilt agent surfaces and why they should be prioritised first.

👉 The full Noma Security article covers runtime detection, delegation patterns, and where agent risk concentrates first.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.