RESEARCH · A reference map of AI-agent and LLM security risks in 2026, illustrated with real disclosed cases from our briefings. No new vulnerabilities were disclosed in this work.

AI agent security is the practice of defending systems where a large language model does not just answer questions but takes actions: reading files, calling tools, writing code, browsing the web, or operating other software on a user's behalf. The defining problem is that an LLM cannot reliably tell trusted instructions apart from untrusted data, so any text an agent reads (a document, a web page, a pull-request comment, a tool's output) can become a command it executes. That single weakness produces the whole 2026 risk landscape: prompt injection, sandbox and tool escapes, agent hijacking, autonomous weaponization, and insecure generated code. The durable defense is to treat every input as untrusted, constrain what the agent can do, and verify its actions continuously rather than trusting the model to behave. This page is Nexus Void's reference on the classes of AI-agent risk, why they differ from traditional application security, and how to defend an agentic system.

Every risk below is illustrated with a real, disclosed case from our daily briefings, so the taxonomy is grounded in what has actually happened, not hypotheticals. Where we cite a rate, it comes from our own reviewed data: across the studies we analyzed, roughly one in three AI-generated code samples contained a security vulnerability.

What is AI agent security, and how is it different from normal appsec?

AI agent security covers the risks that appear when an LLM is given agency: tools, memory, and the ability to act, not just generate text. Traditional application security assumes a clear boundary between code (trusted instructions) and data (untrusted input). An LLM agent erases that boundary. It ingests instructions and data through the same channel, the context window, and treats both as language to be acted on. That is why a defense built for SQL injection or XSS does not map cleanly onto agents: the "injection" is not into a parser, it is into the model's understanding of what it was asked to do.

The practical consequence is that guardrails built from wording (prompt filters, blocklists, model upgrades) are weak, because an attacker can rephrase the payload endlessly. The controls that hold are structural: limiting what data reaches the model as trusted, limiting what the agent is allowed to do, and checking its actions against policy independently of the model.

What are the main classes of AI-agent and LLM risk?

The 2026 landscape sorts into a handful of recurring classes. Each maps to real disclosed cases.

The pattern across all of them is the same root cause seen from different angles: the agent trusted something it read, or was allowed to do something it should not have been able to do.

Why is prompt injection so hard to fix?

Because it is a structural property of how LLMs work, not a bug in one product. The model reads instructions and data through one channel and cannot reliably tell them apart, so hidden text in a document, a web page, or a code comment can hijack its behavior. The Copilot for Word case is the clearest illustration: white-on-white instructions the model reads but a human cannot, which the agent then copies forward into new documents. The vendor blocked the specific wording and upgraded the model, and the attack class still worked, because the fix targeted phrasing rather than the underlying trust boundary.

The defensive lesson is to stop trying to sanitize your way out at the wording level. Detect and strip content styled to be invisible before it reaches the model, keep untrusted content out of the trusted-instruction path where you can, and never let the model's reading of a document be the only thing standing between an attacker and a privileged action.

What happens when an agent has too much access?

It becomes a confused deputy: a trusted actor an attacker can aim. When an agent can call tools, touch files, or reach internal systems, an injection does not just change what it says, it changes what it does. The Azure DevOps MCP hijack turned a hidden pull-request comment into commands an AI review agent carried out with its own privileges. Sandbox escapes are the same problem at the infrastructure layer: the JFrog/OpenAI case and the coding-agent escapes across Cursor, Codex, and Gemini CLI show agents reaching beyond the box they were meant to run in.

The control that matters here is least privilege for agents, the same principle you already apply to service accounts. An agent should hold the minimum tools and permissions its task requires, its actions should be checked against policy independently of the model, and high-impact actions should require a real authorization step rather than the model's say-so.

How do you actually secure an AI-agent system?

Treat the agent as an untrusted, over-eager intern with production access, and design controls accordingly. A practical baseline:

1. Treat every input as untrusted. Documents, web pages, tool outputs, and retrieved content are all potential injection vectors. Strip invisibly-styled content and isolate untrusted data from the trusted-instruction path.

2. Enforce least privilege on tools. Give the agent the minimum tools and scopes for its task; do not hand a summarization agent write access to production.

3. Verify actions independently of the model. Check what the agent is about to do against policy with logic the model cannot talk its way past, and gate high-impact actions behind explicit authorization.

4. Constrain and monitor the sandbox. Assume the model can be manipulated and contain the blast radius: strong sandboxing, egress controls, and monitoring of what the agent actually did.

5. Review generated code as untrusted. With roughly one in three AI-generated samples carrying a vulnerability, agent-written code needs the same security review as any external contribution.

6. Verify continuously. Test agent workflows adversarially and keep an inspectable record of what each agent ingested and did, so the control is evidenced rather than assumed. This is continuous verification applied to AI.

Our read

The uncomfortable truth of agentic AI is that the model is a trusted actor you cannot fully trust. It will faithfully carry out instructions it cannot tell apart from data, and the more tools you give it, the larger the consequence when it is fooled. The vendors' instinct to patch this with better prompts and newer models keeps failing because the problem is structural, not lexical. The programs that stay safe are the ones that assume the model will be manipulated and build the guardrails around it: untrusted inputs, least privilege, independent verification of actions, and continuous, evidenced checking of what agents actually do. Verifiable by design is not optional for agentic systems; it is the only thing standing between a helpful assistant and a confused deputy with your credentials.

Examples drawn from Nexus Void's disclosed-vulnerability briefings; the AI-generated-code vulnerability rate is from our review of published studies. All per-case examples link to full write-ups.

Explore the cluster: Continuous verification vs the annual pentest · Vulnerability prioritization: what CVSS misses · Securing AI-generated code · Pentesting for AI-built apps · Copilot for Word prompt injection · Azure DevOps MCP hijack

Frequently asked questions

What is AI agent security?
It is the practice of defending systems where an LLM takes actions, not just generates text: calling tools, reading and writing files, browsing, or operating other software. The central risk is that the model cannot reliably separate trusted instructions from untrusted data, so content it reads can hijack what it does. Defense centers on untrusted inputs, least privilege, and independent verification of the agent's actions.

What is prompt injection, and why can't it just be patched?
Prompt injection is when text an agent reads (a document, web page, or comment) is interpreted as an instruction and executed. It is hard to patch because it is structural: LLMs process instructions and data through the same channel. Blocking specific wording or upgrading the model does not close it, as the Copilot for Word case showed when the attack survived both fixes.

How is securing an AI agent different from normal application security?
Traditional appsec assumes a boundary between trusted code and untrusted input. An LLM agent erases that boundary by treating everything in its context window as language to act on. So parser-level defenses do not map cleanly; the controls that work are structural: limiting trusted inputs, limiting the agent's privileges, and checking its actions with logic outside the model.

What is the single most important control for AI agents?
Least privilege combined with independent verification of actions. If an agent can only do a little, a successful injection can only cause a little, and if a control outside the model checks every high-impact action against policy, the model being fooled is not enough to cause harm. Sandboxing and treating all inputs as untrusted reinforce this.

Is AI-generated code safe to ship?
Not without review. Across the studies we analyzed, roughly one in three AI-generated code samples contained a security vulnerability. Treat agent-written code as an untrusted external contribution: it needs the same security review, testing, and verification as any code from outside your team.