AI agents need blended identity, not plain workload identity

At a glance

What this is: This is an analysis of why AI agents need a blended identity model that combines agent context, user context, runtime policy, and short-lived credentials.

Why it matters: It matters because identity teams must govern agent access without assuming workload patterns are deterministic or that human IAM patterns can safely carry over unchanged.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read Aembit's analysis of why AI agents need blended identity

Context

AI agent identity is not the same thing as workload identity, because agents do not behave like deterministic services with fixed access paths. The article’s core point is that existing IAM assumptions break when the identity can decide at runtime what to access, in what order, and under which policy context.

The governance gap is straightforward: static credentials, pre-scoped permissions, and log records that only show a service account are not enough when an agent acts on behalf of a user and can change behaviour mid-task. That creates problems for access control, attribution, and compliance at the same time.

This is a typical enterprise mistake rather than an edge case. Teams reach for the nearest identity category, then discover that the category choice has already shaped the blast radius, the audit trail, and the policy model.

Key questions

Q: How should security teams govern AI agents that need access only for a single task?

A: Use just-in-time identity issuance tied to the task, not a standing account that remains valid after the work finishes. The control goal is to align credential lifetime with execution lifetime, preserve traceability to the delegator, and revoke access immediately once the agent completes the action. That reduces standing exposure and makes audit evidence clearer.

Q: Why do AI agents complicate existing IAM and authorization models?

A: AI agents complicate IAM because they turn natural language into execution, which can cross systems faster than human review can intervene. Traditional standing access models assume stable actors and predictable workflows. Agents are more dynamic, so the control point must shift to ephemeral authorization, contextual claims, and continuous validation.

Q: What breaks when an AI agent is given a generic service credential?

A: A generic service credential breaks the link between task scope and access scope. The agent can now operate with org-wide authority even when it only needs a narrow delegated boundary, which expands blast radius and makes incident review harder. That is a governance failure, not just a token choice problem.

Q: How should security teams log AI agent actions for audit and compliance?

A: Security teams should log AI agent actions as identity events, not just application events. Each record should include the human initiator, agent identity, approved session scope, tool invocation details, and any downstream delegation. That structure lets investigators prove whether the action stayed within authorised boundaries and gives compliance teams a defensible record of accountability.

Technical breakdown

Why AI agent runtime access breaks workload identity assumptions

Traditional workload identity assumes a stable application pattern. A service account can be granted access because the system’s actions are known in advance: call this API, read that bucket, run that job. AI agents do not preserve that predictability. Their access path can change based on the user request, retrieved context, or tool choice made during execution, which means the permission boundary is not fully knowable at provisioning time. That is the central mismatch. A static credential can become broader than intended as soon as the agent’s behaviour shifts.

Practical implication: do not model agent access as if the request path were fixed at provisioning time.

Standing credentials and the AI agent blast radius problem

A standing credential creates continuous access exposure, which is tolerable only when the actor’s behaviour is stable and tightly bounded. For AI agents, the article highlights a different problem: the same credential may outlive the model behaviour, prompt context, or tool integration it was originally designed for. That is not just overpermissioning. It is a mismatch between a static authorization artifact and a dynamic decision-maker. Once access is continuous, the blast radius is whatever the credential can reach, not whatever the original task required.

Practical implication: treat persistent credentials for agents as a structural risk, not just a secret hygiene issue.

Why attribution fails when multiple agents share infrastructure

Standard logging often records the service account or application identity, but not the full causal chain behind the action. In an environment where several agents share runtime infrastructure, that means you can see that something accessed a system without being able to prove which agent acted, which user session triggered it, or which policy approved it. That is an auditability failure, not merely a logging gap. For regulated environments, the inability to reconstruct the decision context weakens accountability and makes post-incident investigation slower and less certain.

Practical implication: preserve user context, agent context, and policy decision context in the access record.

Threat narrative

Attacker objective: The objective is to use an AI agent’s persistent or overbroad identity path to reach resources, expand access, and obscure attribution.

