TL;DR: AI agents are no longer behaving like scripted automation, and JumpCloud’s article argues that identity and access controls must shift from static trust assumptions to supervised, task-scoped governance. That matters because 61% of organisations report unsanctioned AI use, while perceived AI maturity still outpaces real readiness by 18 points.
At a glance
What this is: This is an analysis of why AI agents break traditional identity and access assumptions, with a focus on zero trust governance for autonomous systems.
Why it matters: It matters because IAM teams now have to govern human users, machine identities, and AI agents under one model without assuming the same access patterns, review cycles, or control boundaries apply.
By the numbers:
- 61% of organizations report the unsanctioned use of AI tools, creating a sprawling network of Shadow AI.
- Only 22% qualify as fully ready to govern AI at scale, even though 40% of organizations consider themselves AI mature.
- 18 points.
👉 Read JumpCloud's analysis of zero trust governance for AI agents
Context
AI agent governance fails when organisations assume autonomous systems will behave like scripts or static service accounts. The article’s core point is that once an agent can interpret vague instructions and make independent decisions, traditional identity controls no longer describe the real risk surface for AI agents.
That creates a zero trust problem for IAM, not just a technology adoption problem. Teams are being pushed to approve AI faster than their identity, access, and supervision controls can support, which is exactly why the gap between perceived maturity and actual readiness matters.
The article’s model is a useful reminder that human identity, machine identity, and AI identity cannot be governed as one bucket. Readiness depends on recognizing which actor is acting, what decisions it can make at runtime, and where approval needs to stay in the loop.
Key questions
Q: What breaks when AI agents are governed like scripts or service accounts?
A: What breaks is the assumption that access can be defined once and then safely reused. AI agents can interpret instructions, change course, and choose actions at runtime, so static entitlements and one-time approvals no longer describe the real behaviour. Governance has to account for decision-making during execution, not just initial login or provisioning.
Q: Why do AI agents complicate zero trust governance for IAM teams?
A: AI agents complicate zero trust because the trust question shifts from who authenticated to what the actor is doing right now. If the system can choose actions and adjust behaviour mid-session, then every step needs a scope check, not only the initial identity check. That makes runtime supervision and task boundaries central to access governance.
Q: How do security teams know whether AI agent governance is actually working?
A: They know it is working when agents stay within tightly bounded tasks, high-risk actions still require human approval, and unsanctioned AI use is being discovered rather than ignored. If teams only measure adoption or user enthusiasm, they can overestimate readiness while control gaps remain open. Effective governance produces observable boundaries, not just policy language.
Q: Who is accountable when an AI agent causes unauthorized changes?
A: Accountability should sit with the organisation that defined the agent’s permissions, approval paths, and operating limits. If the agent could act without adequate supervision, the failure is usually governance design, not the model alone. Security, IAM, and platform owners should all be able to explain where the boundary was set and why it was acceptable.
Technical breakdown
Why autonomous AI agents break script-based access models
Script-based automation follows a predefined path, but an autonomous AI agent can interpret instructions, choose actions, and adapt to new inputs mid-session. That shifts the control problem from execution reliability to decision governance. Once the actor can decide what to do next, identity is no longer just about authentication and authorization at the start of the task. It becomes about constraining runtime behaviour, tool use, and action scope while the work is in progress.
Practical implication: treat AI agents as runtime decision-makers, not as hardened scripts with predictable outcomes.
Zero trust for AI agents requires task-scoped identity
The article’s “digital intern” analogy maps to a practical identity pattern. Each AI agent should have its own identity, narrow permissions, and explicit task boundaries rather than broad administrative access. That is different from traditional service account management because the objective is not only least privilege, but also preventing the agent from widening its own effective reach through autonomous decisions. In zero trust terms, the question is not whether the agent is trusted once, but whether each action remains within the intended scope.
Practical implication: issue separate identities for agents and keep their entitlements aligned to one bounded task or workflow.
Human approval gates are still the control boundary for high-risk agent actions
The article’s recommended supervision model assumes some actions are too consequential for machine-only execution. Deleting files, moving money, or other high-impact actions need a human decision gate even if the agent can prepare the work. That reflects a broader identity principle: autonomy must be bounded where the business impact becomes irreversible. Without that checkpoint, the agent is not just executing work faster, it is operating outside the governance model that assigned it the work in the first place.
Practical implication: define which AI actions require human approval before the agent can complete them.
NHI Mgmt Group analysis
Zero trust for AI agents is an assumption shift, not a policy tweak. Traditional IAM assumes that a subject can be provisioned, reviewed, and governed against a stable job description. That assumption fails when the actor is autonomous because it can interpret vague instructions and alter its own execution path at runtime. The implication is that identity governance must stop treating access as a fixed state and start treating agent behaviour as the control object.
Task-based identity is the right control concept for autonomous work, but only if the task stays bounded. The article correctly rejects general admin roles for AI agents and replaces them with job-specific entitlements. That lines up with OWASP-NHI and zero trust thinking, but the deeper point is that broad permissions erase the distinction between assistance and delegated authority. Practitioners should see task scope as the primary containment boundary for agentic systems.
Shadow AI is now an identity governance problem, not just an acceptable-use problem. When 61% of organisations already report unsanctioned AI use, unmanaged agents are entering environments outside formal lifecycle control. That means access reviews, logging, and offboarding assumptions are already being bypassed before security teams even define the control model. The practical conclusion is that discovery and governance must move together.
AI readiness is being overestimated because organisations measure adoption, not control reality. The 18-point gap between perceived maturity and objective readiness shows that confidence is not the same as governable capability. In practice, this disconnect often means teams have tools, usage, and appetite, but no coherent way to bound privilege or supervise autonomy. The field should treat readiness as a control outcome, not an executive sentiment.
AI identity governance must now cover human, machine, and autonomous actors in one operating model. The article’s three-identity framing is directionally correct because the controls differ by actor type, even when the business workflow looks similar. Human identity needs authentication and user friction management, machine identity needs least-privilege and rotation, and autonomous AI needs runtime supervision and approval boundaries. Practitioners should stop forcing one governance pattern across three different identity behaviours.
From our research:
- From our research: 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, according to the 2026 Infrastructure Identity Survey.
- For the control model behind that gap, see OWASP Agentic AI Top 10 for the runtime risks that emerge when agents can choose actions independently.
What this signals
With 70% of organisations already granting AI systems more access than human employees performing the same job, the governance gap is structural, not theoretical. Teams that continue to apply human-era privilege assumptions to autonomous systems will keep overestimating control.
Identity blast radius: the real risk is no longer just that an AI agent has access, but that its access can expand into action faster than review cycles can react. That is why task scope, approval gating, and supervision must become first-class programme metrics rather than side controls.
For practitioners, the immediate signal is that AI adoption cannot outpace identity design. If your programme cannot explain how an agent’s permissions are bounded, observed, and revoked, then you do not yet have an AI governance model, only AI usage.
For practitioners
- Define separate governance paths for human, machine, and AI identities Classify each actor before assigning controls so that authentication, rotation, lifecycle review, and supervision match the actual identity type rather than the workflow label.
- Issue task-scoped identities for each AI agent Avoid shared or general admin access. Give every agent its own account, limit entitlements to one bounded use case, and review any permission that is broader than read-only access.
- Require human approval for high-impact agent actions Set explicit approval gates for actions that delete, move, or change production data, and make sure the agent can prepare work but not complete irreversible steps unauthorised.
- Measure AI readiness against control reality Test whether identity, logging, and access supervision actually support autonomous use instead of relying on adoption metrics or executive confidence as proof of maturity.
Key takeaways
- AI agents force IAM teams to move from static permission thinking to runtime governance of autonomous behaviour.
- JumpCloud’s analysis shows a real maturity gap, with 61% unsanctioned AI use and only 22% objective readiness for AI at scale.
- The practical response is to separate identities, bound tasks tightly, and preserve human approval for high-impact agent actions.
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 address the attack and risk surface, while NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Addresses runtime risk in agentic systems that can choose actions and tools. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Least privilege and continuous verification are central to task-scoped AI identity. |
| NIST AI RMF | GOVERN | AI governance requires explicit accountability for autonomous behaviour and supervision. |
Map agent permissions and approval gates to OWASP Agentic AI risks before broad deployment.
Key terms
- AI Identity: An AI identity is the access and governance construct assigned to an AI system that can make decisions or take actions in an environment. In practice, it needs scoped permissions, visible ownership, and controls that match the system’s runtime behaviour rather than the assumptions used for human users or static automation.
- Shadow AI: Shadow AI is the use of AI tools or agents inside an organisation without formal approval, visibility, or governance. It creates hidden access paths, unmanaged data exposure, and gaps in lifecycle control because security teams cannot review or constrain what they cannot see.
- Task-scoped identity: Task-scoped identity is an access model that limits an agent or workload to one defined purpose, with permissions sized to that task only. It is useful because it reduces blast radius and makes it easier to distinguish legitimate execution from scope creep or unintended delegation.
- Supervised autonomy: Supervised autonomy is a governance pattern where an AI agent can prepare or propose actions, but a human must approve specific high-risk outcomes before they complete. It preserves the speed of machine execution while keeping irreversible decisions inside a reviewable control boundary.
Deepen your knowledge
NHI governance, agentic AI identity, machine identity security, and identity lifecycle management 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 programme maturity, it is worth exploring.
This post draws on content published by JumpCloud: Zero Trust for AI and the trust trap in autonomous work. Read the original.
Published by the NHIMG editorial team on 2026-04-30.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org