Agentic AI Security: The Threats That Target AI Agents and the Defences That Stop Them

Agentic AI security protects AI agents that plan, call tools, keep memory and hand work to other agents from being steered into harmful actions. The risk differs from chatbot risk because a manipulated agent acts: it moves data, changes records or runs code with real credentials. The OWASP Top 10 for Agentic Applications, published on 9 December 2025, names the main threats, led by goal hijack, tool misuse and identity abuse. The defences that hold are structural: least privilege per tool, sandboxed execution, egress control, approval for high-impact actions and a complete audit trail.

This guide covers the threat model and the defences a security architect needs to review before approving an agent for production. Two companion pieces go further into the controls that fail most often: permissions and identity for agents and what an agent audit trail must record. The AI agent governance and security handbook holds the full control specifications, from identity records to the containment ladder.

Why AI agents need a different security model from chatbots

A tricked chatbot produces a bad answer that a person may or may not act on. A tricked agent acts by itself, often several times, before anyone reads its output. Five properties create the gap.

The root problem sits in the model itself. OWASP’s agentic list states that agents cannot reliably tell instructions apart from the content they process, so any text an agent reads can try to redirect it. Security therefore cannot rest on the model refusing bad instructions. It has to limit what the agent is able to do when it follows one.

For agents in the EU AI Act’s high-risk categories this is also a legal duty. Article 15(5) requires high-risk systems to resist attempts by unauthorised third parties to alter their use, outputs or performance, naming data poisoning, model poisoning, adversarial inputs and confidentiality attacks. After the Digital Omnibus on AI, Regulation (EU) 2026/1744, the Annex III obligations apply from 2 December 2027; the guide to the EU AI Act for agentic systems explains which agents qualify.

Agentic AI threats: the OWASP Top 10 for Agentic Applications (2026)

The OWASP GenAI Security Project published its Top 10 for Agentic Applications on 9 December 2025. It condenses the longer Agentic AI – Threats and Mitigations taxonomy from February 2025 into ten entries, each mapped to the OWASP Top 10 for LLM Applications 2025. It also introduces least agency: an agent should have no more autonomy than its task needs, because autonomy that adds no value only widens the attack surface.

The entries chain: goal hijack is usually the way in, while tool misuse and privilege abuse decide how much harm follows. CVE-2025-32711, published in June 2025, is an AI command injection in Microsoft 365 Copilot that let an unauthorised attacker disclose information over a network; Microsoft scored it 9.3, and the attack, reported as EchoLeak, is OWASP’s first ASI01 example.

Agentic AI security frameworks to align with

No single framework covers agents end to end, but they fit together: OWASP supplies risks and test cases, MITRE ATLAS adversary techniques, MAESTRO a layered threat model, NIST the governance structure and ENISA the European threat picture.

Agent-specific US federal guidance is still forming. NIST’s Center for AI Standards and Innovation asked for input on securing AI agent systems on 12 January 2026, a draft NIST concept paper on agent identity and authorisation appeared on 5 February, and CAISI launched an AI Agent Standards Initiative on 17 February. No final NIST agent security guideline existed by early November 2026.

Google’s 2025 paper on secure AI agents compresses the design stance into three principles: agents need “well-defined human controllers”, their powers must be limited, and their actions and planning must be observable. For how these risks enter an enterprise risk register, see the companion guide to agentic AI risk management.

How to secure AI agents: eleven best practices

1. Least privilege and least agency for every tool

Grant each agent only the tools its workflow needs, scope each tool to the records and operations required, and default to read-only. MITRE ATLAS mitigation AML.M0027 states the rule that matters most for delegated agents: an agent acting for a user must not hold a permission that user lacks. Set autonomy action by action with bounded autonomy levels; identity models and a permission matrix are in the guide to AI agent permissions.

2. Sandbox anything that executes

Code an agent writes or receives is untrusted input running on your infrastructure. Run it in a sandbox built from a clean image for each run, with no network by default, no production credentials and limits on CPU, memory and time (ATLAS AML.M0032). The comparison of containers, gVisor and microVMs for agent code covers the isolation choices.

3. Control egress

Exfiltration needs a way out. Deny outbound traffic by default and allow only the destinations each tool documents, DNS included, since OWASP shows an innocuous approved tool leaking data through DNS queries. Segment agents, models, tools and data stores so one compromised component cannot reach the rest. See egress-controlled on-premises AI and zero-trust networking for AI workloads.

4. Filter inputs, proposed actions and outputs

Guardrails check what goes in, what the agent proposes to do and what comes out: schema validation on tool arguments, detection of personal data and secrets, policy classifiers and format checks. Guard models reduce risk rather than remove it, so treat them as one layer among several. The explainer on AI guardrails describes the layers, and the comparison of open-weight guard models covers classifiers you can run locally.

5. Contain prompt injection instead of trying to catch all of it

