Agentic AI security is the discipline responsible for protecting autonomous artificial intelligence systems against manipulation, privilege abuse, and data leaks. This involves safeguarding systems that don’t just answer questions, but plan, act, and make decisions within complex business workflows.
At Chakray, we know that connecting these autonomous agents to enterprise tools using the Model Context Protocol (MCP) exponentially multiplies the attack surface. In this article, we translate the OWASP Top 10 for Agentic Applications 2026 into sequenced architectural controls. Our goal is clear: to build robust defenses that can survive integrator turnover and internal team changes.
Why 91% of companies use AI agents, yet only 10% know how to govern them
According to the Okta AI at Work 2025 report —a survey of 261 C-suite and VP-level executives across nine countries —, 91% of organizations are already operating AI agents, but merely 10% have a mature governance strategy for their non-human identities (NHI). This isn’t just a simple configuration oversight; it’s a structural failure in the operating model that carries immense costs. Deploying agents with high-privilege static credentials, without segmenting their identities or establishing human approval workflows, leaves the door wide open. The cost of remediating such an incident involves millions in losses when combining technical containment, operational impact, and severe fines under regulations like the GDPR or the EU AI Act.
The OWASP State of Agentic AI Security v2.01 report gives us a reality check: the ten risk categories (ASI01-ASI10) already have documented vulnerabilities and production exploits. Attack vectors are no longer just laboratory scenarios. Therefore, it is no surprise that the PwC AI Agent Survey points out that 88% of executives plan to increase their AI cybersecurity investments in the coming months. They know the gap between rushed adoption and technical maturity is their biggest risk.
Goal Hijacking via indirect prompt injection: a real-world scenario
Imagine a DevSecOps team connects an AI agent to internal financial tools using highly privileged static credentials via MCP. Overnight, the agent gains unrestricted access to billing, contract, and payroll databases. During one of its routine tasks, it processes a seemingly harmless document hiding malicious instructions. Lacking a defense-in-depth approach (input/output guardrails, Dual-LLM architectures, and schema validation at the MCP Gateway) and solid protection against indirect prompt injection, the system doesn’t even flinch.
In a matter of hours, the agent suffers a Goal Hijack (ASI01) and exfiltrates 150,000 payroll records to an external server. There was no circuit breaker to stop the extraction, no Human-in-the-Loop approval workflow, or network egress restriction to prevent it from reaching an unauthorized external destination for such a massive data movement. The breach is discovered during a manual audit three days later. The root problem wasn’t purely technical, but a governance issue: no provider documented who was supposed to review the agent’s permissions or when to act upon an anomaly.
Goal Hijack (ASI01) attack sequence diagram
Mapping the OWASP Top 10 for agentic applications 2026 into controls
The OWASP Top 10 for Agentic Applications 2026 framework structures the ten critical risks of autonomous AI (ASI01-ASI10). While OWASP defines these risks in a neutral, agnostic way, we propose translating them into a real, executable architecture. Using tools like Keycloak (identity), API gateways like Apache APISIX or Gravitee, orchestrators like Workato, and integration via Apache Camel, here is how we map each risk to a specific control layer:
| ID | Risk | Control layer |
| ASI01 | Goal Hijacking | Input Validation + Human Approval |
| ASI02 | Tool Misuse | Policy Enforcement + Execution Limits |
| ASI03 | Identity & Privilege Abuse | NHI Governance + OAuth 2.1 with ephemeral credentials + mTLS/SPIFFE + ABAC evaluated outside the model |
| ASI04 | Agentic Supply Chain Vulnerabilities | Inventory Governance + Audit Trail |
| ASI05 | Unexpected Code Execution | Hardened Sandboxing (gVisor/Kata) + Egress denied by default + Circuit breaker |
| ASI06 | Memory Poisoning | Cryptographic Provenance, RAG memory isolation, embedding sanitization, and TTL (Time-To-Live) in agent context |
| ASI07 | Insecure Inter-Agent Communication | mTLS between agents + Message signing + Task schema validation + Trusted domain segmentation |
| ASI08 | Cascading Failures | Segmentation + Execution Limits |
| ASI09 | Human-Agent Trust Exploitation | Approval Workflow + Audit Trail |
| ASI10 | Rogue Agents | AI SBOM/Inventory + Plan-vs-execution anomaly detection + Kill switch with credential revocation |
To get the complete picture, the secure adoption guide from CISA and the Five Eyes provides five operational risk dimensions: privileges, design, behavior, structural, and accountability. Additionally, the comprehensive Checkmarx Zero research on MCP details 11 emerging risks within this protocol, highlighting privilege escalation and token leakage.
Authentication and authorization: NHI governance and Zero-Trust
We must treat every agent as a high-risk corporate user. Non-Human Identity (NHI) governance allows us to eradicate shared credentials. To achieve this, we assign each agent minimal scopes and use advanced patterns like OAuth 2.0 Token Exchange (RFC 8693) (for instance, implemented with Keycloak), enabling the agent to swap credentials for an ephemeral delegation of privileges.
Thus, applying the Least Agency principle means the agent only receives the strictly necessary permissions for its immediate task context, evaluated in real-time through attribute-based access control (ABAC). Furthermore, all communication must be shielded with mTLS. Instead of letting agents call APIs at their own discretion, we implement an MCP Gateway (running on APISIX or Gravitee) that acts as a centralized Zero-Trust checkpoint: if the security policy doesn’t approve the request, it simply doesn’t go through.
Segmentation and limits: sandboxing, circuit breakers, and prompt injection containment
Isolating agents with CPU, memory, and disk limits is only half the job, and not the most crucial one. A standard container is not a true security boundary against untrusted code: hardened runtimes (gVisor, Kata, Firecracker), read-only file systems, and seccomp profiles are essential. The other half is the network: egress denied by default with an allowed destination list, controlled DNS, and blocking the cloud metadata endpoint—which would otherwise hand over instance credentials. A compromised agent that cannot open an outbound connection cannot exfiltrate anything.
We also need emergency brakes, and it’s important not to confuse the two types. A circuit breaker is automatic, acts on a specific flow, and is reversible: it halts execution when a predefined budget (calls, time, read volume, cost) is exceeded and resets once normalized. A kill switch is manual and global: a human triggers it to stop an agent, and it must revoke its tokens in addition to killing the process, because a stopped agent with live credentials remains exploitable. Both must exist and both must be tested in simulations.
Lastly, we must accept an uncomfortable premise: indirect prompt injection cannot be solved by merely sanitizing input. The model cannot reliably distinguish data from instructions, and every filter can be bypassed; the Five Eyes agencies describe this as the most persistent risk in the agentic ecosystem. The defense must be architectural: assume the injection will succeed and limit what the agent can do afterward. That means Least Agency (only the tools required for the immediate task), authorization evaluated by a deterministic PDP outside the model, and out-of-band human confirmation for any irreversible action.
Observability, approval, and continuous traceability
Activity logging cannot be optional. We must log the agent’s identity, every request, the databases touched, latency, and errors. Ensuring the cryptographic provenance of the context guarantees that no one can tamper with the agent’s reasoning chain.
At the business level, Human-in-the-Loop workflows are non-negotiable for sensitive actions. We must clearly define which operations require human approval, who is responsible, and the expected SLA. Moreover, regulations like the EU AI Act and GDPR require an always-updated inventory of these components and auditable proof of their decisions.
From isolated controls to transferable governance
As seen in the initial scenario, when an agent suffers goal hijacking, the real issue is that no isolated control (whether sandboxing or mTLS) survives without an operational model backing it up. A solid governance framework endures even if we switch technology providers or rotate our internal staff. This turns a simple technical checklist into a living, auditable, and truly resilient process.
| Dimension | Tactical approach (temporary checklist) | Operational governance model (long-term) |
| Agent identity | Use of static credentials with no clear operational owner. | NHI segmentation in Keycloak with quarterly reviews by a governance lead. |
| Action approval | Requesting “human approval” as a broad recommendation without defining how or when. | Documented Human-in-the-Loop flow with strict SLAs and decision traceability. |
| Partner rotation | Security relies on the memory of the integrator who built the system. | Documented and transferable methodology; security survives regardless of who operates it. |
| Audit & traceability | Retrospective reports only during audits or severe incidents. | Continuous auditing, real-time AI inventory, and evidence ready for EU regulations. |
| MCP surface | Treated merely as another “technical risk,” isolated from infrastructure. | The MCP Gateway is governed as a natural extension of corporate API management. |
Practical implementation in 6 Steps
The sequence matters because each step relies on the previous one: without a unique identity per agent, there’s no policy to apply; without a gateway, there’s nowhere to enforce it; without isolation, it can be bypassed by directly calling the system; without observability, you don’t know if it works; and without evidence, human approval cannot be proven:
- NHI governance and OAuth 2.0: the identity team quarterly certifies each agent’s scopes in Keycloak, verifying no shared credentials or long-lived secrets exist. Recertification is triggered whenever an agent is onboarded, a new MCP server is connected, or a scope expands; it shifts to monthly for agents accessing personal data, financial data, or production systems.
- Centralized MCP Gateway: the API architecture uses APISIX or Gravitee to validate every agent call against company policies.
- Sandboxing, egress, and circuit breakers: infrastructure guarantees the agent runs in isolation, with no access to other agents’ credentials or the cloud metadata endpoint, and network egress denied by default except for an explicit allowed list of destinations.
- Total observability: security operations log and monitor every interaction with exact timestamps and identities.
- Approval workflows (Human-in-the-Loop): business and security delineate the list of critical actions requiring documented human intervention.
- Auditing and inventory: anomaly detection over MCP traffic and the registration of agents and servers into the inventory are automated, continuous processes, with alerts addressed immediately. The AI governance committee reviews the output biweekly—closed alerts, accepted exceptions, pending registrations—and consolidates the regulatory evidence package quarterly.
Diagram of Zero-Trust governance architecture for agents (MCP)
Regardless of the framework (LangChain/LangGraph, vendor agent SDKs, custom orchestrators), this model works because it assigns clear names and responsibilities to each control layer. High-level orchestration flows can be implemented over iPaaS platforms like Workato, delegating complex legacy system connections to intermediary microservices based on Apache Camel.
Is your organization migrating towards agentic AI architectures?
Minimize operational risks and ensure regulatory compliance from day one. To audit your infrastructure or implement a Zero-Trust governance framework, we invite you to contact our team of experts at Chakray.
FAQ
How do I verify that an AI agent only accesses the APIs and data I authorize?
By implementing NHI governance with attribute-based access control (ABAC). Each agent receives a unique identity, authenticates securely (mTLS), and the MCP Gateway acts as a centralized customs checkpoint, validating policies and logging every move.
What are the risks of giving an agent direct access to corporate databases?
According to the OWASP ASI, privilege escalation and goal hijacking are the gravest dangers. A simple prompt injection attack can cause the agent to exfiltrate thousands of records within hours. Sandboxing and mandatory human approval for critical actions are non-negotiable defenses.
How do we detect prompt injection attacks against our agents?
Detection relies on three signals, as filtering is unreliable. First, plan vs. execution deviation: tools invoked outside the approved plan. Second, egress: unauthorized destinations or anomalous outbound volume for that agent’s identity. Third, canary tokens in context: if they appear in an outbound call, a leak is confirmed. If any of these trigger, the circuit breaker halts execution and the agent’s tokens are revoked.
How do we handle authentication when an agent uses numerous tools?
Through identity segmentation. We use Keycloak (OAuth 2.0) to grant specific access per task, encrypt the channel with mTLS, and pass all requests through an MCP Gateway that verifies the inventory in real time.
How does securing the MCP protocol differ from protecting traditional APIs?
The MCP protocol is specifically designed to connect agents and tools with highly granular control. Traditional APIs use identity systems built for static applications or humans, not autonomous, ephemeral entities. The MCP Gateway understands and controls this agentic context.
What standards should we use for our audits?
Base them on the risks outlined in the OWASP Top 10 for Agentic Applications 2026 and the CISA/Five Eyes adoption guide. On a regulatory level, the GDPR and the EU AI Act will require evidence of cryptographic provenance and immutable logs of your agents’ decisions.
How do we prevent an agent from escalating privileges within our infrastructure?
Through three layers. Authorization: task-specific privileges and ephemeral credentials, ensuring there are no permanent permissions to escalate. Isolation: an environment with hardened boundaries, zero visibility into the underlying infrastructure, and no access to the cloud metadata endpoint or other agents’ credentials. Brakes: automatic circuit breakers based on budgets, and a manual kill switch that halts the agent and revokes its credentials. The kill switch should not be triggered “at the slightest deviation,” or the team will end up disabling it.
