Why do blended user and system identities increase risk in agentic workflows?

How blended identities change the control problem

Blending user and system identities turns one workflow into two authority models at once. The agent is no longer acting only as a delegated user or only as a service principal, so the control question becomes what it may do in each plane, when authority changes, and which actions must remain attributable to the human versus the machine credential. That boundary is where risk accumulates.

In practice, the danger is not just “more access”, it is ambiguous access. When a workflow can switch between user context and system context, the effective permission set often becomes the union of both unless policy, token exchange, and approval boundaries are tightly defined. See Agentic AI Identity Guide for the identity model behind delegation, registration, authentication and retirement.

That ambiguity also weakens governance. Reviewers may approve the user-facing action while overlooking the system-level side effects, such as background reads, writes, or tool calls that execute under stronger credentials. The result is a task that appears user-scoped in the interface but machine-scoped in execution, which makes scoping, recertification, and audit review harder to reason about.

Why accountability and privilege boundaries get blurred

Accountability becomes harder because a single event may represent both a user intent and an autonomous system decision. If logs do not clearly show when the agent is speaking for the user and when it is exercising its own credential, incident reviewers cannot reliably reconstruct who authorised what. That makes exception handling, forensic review, and approvals less trustworthy.

Privilege boundaries blur for the same reason. A system identity often carries standing access, broader network reach, or more reliable API permissions than the user who launched the task. If the workflow can borrow that access mid-stream, the practical privilege boundary shifts from “what the user asked for” to “what the agent can reach once execution starts”, which is much harder to govern. AI Agent Authorisation Guide is useful here because it treats per-action policy and task-scoped access as the control point, not the whole session.

For operational teams, this is also where entitlement drift shows up. The original user action may be safe, but the workflow can accumulate additional authority through token reuse, delegated tool access, or inherited permissions. A blended design needs explicit decision points that answer: which identity is in force now, what is the allowed action set, and what happens when the task crosses that boundary.

What goes wrong when blended identities are treated as one actor

When a blended workflow is treated as a single actor, failures tend to cascade. A mistake in user-scoped logic can expose system-scoped capabilities, while a compromise of the agent runtime can let an attacker pivot from delegated context into the machine credential path. That is why agent observability matters as much as authorization. The AI Agent Observability, Audit and Incident Response Guide focuses on attribution, logging and revocation when an agent goes off course.

Another common failure mode is hidden privilege expansion. A user starts a benign task, the agent calls a tool that has broader rights than the user, and the outcome is materially outside the user’s original intent. That can lead to overbroad data exposure, unintended changes, or actions that are hard to roll back because they were executed under a stronger credential than the initiating identity.

Blended identities also complicate containment. If one identity plane is compromised, defenders may not know whether to revoke the user session, the agent token, the service credential, or all three. The more the workflow mixes those planes, the more difficult it becomes to isolate blast radius without breaking legitimate automation.

Risk and Threat Considerations

Blended user and system identities create an attractive attack path because they let an attacker move from an apparently legitimate delegated action into higher system privilege. The risk is not limited to misuse of a single token, it includes confused-deputy behaviour, approval bypass, and privilege escalation through the agent’s own runtime authority.

Failure mechanism: The agent reuses or combines user context and system credentials without a hard policy boundary, so an attacker can abuse the stronger plane after entering through the weaker one.

Impact: The resulting compromise can hide in normal workflow traffic, expand access beyond user intent, and force responders to treat both the human session and the machine identity as potentially compromised.

Practitioner Guidance

What to verify: Check whether every meaningful action can be tied to one active principal at a time, with an explicit transition when the workflow changes from delegated user action to machine-credentialed execution. If the answer is no, the design is already too permissive.

Decision rule: If an action can modify data, invoke tools, or reach downstream systems, require task-scoped authorization and separate evidence of user intent from system execution rights. If the workflow cannot produce that separation, treat it as a higher-risk exception rather than a normal operating mode.

What good looks like: The audit trail shows who initiated the task, which identity executed each step, and when any privileged step was approved, without assuming that the user and system identities are interchangeable.

Practitioner takeaway: The objective is not to eliminate delegation, but to keep delegation explicit enough that privilege never expands invisibly beyond the user’s intent.

Related resources from NHI Mgmt Group

• Why do AI agents increase non-human identity risk in existing IAM programmes?
• When does just-in-time access reduce risk for agentic AI, and when does it fall short?
• Why do AI agents increase non-human identity risk?
• Why do agentic AI and automated workflows increase fraud and access risk when identity assurance is weak?