TL;DR: Autonomous AI agents now plan, call tools, and act inside sensitive environments, which makes visibility, ownership, and runtime control central to governance, according to Akto. Security can keep an agent uncompromised, but only governance answers who is accountable when the agent acts within its permissions and still causes harm.
At a glance
What this is: Akto argues that agentic AI security is no longer just a technical hardening problem, because autonomous agents can act, delegate, and cause harm inside approved access paths.
Why it matters: IAM, PAM, and NHI teams need to govern agent actions, ownership, and runtime limits because conventional security controls do not resolve accountability for permitted but harmful behaviour.
Context
Agentic AI changes the control problem because the system no longer only recommends an action, it can carry one out. Once an agent can access email, CRMs, cloud services, internal APIs, or databases, governance has to cover what it can do, who owns it, and how much operational reach it has.
That creates a real identity and access management intersection. Agentic systems behave like non-human identities in practice, but they also introduce governance gaps that pure security tooling does not solve. The core failure mode is not only compromise, but unowned, over-scoped, or insufficiently supervised action at runtime.
Key questions
Q: Why does agentic AI governance fail when one layer is missing?
A: Because each layer controls a different part of the AI lifecycle, and a gap in any one of them leaves ungoverned data, deployment, or runtime behaviour. Governance is cumulative only when policy can follow the system through all phases. Partial coverage creates the illusion of control without the enforcement needed to reduce risk.
Q: Why do autonomous agents increase the risk of hidden security failures across systems?
A: Autonomous agents can discover excess permissions, exposed credentials, unintended network paths, and weak integrations faster than humans can react. If they can collaborate, share techniques, and keep operating after controls change, the attack surface expands beyond a single model or sandbox. That makes visibility, identity, and authorization controls essential, because post-incident reconstruction is too late.
Q: What are the signs that an agent’s effective permissions are too broad?
A: Look for agents that can move from retrieval to mutation, inherit user or service credentials without separation, or reach multiple environments with the same identity. Those patterns show that assigned access and usable access are too far apart.
Q: How should organisations govern agent-to-agent delegation?
A: They should treat delegation as a formal governance boundary, not just an integration pattern. That means defining what data can move between agents, how inherited permissions are recorded, and when delegated actions require review. Without that, one agent can extend another's access in ways the original control model never saw.
Technical breakdown
Why agentic AI breaks the old security model
Traditional security assumes software behaves predictably and only within a pre-set workflow. Agentic AI can choose steps, call tools, and take different paths toward the same goal, which makes testing incomplete and behavior less deterministic. That means a technically secure agent can still produce unsafe or non-compliant outcomes if the workflow, permissions, or guardrails are too broad. The control problem shifts from preventing code execution to governing action scope, delegation, and runtime decisions across systems.
Practical implication: treat agent behaviour as a governance object, not just an application deployment.
Why ownership matters more than technical hardening
The article separates security from governance for a reason. Security can reduce compromise risk, but it does not assign accountability when an agent acts within its permissions and still causes harm. Agentic systems need business ownership, technical ownership, security ownership, and executive oversight because the question is not only whether the agent is safe to run, but who approved its purpose, limits, and ongoing operation. Without a named owner, oversight collapses into shared responsibility and no responsibility.
Practical implication: create explicit ownership for every agent before it reaches production.
How runtime control and lifecycle governance work together
Governance is not a launch-time checkpoint. The article frames a lifecycle from design through retirement, with visibility, policy, review, and runtime guardrails layered across that lifecycle. That matters because risk changes when agents gain new tools, new data access, or new delegated workflows. In multi-agent environments, permission inheritance and chained delegation can amplify errors or expand access unexpectedly, so runtime controls must enforce approved action sets while lifecycle reviews keep the model current.
Practical implication: govern agent permissions, approvals, and monitoring continuously across the full lifecycle.
Threat narrative
Attacker objective: The objective is to make a governed-looking agent produce harmful business or security outcomes without triggering a conventional compromise signal.
- Entry occurs when an agent is connected to email, CRM, cloud services, internal APIs, or databases and given operating permissions that exceed close supervision.
- Escalation happens when the agent chains tool calls or delegates across other agents, allowing one weak instruction or inherited permission to expand the blast radius.
- Impact follows when a technically functional agent still takes harmful, non-compliant, or unowned actions inside approved access paths, with no clear accountability for the outcome.
Breaches seen in the wild
- Meta Muse agent hijack 2026: An undocumented Muse setting let local malware hijack Meta's personal AI agent, steal its authentication material and abuse user access.
- SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
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 creates an accountability gap, not just a security gap. The article is right to separate compromise prevention from governance because a protected agent can still make harmful decisions inside legitimate permissions. That is a policy and ownership problem, not a perimeter problem. Practitioners should treat agent accountability as a first-class control plane, with named responsibility before deployment and not after an incident.
Agentic AI behaves like a non-human identity, but with wider delegation risk. Once an agent can call tools, query systems, and chain actions, it becomes an identity-bearing actor that must be inventoried, scoped, and reviewed. The distinctive risk is not only overprivilege, but permission inheritance across agent-to-agent workflows. That makes the identity governance boundary more dynamic than traditional service account management, and it demands runtime visibility rather than spreadsheet control.
Continuous ownership is the named governance gap this category now exposes. The article's strongest concept is that agent ownership cannot be assumed, shared, or deferred. When multiple teams share responsibility, oversight evaporates exactly when an incident occurs. A practical program therefore needs explicit business, technical, security, and executive owners, each tied to a defined decision right and control boundary.
Lifecycle governance is the only credible response to agent drift. Agentic systems change when tools, data sources, or models change, and those changes alter risk even if the code never looks obviously broken. That is why post-deployment review, change control, and continuous monitoring matter more than one-time approval. Security teams should align this with runtime policy enforcement and governance review, because agent risk is cumulative, not static.
Multi-agent orchestration is now a control problem in its own right. Chains of agents can obscure who made a decision, who inherited which permission, and where a bad instruction first entered the workflow. That means agent governance needs workflow-level accountability, not just per-agent inventory. The practitioner conclusion is blunt: if you cannot explain the delegation chain, you do not yet control the agentic system.
From our research library:
- Gartner predicts that AI systems will initiate 50% of all service requests by 2030, driven largely by agentic AI.
- Read next: Agentic AI Identity Maturity Model
What this signals
Continuous ownership is becoming the decisive governance concept for agentic AI. Programmes that only secure the model and forget the operating model will miss the point, because accountability has to survive deployment, delegation, and change. The governance question is not whether the agent is safe in a narrow sense, but whether someone can still explain and answer for its actions when it behaves as designed.
69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey. That signal matters because agentic AI turns visibility, ownership, and runtime privilege into living controls rather than static approval gates. Security teams should expect more pressure to treat agents as governed identities with continuous oversight.
For practitioners
- Inventory every agent and connected tool Create a live inventory of all AI agents, MCP servers, and connected tools, including where they run and what systems they can reach. Stale spreadsheets are not sufficient for runtime governance or accountability.
- Assign named ownership before deployment Map each agent to business, technical, security, and executive owners before it reaches production. Each owner should have a clear decision right for scope, change approval, risk acceptance, or oversight.
- Constrain agent permissions to approved actions Define the exact actions, data sets, and integrations each agent may use, then enforce those limits at runtime. The control objective is to stop the agent from stepping outside its intended rights even when the underlying system works normally.
Key takeaways
- Agentic AI changes the governance problem because a system can be technically secure and still cause harm through permitted actions.
- Visibility, ownership, and runtime control are the controls that matter most when agents can plan, call tools, and delegate across systems.
- The practical response is continuous agent governance, with named owners, scoped permissions, and lifecycle oversight from design through retirement.
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 AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic systems here hinge on delegated access, ownership, and permission scope. |
| ASI07 — Insecure Inter-Agent Communication | The article highlights chained delegation and multi-agent interactions as a governance risk. | |
| Recommendation — Map agent permissions to ASI03 and restrict delegated access to approved actions only. Trace inter-agent handoffs and enforce controls on context and privilege transfer. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agents function as non-human identities when they hold broad system access. |
| Recommendation — Review agent entitlements under NHI-05 and remove access beyond the minimum needed. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about accountability, oversight, and governance structure. |
| Recommendation — Establish AI governance accountability under GOVERN before agents reach production. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article's runtime-control theme maps directly to permissions and authorization management. |
| Recommendation — Apply PR.AA-05 to enforce least-privilege authorisations for every agent connection. | ||
Key terms
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
- Agent Accountability: Agent accountability is the ability to explain, verify, and review what an AI agent did and why it did it. For security teams, it means the agent’s decisions are traceable to evidence, scope, and ownership, so failures can be corrected instead of merely observed.
- Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
- Permission Inheritance: The practice of allowing access on one object to flow into related objects through defined traversal rules. It reduces duplicate configuration, but it also creates hidden privilege paths that must be understood and reviewed. In complex systems, inheritance is often the real source of effective access.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners turn identity control principles into operating models that security and governance teams can actually run.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org