AI agent identity vs service accounts: where IAM assumptions break

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: AI agents behave differently enough from service accounts that traditional IAM assumptions break across authorization, auditing and revocation.

Why it matters: IAM teams need to treat AI agents as a distinct governance problem because action-level authorization, delegated identity and reasoning traces do not map cleanly to service account controls.

Context

AI agent identity is not just another NHI variant. The article shows that agents can look like service accounts at the API boundary while behaving very differently at runtime, which means existing IAM models can misread the real permission boundary.

For identity teams, the issue is governance rather than novelty. If scope, audit and revocation controls still assume fixed behaviour and long-lived credentials, they will miss where an agent’s authority is actually exercised: at the tool call, in the session, and through delegated user context.

Key questions

Q: What breaks when AI agent access is managed like standard IAM access?

A: What breaks is the assumption that access is stable, reviewable, and tied to a single human owner. AI agents can call tools, change scope, and execute within runtime workflows, so standard IAM review cycles may miss the real moment of risk. Governance needs to move closer to execution and delegated authority.

Q: Why do AI agents make delegated access riskier than traditional service-to-service calls?

A: AI agents increase risk because one human request can fan out into many downstream actions, often across several systems and other agents. Each hop creates another chance to lose scope, actor context, or audit fidelity, which turns a manageable delegation pattern into a governance problem.

Q: What are the signs that an AI agent access model is too weak?

A: Warning signs include unrestricted prompt handling, broad access to knowledge bases, unguarded API calls, and responses that can expose sensitive information without review. If the agent can act before permissions are checked, or if the same policy is not applied to inputs, data, tools, and outputs, the control model is already too loose.

Q: How should security teams model AI agents in cloud governance when the agent runs through a service account?

A: Treat the agent as an identity surface, but treat the service account as the source of effective privilege. The agent itself usually acts through delegated access, so governance should trace the full chain from invoker to agent to service account to downstream resources. That approach exposes blast radius, shared credentials, and over-privileged paths before they turn into control gaps.

Technical breakdown

Runtime behaviour vs code-defined behaviour

A service account’s behaviour is normally defined by code, so its possible actions are enumerable from repositories, deployment pipelines and change control. An AI agent’s behaviour is produced at runtime from prompts, tool descriptions and model interpretation, which means the same identity can take different actions without a code change. That breaks assumptions behind static allowlists, code review and behavioural baselining. The security boundary shifts from the repository to the live interaction between model, prompt and tools.

Practical implication: authorisation must evaluate the action in context, not just the identity at provisioning time.

Delegated identity and the multi-hop trust chain

Service accounts act as themselves, but agents often act on behalf of a user through a chain that includes the user, the application, the agent process and downstream services. That creates a provenance problem as well as an access problem, because accountability depends on which user session and which prompt produced the action. Short-lived delegated tokens help, but only if downstream services preserve the delegated identity instead of collapsing it back into the agent credential.

Practical implication: design downstream services to inspect and enforce user-bound delegation, not just accept the agent’s own token.

Reasoning traces as part of the audit surface

Traditional service account logs record who called what and when. Agent auditing needs more: the user request, prompt, tool set, model version, reasoning trace or tool chain, and the resulting action. Without that context, teams cannot explain why an agent acted or prove whether the action matched user intent. These traces are also sensitive because they can expose user data, third-party content and internal operational hints, so they need stronger retention and access controls than ordinary machine logs.

Practical implication: treat prompts and reasoning traces as first-class audit evidence, not optional debug output.

Threat narrative

Attacker objective: The objective is to induce the agent to perform a legitimate-looking action that exceeds the user’s intent while staying inside its allowed tool surface.

1. Entry occurs when an attacker or malicious input reaches the agent through a prompt, tool output, webpage or document that the model reads as instruction.
2. Privilege escalation happens when the agent accepts adversarial context and uses its delegated tools or broad session scope to attempt actions outside the user’s intent.
3. Impact follows when the agent completes an unintended write, message, payment or data access action through downstream systems that trust the delegated call.

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.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent identity exposes an assumption collapse in IAM design: least privilege was designed for identities whose action scope is knowable at provisioning time. That assumption fails when the actor decides per call, because the effective privilege boundary moves to runtime tool invocation. The implication is that IAM has to reason about action, not just credential.

