Agentic AI security in 2026: identity and control gaps widen

At a glance

What this is: This analysis argues that 2026 is the inflection point for agentic AI security, as autonomous agents move into enterprise workflows faster than identity, permission and runtime controls are maturing.

Why it matters: It matters because AI agents behave like privileged non-human actors, so IAM, PAM and security teams need governance that covers delegation, verification and post-installation change, not just initial access.

By the numbers:

• Gartner predicts that 40% of enterprise applications will embed task-specific AI agents by the end of 2026, up from less than 5% in 2025.
• Palo Alto Networks found that machine identities already outnumber human employees by an 82-to-1 ratio in the enterprise.
• ClawSecure says 539 OpenClaw skills, or 18.7% of those audited, showed indicators of command-and-control callbacks, credential harvesting or data exfiltration endpoints.
• ClawSecure found that 99.3% of OpenClaw skills shipped without any permissions manifest, limiting least-agency enforcement.

Context

Agentic AI security now sits at the point where autonomy, identity and access control intersect. The shift is not simply that more software uses AI, but that AI systems are making decisions, using credentials and chaining actions across enterprise services without direct human approval.

That shift breaks the assumptions behind many existing controls, which were designed for human users, static software and point-in-time review. When an agent can keep acting, update itself and use inherited permissions, the governance problem becomes continuous rather than episodic. agent identity governance is the right starting point for that conversation.

Key questions

Q: What breaks when AI agents are given broad inherited permissions?

A: Broad inherited permissions break the assumption that access is tied to a narrow business need. The result is larger blast radius, weaker accountability, and faster propagation of mistakes or abuse across connected systems. A single compromised or misconfigured agent can then touch far more data and workflows than the original task required.

Q: Why do autonomous AI agents increase insider risk even when access is technically authorized?

A: Autonomous agents increase insider risk because authorization alone does not explain purpose. A headless agent can inherit legitimate access and still move data, trigger workflows, or expose information in ways humans never intended. Risk rises when security teams cannot see the action’s context, intended outcome, and data sensitivity together.

Q: How should security teams evaluate AI agent trust before production use?

A: Security teams should evaluate AI agent trust by combining identity posture, intended access, delegation paths, and governance metadata in one approval decision. The key question is not whether the agent is useful, but whether its runtime behaviour can be bounded before it reaches sensitive systems. Registries can support that decision, but they do not replace policy enforcement.

Q: Should organisations treat AI coding agents as part of IAM and PAM governance?

A: Yes, when those agents can act on code, data, or tools in ways that affect production risk. Their permissions should be scoped, reviewed, and audited like other privileged systems, especially when they interact with sensitive routes, secrets, or regulated data. The governance question is who can let the agent act, and under what policy.

Technical breakdown

Why autonomous agents break traditional identity boundaries

Traditional identity models assume a principal is stable enough to be enrolled, granted access, reviewed and eventually offboarded. Autonomous agents behave differently because they can be instantiated quickly, delegate actions across tools and operate with borrowed credentials on behalf of a human or application. That makes identity a runtime property, not just a directory record. The governance problem is not only who created the agent, but what authority it can assume, when that authority is valid and how it is revoked when the workflow changes. In practice, teams need to think about agent identity as a chain of delegation and verification rather than a single account object.

Practical implication: Treat agent identity as a governed runtime state, not a one-time registration event.

Why point-in-time scanning misses sleeper agent risk

Point-in-time scanning can tell you whether an agent or skill looked safe at installation, but it cannot prove the code remained safe after updates, dependency changes or marketplace repackaging. That is the sleeper agent problem: a benign package can become dangerous later without any change to the initial approval decision. Runtime integrity therefore matters more than first-pass approval. Security teams need continuous reassessment tied to code change, permission change and execution context, especially where agents can access shell commands, email, files or APIs. This is a control failure as much as a detection problem, because the trust decision was made once and then assumed durable. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Move approval from install time to continuous verification at execution time.

How least agency changes the agent security model

Least agency is the agentic analogue of least privilege, but it is stricter because an agent can decide when and how to act across multiple steps. The goal is to limit not just access scope, but decision scope, tool scope and action scope. An agent that can read data, accept untrusted instructions and execute tools creates the exact compound risk that security researchers describe as the Lethal Trifecta. In that model, the problem is not one risky permission in isolation. It is the combination of broad data access, untrusted inputs and unrestricted execution that turns a compromised agent into an insider at machine speed. See the Agentic AI Security Guide.

Practical implication: Constrain what an agent can decide and execute, not just what it can read.

Threat narrative

Attacker objective: The attacker wants to turn a trusted agent into a privileged execution path for stealing data, modifying systems or spreading malicious actions across enterprise workflows.