1. Entry begins when an attacker or unauthorised workflow reaches a standing agent credential, a reused service account, or another persistent access path.
2. Escalation occurs when that credential is used against broader resources than the original task required, especially if the agent’s behaviour has changed since provisioning.
3. Impact follows when the attacker can act through the agent’s access path with limited attribution, expanding blast radius and weakening auditability.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent identity is a new identity class, not a renamed workload. The article’s strongest point is that agent behaviour sits between workload determinism and human-session context, which is exactly why simple category mapping fails. If teams treat the agent as just another service account, they lose the runtime policy context that governs how the agent actually decides. The practitioner conclusion is to classify the actor first, then design the authorization model around that behaviour.

Static least privilege is not enough when access decisions are made at runtime. Least privilege is often defined at provisioning time, but that assumption only works when the actor’s intent is stable enough to predict. AI agents infer their path mid-task, so the access boundary is not fully knowable in advance. The implication is that entitlement design must move from static scoping to policy evaluation at the moment of use.

Blended identity is the named concept that matters here: it preserves both agent context and user context. That framing is useful because it explains why neither pure human IAM nor pure workload identity solves the problem alone. The audit trail has to answer who requested the action, which agent executed it, and what policy authorized it. Practitioners should treat attribution as a control objective, not a reporting afterthought.

Standing access becomes a governance failure when the actor can change behaviour without a new credential. A model update, prompt change, or new tool integration can alter what the agent is able to do while the original credential remains valid. That means the authorization decision is being applied to a different behavioural reality than the one it was designed for. The practitioner takeaway is that the control is not just credential lifetime, but behavioural alignment over time.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, which is why visibility alone is not enough.
• The 52 NHI Breaches Analysis shows how weak identity governance turns ordinary access into repeatable breach patterns.

What this signals

Blended identity: this is the practical shift AI agent programmes now need, because runtime access must be governed with both agent context and user context attached. As agent adoption grows, the security programme will need to distinguish between visibility, enforcement, and attribution, rather than assuming one control covers all three.

Current NHI controls already struggle with service-account visibility, so agent identity will not be manageable if it inherits the same blind spots. The lesson from the Ultimate Guide to NHIs is that governance needs lifecycle, rotation, and revocation discipline before runtime enforcement can be trusted.

Practitioners should also align agent governance with the OWASP Agentic AI Top 10 and the NIST AI Risk Management Framework, because runtime policy failures are not just access issues. They are behaviour, accountability, and control-design problems that need cross-functional ownership.

For practitioners

• Define agent identity separately from user identity Create an identity model that records the agent as its own subject while linking it to the user session on whose behalf it acts. That makes access decisions and audit records reconstructable.
• Issue runtime-scoped credentials for tasks Replace standing access with short-lived credentials that are minted for a specific task, resource, and policy decision, then expire when the task ends.
• Log the full authorization context Capture agent identity, user session, target resource, and policy outcome in the same event so investigators can answer who acted and why.
• Review whether current IAM assumes deterministic behaviour Test every control that depends on fixed paths, fixed scopes, or stable access patterns, because those assumptions are the first to fail when agents decide at runtime.

Key takeaways

• AI agents cannot be governed safely as plain workloads because their access path is decided at runtime, not fixed in advance.
• Static credentials create a wider blast radius for agents, especially when behaviour can change through prompts, model updates, or new tools.
• The control problem is not just access scope, but attribution, because audit logs must show which agent acted, on whose behalf, and under what policy.

Key terms

• Blended Identity: Blended identity occurs when an autonomous system acts partly on behalf of a person and partly under its own machine authority. This creates split accountability because one actor may initiate the task while another identity performs the privileged action across different systems.
• 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.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
• Attribution: Attribution is the ability to prove which identity performed a specific action, through which systems, and with what outcome. In agentic environments, attribution must span APIs, services, and workflow steps, because isolated logs are rarely enough to reconstruct decision chains or support audit and incident response.

What's in the full article

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

• How the blended identity model is applied at runtime across agent, user, and policy context
• The specific enforcement flow for issuing short-lived credentials to AI agents
• The visibility-versus-enforcement distinction that affects production rollout decisions
• The example integration pattern described for Microsoft Copilot Studio

👉 The full Aembit article covers the runtime policy model, attribution details, and Copilot Studio example.

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 building or maturing an identity security programme, it is worth exploring.