Tool-layer governance is now the real permission boundary: agents do not simply inherit the rights of a static account, they operate through a catalog of tools whose descriptions, schemas and implementations shape what they can do. That means capability review has become a security control, not just a product configuration task. Practitioners need to govern tools as permission surfaces, not features.

Delegated identity should be treated as provenance, not decoration: an agent acting on behalf of a user is not equivalent to an autonomous service account. The useful question is who requested the action, which prompt shaped it, and whether downstream systems preserved that context. Identity programmes that lose the delegation chain lose accountability.

Auditability for agents is broader than auditability for service accounts: log lines alone cannot explain agent behaviour because the decision is formed across prompts, tools and model outputs. Reasoning traces and tool chains therefore become governance artefacts, but they also raise retention and sensitivity issues. The practical conclusion is that evidence collection must expand with the actor model.

Runtime autonomy changes the governance unit from identity to session: agent sessions are often short-lived, narrowly scoped and created on demand, which is healthier than standing access but harder to govern with legacy NHI inventory thinking. That shift points to a new pattern of identity blast radius management built around issuance events. Teams should re-centre governance on session-bound delegation and tool-authorised actions.

From our research library:

• 59% of organisations say they lack viable alternatives to standing privileged access for NHIs and AI agents, according to Delinea research.
• Read next: Agentic AI Identity Guide

What this signals

Delegated identity is the new control plane: AI agents force identity teams to move governance away from static credentials and toward session-bound, user-scoped delegation. That shift matters because the real risk is no longer just who owns the account, but which request and which tool call it can execute on behalf of that user.

Runtime authorisation replaces provisioning-time certainty: when behaviour is decided per call, access reviews that depend on stable entitlements lose their leverage. Organisations that fail to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.

Tool inventories are becoming identity inventories: as agent capability expands through added tools, security teams need a named control surface for what those tools can do and who approved them. That is the practical boundary where agentic governance, IAM and audit discipline now meet.

For practitioners

• Authorize at the action level Evaluate each agent tool call against the originating user request, the current session and the specific arguments being passed. Static identity permissions are too coarse once the agent can choose actions at runtime.
• Bind credentials to user sessions Issue short-lived delegated tokens tied to the user session or task, and avoid giving agents their own long-lived credentials where possible. Ensure downstream services honour the delegated identity instead of flattening it into the agent account.
• Treat tool inventories as permission catalogs Review every new tool, tool description and schema as if it were a new privilege path. Version tool availability with the same discipline used for IAM policy changes because the tool set defines the agent’s real capability.
• Capture reasoning as audit evidence Retain prompts, tool inputs, tool outputs and model version data alongside execution logs so investigators can reconstruct why an agent acted. Treat these records as sensitive security evidence rather than disposable telemetry.
• Plan for hostile inputs Assume an agent will eventually read content that contains hidden instructions or adversarial guidance. Constrain tools so a persuaded agent cannot cause irreversible damage without another control, especially for payment, data-write or external-message actions.

Key takeaways

• AI agents are not just service accounts with a new label, because their behaviour, trust inputs and audit requirements are produced at runtime rather than fixed at provisioning.
• The most important control shift is from credential management to action governance, with delegated identity and tool-level enforcement doing the work legacy IAM cannot.
• Teams that keep measuring agent risk through static account reviews will miss the real failure mode, which is permission exercised inside a live session and recorded only imperfectly.

Key terms

• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.
• Tool-Layer Authorisation: Tool-layer authorisation is the control point where an AI agent’s proposed action is approved or denied before it reaches an underlying system. It matters because the agent’s real capability is defined by the tools it can invoke, not by a static account label or credential alone.
• Reasoning Trace: A reasoning trace is the record of prompts, tool inputs, model outputs, and decisions that led to an agent action. For governance, it is part of the audit trail because simple API logs rarely explain why the agent acted or whether the action matched the user's intent.
• Session-Bound Credential: A short-lived token or certificate tied to a specific interaction window rather than a durable integration. For MCP, this is the practical control that prevents a connected client from keeping standing access after the intended task ends.

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.