TL;DR: AI agents are spreading across homegrown, SaaS, and developer environments, but most teams still govern them as if they were service accounts and API keys, according to Noma Security. That model misses runtime delegation, ownerless agents, and tool-chaining behaviour that makes identity control and accountability materially harder.
At a glance
What this is: This analysis says AI agent identity is more complex than service account governance because agents inherit credentials, delegate tasks, and chain tools at runtime.
Why it matters: IAM, IGA, PAM, and NHI teams need to treat agent identity as a distinct governance problem because ownership, authorization, and auditability break down when runtime decisions replace static workloads.
Context
AI agent identity is the governance problem that appears when software can act on behalf of users, inherit credentials, and make decisions at runtime. The article argues that service account and API key models only cover a narrow slice of the actual risk because agents can change behaviour based on context, instructions, and downstream tool calls.
That matters for identity programmes because the control assumptions differ from classic NHI management. Static workload identity can be inventoried and rotated, but agentic identity also needs ownership, delegation tracking, and runtime verification across tools, users, and sub-agents.
Key questions
Q: What breaks when AI agents are governed like ordinary service principals?
A: The main failure is that ordinary service-principal governance assumes a stable workload with predictable lifecycle and entitlement patterns. AI agents can inherit access from a blueprint, act through user-shaped interfaces, and change their operational state at runtime, so the control model no longer matches the behaviour. Teams need a separate governance view for the agent runtime, not just for the underlying credential object.
Q: Why do AI agents create accountability problems for IAM and NHI teams?
A: AI agents create accountability problems because traditional IAM proves who authenticated, while agent governance must prove what the actor did with that access. When the system can act, forget, and continue later, the organisation needs evidence across the whole task lifecycle. Identity controls alone do not show whether the action was justified or repeatable.
Q: What are the signs that delegated AI access is too ambiguous to govern safely?
A: Look for logs that only show the human user, tokens that never record the agent, and downstream services that cannot distinguish a delegated action from direct user activity. Those are signs the delegation model is hiding the actor. If investigators cannot answer which agent acted, the governance model is under-specified.
Q: How should security teams govern agent workflows at runtime?
A: Security teams should govern agent workflows with controls that evaluate prompts, tool calls, and outputs during execution, not only after deployment. Runtime checks matter because risk can appear at each stage of the workflow. The goal is to stop unsafe behavior before it becomes an executed action or a leaked response.
Technical breakdown
Why service account governance breaks for AI agents
Service accounts are built for predictable execution: one identity, one set of permissions, one repeatable workload. AI agents are different because they can decide which tools to call, in what order, and under which runtime conditions. That creates an identity object whose effective permissions may shift during a session even when the underlying credential does not. The result is that a provisioning-time control set cannot fully describe the agent’s operational authority. This is where inherited permissions, delegated tokens, and chained tool use become governance problems rather than simple authentication issues.
Practical implication: inventory agents by runtime behaviour, not just by credential type, before you decide what access they should have.
Maker’s identity and delegated authority
The Maker’s Identity problem occurs when an agent runs under the permissions of the person or system that created it, rather than the current user or task. In SaaS agent platforms and MCP-connected workflows, that can allow later users to inherit the maker’s broader privileges without realizing it. Even when OAuth is used, scoping is often broader than the task actually requires, and permissions may not update cleanly when the human’s access changes. That turns delegation into a lifecycle problem as much as an authorization problem.
Practical implication: separate creator privileges from end-user authority and verify that delegated access changes when the underlying human account changes.
Connected agents need traceable delegation chains
Agent-to-agent workflows amplify identity risk because each handoff can expand, preserve, or obscure authority. An orchestrator may invoke sub-agents, each with its own tools and data sources, while the original user never sees the full chain. If the enterprise cannot trace who asked whom to do what, and under whose authority each action ran, then accountability is incomplete even if every individual step looked valid. This is not only about logging. It is about preserving the permission boundary across every delegation hop so authority does not inflate silently.
Practical implication: require end-to-end delegation traceability for multi-agent workflows and block any handoff that cannot preserve least privilege.
Threat narrative
Attacker objective: The objective is to exploit delegated agent authority to reach sensitive systems and perform actions that are difficult to trace back to a clear owner or approval chain.
- Entry occurs when an agent inherits a user’s or maker’s credentials and is allowed into enterprise systems with more authority than the task requires.
- Credential abuse follows when static API keys, shared service accounts, or overbroad OAuth scopes let the agent reach tools and data sources without fresh human review.
- Escalation happens when the agent chains tool calls or delegates to sub-agents, widening effective permissions beyond the original approval boundary.
- Impact is the loss of accountability, traceability, and permission containment across the session, which can expose sensitive data or trigger unintended actions.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
AI agent identity has outgrown service account governance because the governing object is no longer static. Service accounts can be described at provisioning time, but agents change the way they use identity while the session is still active. That makes runtime behaviour part of the identity record, not just the workload description. The practical consequence is that identity governance must move from pure asset control to continuous authority tracking.
Maker’s Identity is the clearest sign that delegation and ownership are collapsing into the same control problem. When an agent created by one user is later used by many others, the original permission set can outlive the business context that justified it. That is not simply overprivilege, it is authority reuse under a different operational purpose. Practitioners need to treat ownership, edit rights, and effective runtime authority as separate governance questions.
Access review processes assume access persists long enough to be reviewed, but agent sessions can create and consume authority within the same task. That assumption fails when the actor can chain tools, invoke sub-agents, and narrow or widen authority between actions. The implication is that review cadences alone cannot govern agent behaviour; the decision point must move closer to issuance and delegation.
Agent-to-agent delegation creates an identity blast radius that classic NHI tooling does not model well. A single approved action can branch into multiple sub-actions across tools and systems, each with different authority requirements. If the enterprise cannot preserve least privilege across those handoffs, then the governance surface expands faster than the access model. Practitioners should treat delegation chains as first-class identity objects.
Runtime detection becomes an identity control, not just a security monitoring layer, once agents can make independent decisions. The article’s strongest point is that approval and execution are no longer the same event. That means governance must combine discovery, access control, and behavioural verification. The field should stop asking whether the agent is approved and start asking whether its live sequence of actions still matches the authority it was granted.
From our research library:
- Gartner predicts that by 2028, 33% of enterprise software applications will include agentic AI, up from less than 1% in 2024, and that 15% of day-to-day work decisions will be made autonomously.
- Read next: Agentic AI Identity Guide
What this signals
Agentic identity introduces a new governance boundary: a control can be correctly configured and still fail if the agent’s runtime decisions outgrow the access model it was assigned at creation. That is why identity teams need to move policy enforcement closer to issuance, delegation, and session-time verification.
The practical programme shift is from managing static entitlements to managing dynamic authority chains. In environments with SaaS agents, developer copilots, and homegrown orchestrators, the question is no longer whether access exists, but whether every handoff can still be explained and contained.
For practitioners
- Map agent ownership and edit rights Create an inventory that records who built each agent, who can modify its tools, and who is accountable when behaviour changes or permissions drift.
- Separate maker authority from user authority Do not let the credentials of the agent creator define the permissions of every later user. Scope agent access to the current user and task, not the original maker.
- Trace delegation chains end to end Require visibility into each tool call, sub-agent handoff, and downstream authorization step so that permission inflation is detectable before it becomes normal.
- Replace static access assumptions with runtime checks Treat agent sessions as dynamic authority windows and verify that each action still fits the approved context rather than trusting the initial approval alone.
Key takeaways
- AI agent identity cannot be reduced to service account management because runtime decisions, delegation chains, and inherited permissions expand the governance problem.
- The article argues that accountability becomes unclear when maker credentials, user context, and sub-agent actions no longer line up.
- Identity teams should shift from static entitlement reviews to live delegation controls and traceable authority chains.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on agents inheriting and expanding authority across runtime workflows. |
| Recommendation — Apply ASI03 to constrain agent authority to the current task and preserve traceable delegation. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Static keys, shared service accounts, and inherited credentials are central to the risk described. |
| NHI-05 — Overprivileged NHI | The article repeatedly describes agents acting with broader access than the task requires. | |
| Recommendation — Replace inherited static credentials with tightly scoped authentication tied to each agent context. Review agent entitlements for excess privilege and narrow each tool scope to the smallest usable set. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The governance gap is fundamentally about who can do what across agent sessions and delegations. |
| Recommendation — Define and enforce agent access permissions so runtime actions stay within approved authorizations. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat path relies on credential inheritance and chained access across tools and systems. |
| Recommendation — Map agent credential exposure and chained tool use to TA0006 and TA0008 in detection content. | ||
Key terms
- Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.
- 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.
- Delegation Chain: A delegation chain is the sequence of identities, credentials, and tool calls an agent uses to complete a task across systems. It matters because each step may appear acceptable on its own while the combined path produces an outcome no reviewer would have approved directly.
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 24, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org