Agentic AI Is Here. Your Security Model Isn’t Ready.

The rules of AI security just changed. On 10 December 2025, OWASP released their Top 10 for Agentic Applications, the culmination of over a year of research and input from more than 100 security researchers and practitioners. This isn’t an incremental update to existing frameworks. It’s an acknowledgement that agentic AI represents a fundamentally different threat model, one that most organisations are woefully unprepared to address.

The numbers tell a stark story. Eighty percent of organisations report they’ve already encountered risky behaviours from AI agents, including improper data exposure and unauthorised system access. Yet only 21 percent of executives claim complete visibility across agentic AI behaviours, permissions, tool usage, or data access. That gap between exposure and oversight is where breaches happen.

Why Agentic AI Breaks Traditional Security Models

Traditional AI security focused on prompt injection, output filtering, and model alignment. These concerns remain valid, but agentic AI introduces something entirely different: autonomous execution. Agents initiate actions based on goals and environmental triggers that might not require human prompts or approval. They persist context across sessions. They chain tools together. They make decisions.

This creates risk categories that simply didn’t exist before. Unauthorised actions. Runaway processes. Decisions that exceed intended boundaries. An agent isn’t just answering questions; it’s acting on your infrastructure with whatever permissions you’ve granted it.

OWASP’s Agentic Security Initiative has catalogued 15 categories of threats that map directly onto an agent’s architecture, spanning memory and planning through to tool usage, inter agent communication, and human interaction. Three risks dominate their Top 10: Agent Behaviour Hijacking, Tool Misuse and Exploitation, and Identity and Privilege Abuse.

Memory Poisoning: The Persistence Problem

Unlike traditional AI models that forget after each session, agentic systems maintain context across interactions. This persistence is both their strength and their liability.

Memory poisoning attacks corrupt an agent’s short term or long term memory with malicious or misleading data. Once poisoned, that corrupted context influences every subsequent decision the agent makes. The attacker doesn’t need to compromise the model itself. They just need to feed it the right information at the right time, and that information persists.

This is particularly insidious because the agent continues to operate normally from its own perspective. It’s making decisions based on its context, which happens to include attacker controlled data. Detection requires monitoring not just what the agent does, but what it believes.

MCP: The Protocol Everyone Uses and Nobody Secures

The Model Context Protocol has become the de facto standard for connecting AI models to external tools, with over eight million weekly SDK downloads. It’s elegant, it’s flexible, and it wasn’t designed with security first.

A recent study found that 7.2 percent of MCP servers contain general vulnerabilities, while 5.5 percent exhibit MCP specific tool poisoning. These numbers will climb as adoption accelerates.

Indirect Prompt Injection via Tools

LLMs will trust anything that can send them convincing sounding tokens. This makes them extremely vulnerable to confused deputy attacks. Any time you mix tools that perform actions with exposure to potentially untrusted input, you’re effectively allowing attackers to make those tools do whatever they want.

MCP creates a new attack vector here. Attackers craft malicious messages containing hidden instructions. These appear harmless to human reviewers but contain embedded commands. When shared with an AI assistant, the injected commands trigger unauthorised MCP actions. The agent becomes an unwitting proxy for the attacker.

Tool Poisoning: The Description Is the Payload

This one is elegant in its simplicity. Malicious instructions can be hidden in tool descriptions themselves, visible to the LLM but not normally displayed to users. A malicious MCP server can inject prompts through tool descriptions to manipulate AI model behaviour without being explicitly invoked.

The tool doesn’t need to be called. Its mere presence in the agent’s context is enough to influence behaviour. Users approve what looks like a harmless integration, never realising the description contains instructions that will be silently processed.

Tool Mutation: The Bait and Switch

MCP tools can mutate their own definitions after installation. Users approve a safe looking tool initially, complete their security review, and move on. Later, the tool quietly changes its behaviour to perform malicious actions.

This exploits the gap between approval time and runtime. Most organisations review integrations once, at installation. They don’t continuously verify that the tool they approved is still the tool they’re running.

Session Hijacking and Confused Deputies

With multiple stateful HTTP servers, an attacker who obtains an existing session ID can send malicious events to a different server. Attackers can also exploit MCP proxy servers that connect to third party APIs, creating confused deputy vulnerabilities. This allows malicious clients to obtain authorisation codes without proper user consent.

The MCP specification includes a notable line: “There SHOULD always be a human in the loop with the ability to deny tool invocations.” Security practitioners should treat that SHOULD as a MUST.

Securing Agentic Deployments

The good news is that mature security practices exist. The challenge is applying them consistently.

Identity and Access Control

Every AI agent must have a verifiable identity, just like a human user. Strong cryptographic credentials combined with attribute based access controls ensure agents operate only within approved boundaries.

Agents act like digital workers. They need their own identity through unique service accounts for tool access, Kubernetes pod identities for containerised deployments, or workload identities in cloud environments. They need strict rules regarding what they can and cannot do. And they need mechanisms ensuring they cannot escalate privileges without proper oversight.

Runtime Monitoring

Since agents operate continuously, real time monitoring of their actions is critical. Behavioural baselines help detect unusual activity such as sudden spikes in tool usage or abnormal data access patterns. These signals should integrate into SIEM platforms for faster detection and response.

This is where memory poisoning becomes detectable. If an agent suddenly changes behaviour patterns without corresponding changes to its instructions, something has influenced its context. That anomaly is your signal.

MCP Specific Controls

For MCP deployments, server side controls are essential. MCP proxy servers must maintain a registry of approved client ID values per user, check this registry before initiating third party authorisation flows, and store consent decisions securely.

The consent UI must clearly identify the requesting MCP client, display specific API scopes being requested, show the registered redirect URI, implement CSRF protection, and prevent iframing via Content Security Policy directives. MCP servers must not accept any tokens that were not explicitly issued for them.

Build pipeline security matters equally. Build MCP components on pipelines that implement Static Application Security Testing. Implement Software Composition Analysis so known vulnerabilities in dependencies are identified and fixed. Verify the integrity of all dependencies and scan them for malware.

The AWS Scoping Matrix

AWS has developed the Agentic AI Security Scoping Matrix, a framework that categorises four distinct agentic architectures based on connectivity and autonomy levels and maps critical security controls across each. It distinguishes between agency, the scope of actions an AI system is permitted to take, and autonomy, the degree of independent decision making without human intervention.

This distinction matters. A high agency, low autonomy agent with human approval gates poses different risks than a low agency, high autonomy agent operating independently within narrow bounds. Security controls should reflect these differences.

The Path Forward

The OWASP GenAI Security Project has released several practical guides: the Top 10 for Agentic Applications 2026, A Practical Guide for Securely Using Third Party MCP Servers, the Securing Agentic Applications Guide 1.0, and Agentic AI Threats and Mitigations.

These resources provide concrete, actionable guidance. But resources alone aren’t enough. Organisations need to accept that agentic AI represents a new category of risk that requires new categories of controls.

The agents are already deployed. The question is whether your security model has caught up.

References

  1. OWASP Top 10 for Agentic Applications 2026

  2. OWASP Agentic AI Threats and Mitigations

  3. OWASP Securing Agentic Applications Guide 1.0

  4. OWASP Practical Guide for Securely Using Third Party MCP Servers

  5. Model Context Protocol Specification

  6. AWS Agentic AI Security Scoping Matrix

  7. Cato Networks MCP Security Best Practices