TL;DR: Enterprises are converging on a five-layer agentic AI security stack that spans discovery and governance, identity, runtime guardrails, MCP visibility, and continuous red teaming, according to Akto. The core issue is not prompt safety alone but controlling agent behaviour, tool access, and downstream actions before autonomous systems outpace governance.
At a glance
What this is: Akto maps agentic AI security to five layers that move from discovery and identity to runtime controls, MCP visibility, and red teaming, arguing that the stack is forming around control of actions rather than prompts.
Why it matters: IAM, NHI, and AI security teams need a shared model for where governance, identity, runtime enforcement, and testing belong as agents begin to invoke tools and trigger real business actions.
Context
Agentic AI security is the problem of governing systems that can select tools, call MCP servers, and trigger downstream actions without staying inside a single prompt boundary. In this article, Akto argues that the control plane is now fragmented across discovery, identity, runtime enforcement, MCP visibility, and adversarial testing.
The governance gap is not that enterprises lack AI security effort. It is that different teams are trying to own the same emerging action surface while agents, tools, and MCP experiments spread faster than inventory, ownership, and policy can keep up. That makes this a programme design problem for NHI, agentic AI, and adjacent IAM teams alike.
Key questions
A: They should build a single inventory of agents, MCP servers, tools, and data flows before deciding which team owns which control. Without that map, governance, identity, and runtime enforcement end up duplicated or missing, and shadow experiments become difficult to contain or review.
Q: Why do agent credentials create more risk than traditional IAM models expect?
A: Traditional IAM models assume the identity behind an action is stable enough to inspect, review, or challenge. AI agents can act continuously, reuse the same secrets across workflows, and complete work faster than human review cycles can respond. That makes credential possession an insufficient control unless the system also verifies the actor at the moment of action.
Q: What breaks when MCP servers are connected without a trusted control plane?
A: Discovery and execution become the same decision, which removes the ability to review who published a tool, who can call it, and what trail exists after use. That creates a governance gap between the registry and the real runtime path. Enterprises usually discover the problem only after tool sprawl makes audit and revocation inconsistent.
Q: How can organisations prove their AI controls are actually working?
A: Look for evidence that policy decisions are logged, sensitive prompts are being redacted or blocked when required, and approved AI interactions are traceable by identity and business context. Effective programmes produce audit-ready records, not just policy text. If the control cannot explain what happened in a session, it is not operational enough.
Technical breakdown
Why agentic AI changes the security boundary
Agentic systems change the security boundary because the protected object is no longer just model output. An agent can read data, choose tools, call MCP servers, and trigger workflows, which means the security model has to account for action, not only content. That creates a multi-layer control problem across identity, policy, runtime enforcement, and execution paths. In practice, the same agent may be governed in one place, authorised in another, and blocked in a third. Without a clear boundary, teams lose track of which layer owns what condition. Practical implication: define the action surface before buying controls.
Practical implication: define the action surface before buying controls.
How MCP changes visibility and enforcement
MCP introduces a distinct control point because it is the layer where agents gain abilities through tools and resources. Governance can inventory agents, but MCP-aware visibility shows which servers, tools, and resource paths are actually exposed at runtime. A proxy at this layer can enforce policy where the agent reaches for capability, rather than after the action has already propagated into downstream apps and APIs. That matters because shadow MCP servers and unmanaged tool exposure create blind spots even when identity and runtime controls exist elsewhere. Practical implication: treat MCP as its own policy boundary, not a side effect of general app governance.
Practical implication: treat MCP as its own policy boundary, not a side effect of general app governance.
Why continuous red teaming is part of the stack
Continuous red teaming exists because autonomous agents fail in ways that static test cases miss. The article points to objective drift, tool abuse, memory manipulation, and chained actions across tools as failure modes that only appear under adversarial pressure. That is not the same as prompt testing, because the system under test is an evolving action chain with policy, memory, and tool-use dependencies. Red teaming therefore validates whether governance, identity, runtime, and MCP layers hold together under pressure rather than only in a happy-path demo. Practical implication: test the full action chain, not isolated prompts.
Practical implication: test the full action chain, not isolated prompts.
Threat narrative
Attacker objective: The objective is to use agent access and tool reach to expand action scope until the agent can affect data, workflows, or customer systems beyond its intended remit.
- Entry occurs when agents are introduced through fragmented, bottom-up experimentation across departments, creating unmanaged tools, MCP servers, and workflows.
- Privilege exposure follows when those agents are given credentials, tokens, and tool access that exceed the intent of the owning team.
- Escalation happens as the agent uses its allowed tools to cross into sensitive data, downstream apps, and APIs without a single coordinating control plane.
- Impact is realized when unsafe behavior, data leakage, or harmful tool execution reaches production workflows and customer-facing systems.
Breaches seen in the wild
- 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.
- 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.
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 becoming an action-surface governance problem, not a prompt-safety problem. The article correctly shows that the security boundary now includes agents, tools, MCP servers, and downstream systems. That shift matters because governance models built around static applications do not describe how a runtime decision engine acquires and uses capability. Practitioners should treat control design as a question of who can initiate action, not only who can see output.
Identity is the first durable control plane for agents because credentials turn intent into reach. Once an agent can read data, call tools, and trigger workflows, it behaves as a non-human identity with credentials, tokens, and permissions that drift over time. That means over-privilege and shadow agents are not edge cases but expected failure modes in bottom-up adoption. The practical conclusion is that agent identity and lifecycle governance must be explicit, owned, and inventoried.
Runtime guardrails alone are insufficient unless they sit beside discovery and MCP enforcement. The article’s five-layer model is strongest where it separates policy definition from in-flight enforcement and from tool-boundary control. That separation reflects real enterprise conditions: teams may know an agent exists, yet still not know which MCP server exposes which actions. Practitioners should avoid treating runtime filtering as a substitute for visibility or authorisation design.
Continuous red teaming is the validation layer that keeps the stack honest. When agents can chain actions, static tests understate the risk because failures emerge only when the system is pressured across multiple tools and contexts. This is where agentic AI security departs from conventional AppSec, because the relevant failure is not a single bad response but a compounding action sequence. Practitioners should require adversarial testing that exercises the full path from tool request to downstream effect.
Five layers is the right market shape because different control problems sit at different enforcement points. Governance answers what exists, identity answers what it should access, runtime answers what it is doing, MCP answers how it reaches capability, and red teaming answers how it fails. That division will define vendor consolidation and buyer confusion through 2026. Practitioners should map products to the layer they actually govern before standardising on a platform.
From our research library:
- Gartner predicts that by the end of 2026, 40% of enterprise apps will feature task-specific AI agents.
- Read next: Agentic AI Identity Maturity Model
What this signals
Agentic AI visibility will be the first budget winner: enterprises cannot govern what they cannot inventory, and fragmented agent adoption makes inventory the prerequisite for every later control. That is why discovery, ownership mapping, and tool exposure visibility will matter more than isolated prompt filters in the next buying cycle.
Access review processes assume access persists long enough to be certified. When agents can request, use, and release capability inside a single workflow, the governance model has to move closer to issuance time and runtime enforcement.
Converging control layers will create programme pressure for IAM, AppSec, and cloud teams: the market is moving toward a shared action-surface model, but buying decisions will still fail if each team secures a different slice without a common operating picture.
For practitioners
- Map the agentic action surface Inventory agents, MCP servers, tools, data flows, and downstream APIs before assigning control ownership. The first decision is which teams own which action paths, not which vendor owns the most features.
- Separate identity from runtime enforcement Treat credentials, tokens, and permissions as the identity layer, then decide where behavioral checks and blocking should occur during execution. That separation prevents a single control from being asked to solve discovery, authorisation, and blocking at once.
- Establish MCP boundary controls Place policy enforcement where tools and resources are exposed so shadow servers and unknown integrations do not bypass governance. MCP visibility should show which capabilities an agent can actually reach, not just which agent exists.
- Build continuous adversarial testing into release gates Test objective drift, tool abuse, memory manipulation, and chained actions as part of the rollout path for any production agent. One-off prompt testing does not reveal how an agent fails when multiple tools are involved.
Key takeaways
- Agentic AI security is maturing into a layered control problem that spans discovery, identity, runtime enforcement, MCP visibility, and adversarial testing.
- The biggest gap is not model output safety but governance of tool access, action scope, and downstream effects across unmanaged agent deployments.
- Enterprises need a shared inventory and enforcement model before agent growth turns into invisible privilege and uncontrolled integration paths.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set 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 agent identity, tool access, and action scope. |
| ASI02 — Tool Misuse | The stack model treats unsafe tool use as a primary runtime and governance risk. | |
| ASI08 — Cascading Failures | The article emphasises chained actions across tools and downstream systems. | |
| Recommendation — Map agent privileges to ASI03 and restrict tool reach to the minimum action set each workflow requires. Use ASI02 to assess which tools an agent can invoke and block unsafe tool combinations before release. Test for ASI08 by simulating multi-step agent chains that can amplify a single failure into broader impact. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Agents are treated as non-human identities whose permissions can outgrow intent. |
| NHI-10 — Human Use of NHI | The article describes human teams creating and operating agents without clear ownership. | |
| Recommendation — Apply NHI-05 to review agent entitlements and remove any access that exceeds current task scope. Apply NHI-10 to assign named owners for each agent and stop informal human operation of shared credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing who and what can act across the agentic stack. |
| Recommendation — Use PR.AA-05 to centralise entitlement decisions for agents, tools, and MCP-connected resources. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Leaked tokens and agent tool reach create classic credential access and movement risk. |
| Recommendation — Map exposed agent credentials and tool paths to TA0006 and TA0008 when prioritising detections and containment. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is explicitly about organising AI security governance across teams and layers. |
| Recommendation — Use GOVERN to assign accountability for agent inventory, policy, and enforcement across the programme. | ||
Key terms
- Agentic AI Security: Agentic AI security is the discipline of securing autonomous AI systems that can take actions, use tools, and chain decisions without direct human approval at each step. It covers identity and access management for AI agents, prompt injection defence, tool call governance, credential scoping, and runtime monitoring. As agentic systems acquire real-world authority, API access, file writes, workflow triggers, the security model must treat them as non-human identities with explicit lifecycle controls, not trusted processes.
- MCP Boundary: The control point where an AI client reaches external tools through Model Context Protocol. It is where identity, authorisation, and logging need to be enforced so that downstream systems do not receive uncontrolled or untraceable requests.
- 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.
- Agent Surface: The full set of places where an AI agent can be configured, triggered, and allowed to act. In practice this includes SaaS platforms, cloud runtimes, and endpoints. The term matters because governance fails when teams only see one part of the path and miss how the agent behaves across the rest.
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.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org