TL;DR: Workload identity alone cannot safely govern AI agents because the same agent can act on behalf of different users, prompts and intents, forcing overly broad permissions that expand blast radius when behaviour shifts at runtime, according to Hush Security research. The right control is an effective access policy that combines agent identity and authenticated user claims so access is resolved per request, not per workload.
At a glance
What this is: This is an analysis of why traditional workload identity does not fully govern AI agents, and why combining agent identity with user context changes access decisions at runtime.
Why it matters: It matters because IAM teams need to scope AI agent access to the current user’s authority, or one agent can inherit permissions that exceed the user’s intended blast radius.
Context
AI agents do not behave like scheduled jobs or ordinary microservices. They interpret prompts, choose actions at runtime, and can be pushed into requests that exceed the user’s intent, which means classic workload identity no longer captures the real access decision.
The governance gap is not whether the agent has an identity, but whether that identity is evaluated alongside the person driving it. Without that second plane, the same agent can be over-scoped for one user and under-governed for another.
Key questions
Q: What breaks when AI agents are monitored like ordinary automated jobs?
A: What breaks is the assumption that fixed schedules and static logs are enough. Autonomous agents can act continuously, switch context, and combine tools in ways that simple job monitoring will miss. Security teams need observability that links identity, action, decision context, and oversight state in a single reviewable record.
Q: Why do AI agents need user context in addition to workload identity?
A: Because the security decision is not just who the agent is, but who is driving it and what that user is allowed to do. User claims, roles and group memberships let the policy engine narrow access so the agent cannot exceed the current human or role boundary during the session.
Q: How can teams tell whether agentic access controls are actually working?
A: Look for evidence that every privileged action is logged with actor type, target resource, and policy decision, and that denied requests are being blocked before execution. If you can only see the login and not the downstream action, the control is too weak for agentic use.
Q: What is the difference between agent identity and effective access policy?
A: Agent identity proves which autonomous system is calling, while effective access policy resolves what that system may do once the current user context is added. The first is an identity assertion, the second is the authorization decision that turns identity into a bounded permission set.
Technical breakdown
Why workload identity is incomplete for AI agents
Workload identity answers a narrow question: which workload is calling. That works for predictable services because the request pattern, destination and privilege need are stable. AI agents are different because the effective permission depends on who is driving the session and what the agent decides to do next. If the same agent can query one dataset, update another system, or be manipulated into a broader request, then a single static service identity collapses multiple access contexts into one. That is why workload identity alone becomes an over-permissioning mechanism rather than a control. Practical implication: treat agent identity as necessary but not sufficient when designing access control for runtime decision-making systems. See the Agentic AI Identity Guide.
Practical implication: stop using a single static workload identity as the full access model for AI agents.
What an effective access policy changes at decision time
An effective access policy resolves privilege from two identity planes at runtime. The first plane is the agent, established through cloud-native identity or attestation. The second plane is the authenticated user, carried in IdP-issued claims such as group membership and role. Policy evaluation combines both to determine the exact credential scope for the current action. This is not simply user impersonation, because the agent still needs its own verified identity. It is also not traditional delegation, because the privilege boundary changes with the user context on each request. Practical implication: design authorization so the policy engine can re-evaluate access for every action, not just every session. See the AI Agent Authorisation Guide.
Practical implication: make authorization re-evaluate the current user and current action before issuing credentials.
How just-in-time credentials limit surprise actions
Just-in-time credentials reduce the damage window by issuing scoped access only when the current request matches policy. For AI agents, that matters because the risk is not only credential theft but also misaligned execution, where a valid agent performs an unexpected operation with excessive rights. If the agent is manipulated into a broader query or a write action that the user should not have, JIT issuance keeps the blast radius tied to the user’s claims instead of the agent’s total capability. That makes runtime authorization the real control point, not the broadest possible pre-provisioned access. Practical implication: issue the minimum credential set needed for the verified user context and revoke it as soon as the action completes. Read Zero Trust for AI Agents.
Practical implication: issue the minimum credential set needed for the verified user context and revoke it after the action completes.
Threat narrative
Attacker objective: The objective is to induce the agent to perform unauthorized reads or writes while hiding behind a legitimate identity and trusted workflow.
- Entry occurs when a user starts a session with an AI agent that already has broad access to data and business systems.
- Escalation happens when the agent is manipulated by prompt injection or vague intent into attempting actions beyond the user’s legitimate scope.
- Impact follows when the agent executes those requests with permissions that exceed the user’s intended blast radius, exposing data or changing records outside policy.
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.
- Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
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
Workload identity is not an access model for autonomous decision-making: It answers who the workload is, but not what the workload is allowed to do under a particular user context. AI agents can change actions, targets and consequences mid-session, so the old assumption that one service identity maps cleanly to one permission boundary no longer holds. The implication is that agent governance must move from workload centric provisioning to request centric authorization.
Effective identity for agents is a composite, not a single principal: The article points to a useful governance pattern because the agent identity and the user identity are both part of the access decision. That is a stronger model than static service accounts because it aligns privilege with the current human or role context driving the interaction. Practitioners should read this as a sign that delegation chains now need explicit policy resolution, not implicit trust in the calling workload.
Dynamic scoping is a blast-radius control, not just a convenience feature: When the same agent can serve a regional analyst, a finance lead, or an unattended job, the control objective changes from authenticating the agent to constraining the consequences of each invocation. Zero Trust for AI Agents is relevant here because the trust decision must happen per action, not once at deployment. The practical conclusion is that AI agent privilege should contract and expand with the authenticated user, or the agent becomes a standing privilege amplifier.
Runtime authorization is the real control plane for agent governance: The meaningful security boundary is no longer the platform that hosts the agent, but the policy engine that resolves the effective identity before credentials are issued. That is why just-in-time access is central here. If policy does not incorporate user claims at decision time, the agent inherits the broadest possible privilege set and the programme loses containment by design.
Agent identity governance now overlaps with human IAM discipline: This is not only an NHI problem, because the user’s IdP claims directly shape what the agent may do. That makes identity governance cross-domain by structure, not by coincidence. The practitioner takeaway is that AI agent access reviews must consider both machine attestation and human role claims, or the governance model remains incomplete.
From our research library:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- Read next: Zero Trust for AI Agents
What this signals
Effective access is becoming the governing concept for AI agents: Access controls built for stable workloads cannot contain runtime decision-makers, because the privilege boundary now has to follow the authenticated user as well as the agent. That changes the design target from static provisioning to per-request authorization, and it will reshape how teams think about agent identity governance.
Security leaders already see the scale of that shift: 69% agree identity management must fundamentally change for agentic AI systems, according to the 2026 Infrastructure Identity Survey. The practical implication is that agent access cannot be a bolt-on exception path.
Blast-radius control becomes the decisive metric: When an agent can serve different users, the real question is not whether it has access, but whether its access contracts before it can act outside the current user’s authority. That is why effective identity has to be evaluated at issuance time, not after the fact.
For practitioners
- Define the effective identity boundary Specify which user claims, group memberships and role attributes must be present before an agent can request sensitive data or write actions.
- Replace static agent scopes with request-level policy Evaluate each agent action against the current user context so the same agent can be constrained differently for different sessions.
- Tie credential issuance to the current action Issue short-lived credentials only after the policy engine has resolved the combined agent and user identity for that request.
- Separate scheduled jobs from interactive agent sessions Keep unattended automation on a predictable workload identity path and reserve context-aware policy for interactive agent sessions with human-driven intent.
Key takeaways
- AI agents cannot be governed safely with workload identity alone because they can change actions and targets at runtime.
- The right access model combines verified agent identity with the authenticated user’s claims so privilege follows the current session context.
- Just-in-time credential issuance is the containment mechanism that keeps agent blast radius tied to user authority rather than total system capability.
Related NHI Mgmt Group resources: Agentic AI Identity Guide · AI Agent Authorisation Guide · Zero Trust for AI Agents · AI Agent Observability, Audit and Incident Response Guide
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 and OWASP Non-Human Identity Top 10 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 receiving or exceeding privilege based on identity context. |
| Recommendation — Bind agent actions to runtime policy so identity and privilege cannot drift beyond the current user context. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The post relies on verified agent identity and attestation before access is issued. |
| NHI-05 — Overprivileged NHI | Static workload identity can grant broader access than the current task or user justifies. | |
| NHI-10 — Human Use of NHI | The user driving the agent directly shapes the effective access decision. | |
| Recommendation — Authenticate the agent with strong attestation before any sensitive credential is issued. Reduce standing access and scope each agent to the minimum privilege needed for the current request. Treat user-mediated agent sessions as human-governed NHI use and resolve access from both identities. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is authorization scope for agentic access under current identity context. |
| Recommendation — Enforce request-level entitlement checks so agent permissions match the authenticated user’s authority. | ||
Key terms
- Effective Access: The actual permissions an identity can exercise after inheritance, nested groups, delegation, and object-level controls are evaluated. In Active Directory, effective access is more useful than direct membership because it reveals the true operational reach of a service account.
- 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.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
- Request-level Authorization: Request-level authorization means access is decided for each request rather than once at login or network entry. It lets operators scope permissions by route, method, and identity, which is far more precise than broad network access and better suited to distributed systems and NHIs.
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 identity controls for modern infrastructure or AI-driven systems, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org