Design for the case where an injected instruction gets through. Keep untrusted content away from the component that decides which tool to call, restrict tool use once untrusted data enters the context (ATLAS AML.M0030), and ask a person to confirm high-consequence actions. The prompt injection prevention guide lists the techniques; for retrieval pipelines, see injection containment for private RAG.

6. Protect memory and retrieval from poisoning

Long-term memory turns a one-off injection into a persistent one. Validate what gets written, segment memory by user and task, record where each entry came from, expire entries nobody has verified and keep snapshots so a poisoned state can be rolled back. OWASP lists these measures under ASI06, and MITRE ATLAS covers the same ground as memory hardening (AML.M0031).

7. Vet MCP servers and other components as third-party code

Tools increasingly arrive as MCP servers, and a server acts with the authority of whatever calls it. The Model Context Protocol specification, revision 2026-07-28, requires servers to accept only tokens issued for them, and requires clients offering one-click setup of a local server to show the exact command and get explicit approval first. Published flaws show why: CVE-2025-6514 describes OS command injection in the mcp-remote package when it connects to an untrusted server. Admit components through a private MCP registry, pin them by version and hash, and route calls through an MCP gateway that enforces grants and logs each call.

8. Require approval for high-impact actions

Payments, deletions, external messages, access changes and anything irreversible should wait for a named person who sees exactly what will change. An approval only protects you if it can change the outcome: show the payload and its effect, bind the approval to one run and keep the approver separate from whoever configured the agent. See human-in-the-loop design for AI agents.

9. Monitor behaviour and keep a complete audit trail

Record every run end to end and watch for signs of misuse: a read from a sensitive store followed by an outbound transfer, unfamiliar tool sequences, rising denials or sudden spend. The record must also stand up as evidence, with tamper-evident storage and synchronised clocks; the AI agent audit trail guide sets out fields and retention rules.

10. Red-team before release and after every material change

Attack the agent as an adversary would: plant instructions in documents and tool results, push it toward out-of-scope tools, escalate through a second agent and try to slip past the approval step. Rerun the scenarios whenever the model, prompt, tools or data change, following the method in red-teaming an agent before production.

11. Prepare incident response and a kill switch

Contain in graduated steps: disable one tool for one agent, suspend the agent, revoke its credentials, stop the workflow, then close the egress path. Each step needs an owner and a rehearsal. The incident response playbook for private agents covers detection, containment and reconstruction.

Agentic AI security checklist

Use the table as a release gate: each line names evidence a reviewer can inspect.

Governance gaps that sit outside security, such as missing owners or unregistered agents, belong on the AI agent governance checklist. The CISO guide to multi-agent platform security adds questions for procurement.

What changes when agents run on-premises

Running agents in your own data centre, a private cloud or an air-gapped network moves the boundaries. It does not stop attacks from working.

What gets easier. Prompts, retrieved documents, tool results and logs stay inside your perimeter, so you can show where data went. Egress can be denied by default or, when air-gapped, removed entirely. Guard models run locally, your identity provider, SIEM and network controls cover agent traffic, and vendor access to production becomes something you grant and log.

What stays the same. Prompt injection, tool misuse, memory poisoning and insider misuse work on-premises exactly as they do in the cloud. An agent with broad rights inside the perimeter can cause as much damage as one outside it, and possibly more, because internal systems trust it.

What becomes your job. You patch the model servers, runtimes, MCP servers and sandbox hosts. You vet model weights and agent components before they enter the environment, which in a disconnected network means a controlled import path. You also own the logging pipeline, its retention and its protection. The guide to deploying agents on your infrastructure covers operations, and the review of what agent security reviews miss explains why the deployment model matters for exfiltration.

How VDF AI fits

VDF AI can be deployed in VDF’s managed cloud, in your own data centre, in a private cloud or VPC, in a sovereign cloud or on a fully air-gapped network. For the air-gapped case, VDF AI Router has a mode that keeps every request on local models, and its allow, deny and pin lists are applied before any model is called.

Agents built in VDF AI Agents receive their tools one grant at a time from an MCP-powered registry, so each agent’s tool access is limited to what its workflow needs, and role-based access control comes with every plan. High-risk actions stop at a human approval gate. For every run, the agent’s audit log and execution trace hold the request and the identity behind it, the retrieval hits, each tool call and its arguments, the model’s reply and the final output. Inside a workflow, permission-check answers allow or deny with the policy reason, and secrets-scan finds exposed keys, tokens and passwords.

Multi-agent work runs in VDF AI Networks: a Human Approval node pauses consequential steps for an accountable person, a Verification node checks evidence and conditions before the next stage, and Run Code nodes execute Python or JavaScript with limits and secrets. Above both, the AI governance platform records an owner, purpose, risk class and version for each agent, Network and model, and its kill switch can halt any one of them.