1. Entry occurs when a user installs or trusts an agent skill or workflow that appears legitimate but later becomes a security problem through update, compromise or malicious design.
2. Credential access follows when the agent operates with inherited permissions and can reach email, files, shell access or API tokens already available in the environment.
3. Escalation and lateral movement occur when the agent chains tools and actions across systems faster than human review can intervene, turning broad permissions into cross-system reach.
4. Impact is achieved through data exfiltration, configuration changes, code execution or other automated misuse that happens at machine speed.

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.
• Langflow Flodrix botnet 2025: Attackers used Langflow's unauthenticated code endpoint to dump AI servers' environment variables and enlist them in the Flodrix botnet.

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

Agentic AI security is now an identity governance problem, not just an AI safety problem. The article shows that the real risk emerges when agents inherit permissions, act on behalf of users and persist across workflows without a clear lifecycle. That makes identity, delegation and offboarding central controls rather than administrative details. Practitioners should treat agent identity as a first-class governance domain.

Least agency is the right concept for governing autonomous systems. The article correctly distinguishes useful automation from unconstrained autonomy, which is what creates machine-speed insider risk. Security teams need to limit decision scope, tool scope and action scope together, not separately. The practical conclusion is that the control boundary has to move earlier in the workflow.

Continuous verification matters more than static trust in agent ecosystems. ClawSecure’s discussion of sleeper agents, code updates and runtime checks shows that trust decisions decay quickly once an agent is installed. That is why point-in-time review cannot be the main control for agentic platforms. The practitioner takeaway is to govern access at execution time, not just at approval time.

OWASP ASI Top 10 captures the shift from application security to agent governance. The article aligns with a world where goal hijack, tool misuse and privilege abuse are no longer edge cases but core design threats. That changes how security architectures should be evaluated: by the degree to which they constrain autonomous actions, not by whether they can scan code after the fact. Teams should use agentic AI threat modelling to structure that review.

Machine identity scale is now large enough to change the baseline for access governance. The article cites an 82-to-1 machine-to-human ratio, which means many programmes are already operating in a world where non-human actors dominate access volume. That does not automatically make every machine identity an agent, but it does mean the identity plane is now the control plane for agentic risk. Practitioners should fold agent governance into existing NHI and privileged access programmes.

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.
• Read next: Agentic AI Identity Guide

What this signals

Agentic identity sprawl: once agents begin operating across email, files, APIs and code, the number of governed non-human actors grows faster than most identity programmes can inventory. That pushes security teams toward issuance-time controls, continuous verification and lifecycle ownership rather than periodic review alone.

The governance signal is clear: identity teams should expect agent-specific policy, audit and approval layers to become part of normal IAM and PAM operations, especially where agents can act with inherited authority. Treating agent behaviour as a side issue will leave the most powerful access paths outside the control model.

Gartner’s projection that 40% of enterprise applications will embed task-specific AI agents by the end of 2026 is a signal that policy design, not tool adoption, is now the limiting factor. Security programmes need control models that assume agent identity governance will be a routine requirement, not a future special case.

For practitioners

• Define an agent identity lifecycle Register every agent with an owner, purpose, delegated authority and retirement trigger so the identity record reflects how the agent is actually used.
• Enforce least agency by default Limit each agent to the minimum decision scope, tool scope and action scope needed for its task, and require explicit approval for higher-risk actions.
• Add runtime integrity checks Verify that an agent is running unmodified code before it is allowed to access email, files, shells or sensitive APIs, then re-check after updates.
• Review marketplace and skill trust assumptions Assume a trusted-looking skill can become hostile after publication or update, and tie trust decisions to continuous monitoring rather than static review.
• Map agent behaviour to agentic threat categories Use a structured threat model to test for goal hijack, tool misuse, privilege abuse and supply chain compromise across the agent lifecycle.

Key takeaways

• Agentic AI changes the identity problem because software can now take actions, use credentials and chain tasks without a human closing each step.
• The article’s evidence points to a widening gap between adoption and control, with exposed skills, hardcoded credentials and missing permission manifests showing how quickly risk scales.
• The practical response is to govern agent identity, limit delegated authority and verify runtime integrity before sensitive access is granted.

Related NHI Mgmt Group resources: Agentic AI Security Guide · Agentic AI Identity Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide

Key terms

• 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.
• Least Agency: The agentic equivalent of least privilege, the principle that AI agents should be granted only the minimum level of autonomy necessary to complete their designated task, and no more. Coined in the OWASP Top 10 for Agentic Applications 2026.
• Runtime Verification: Runtime verification is the practice of checking what an identity is doing while it is active, rather than relying only on provisioning-time controls. For autonomous agents, it means monitoring prompts, tool use, outputs, and policy violations as actions unfold so harmful behavior can be contained early.
• Sleeper Agent Risk: The risk that an AI agent or skill is safe when first approved but becomes dangerous later through updates, dependency changes or malicious repackaging. It is a governance problem because the original trust decision no longer matches the agent’s current behaviour.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners build the identity controls that autonomous systems now depend on.