AI Agent Security: Why Traditional Cybersecurity Is Not Enough
87% of CISOs call AI agent security their top concern. Only 11% say they're actually ready. Here's the full threat surface traditional AppSec never covered.
A recent industry survey found that 87% of CISOs now name AI agent security their top concern. The same survey found that only 11% of organizations have mature safeguards actually in place. That 76-point gap is not a staffing problem. It's a sign that the security model most teams are running was built for a different kind of system entirely.
Traditional application security assumes a fixed, knowable attack surface: known inputs, deterministic code, a finite set of ways a request can go wrong. NIST's own framing of agentic systems, part of a new AI Agent Standards Initiative it launched in February 2026, states the problem precisely: agentic systems introduce risk by combining model outputs with software functionality, creating failure modes that operate at the system level, not the model level. An agent isn't just code with a vulnerability waiting to be patched. It's code that takes instructions from data it was never designed to distrust.
The one sentence to remember
A traditional application has a bug when its code does something the code wasn't written to do. An AI agent can be perfectly implemented, no bug anywhere, and still do something dangerous, because the model reading its input decided to.
This is a full threat-surface walkthrough: nine categories of AI agent security risk, grounded in real, documented cases from the last year, not hypotheticals, and where sandboxing fits as the one mitigation that helps against nearly all of them at once.
Why the Old Model Doesn't Cover This
The attack surface moved
A SQL injection exploits a flaw in how code handles input. A buffer overflow exploits a flaw in how code manages memory. Both are attacks on the code. Most AI agent attacks aren't attacks on the code at all, the code runs exactly as written. They're attacks on the judgment of the model deciding what that code should do next, using data the model was handed as part of a completely legitimate task.
That distinction is why firewalls, input sanitization, and static analysis, the standard toolkit, don't catch most of what follows. None of them were built to evaluate whether a retrieved document is quietly trying to manipulate a model's next decision.
1. Prompt Injection
Malicious instructions hidden inside content an agent reads, an email, a document, a web page, get treated by the model as legitimate direction rather than untrusted data. This is covered in full depth, including the real EchoLeak (CVE-2025-32711) and "Comment and Control" cases, in Prompt Injection and Agent Hijacking. Every other category on this list either enables prompt injection or is enabled by it, it's the foundational attack this whole threat surface is built on.
2. Tool Abuse
Even with no injection involved, an agent with legitimate access to a tool can be manipulated into using it in ways nobody intended, deleting instead of archiving, querying far more data than a task required, chaining several individually reasonable tool calls into a harmful sequence. The MCPTox benchmark, released in 2025, tested this directly: poisoned tool descriptions run against 45 real MCP servers and 20 leading AI models, measuring how reliably models could be steered into misusing tools they already had permission to call.
This is a different problem from a malicious tool
Tool abuse means a legitimate, correctly-built tool gets misused. A malicious tool, covered below, means the tool itself was never trustworthy to begin with. Both need different defenses.
3. Agent Identity
NIST's own National Cybersecurity Center of Excellence published a concept paper in February 2026 naming this gap directly: AI agents are commonly treated as generic service accounts, with no dedicated identity, authorization, or accountability controls of their own. An agent acting under a shared, powerful credential is indistinguishable from any other process using that same credential, including a compromised one. The full architectural fix, delegation instead of impersonation, scoped agent identities, and real audit trails, is covered in AI Agent Identity.
4. Excessive Permissions
The default failure mode when nobody scopes access deliberately: an agent ends up holding far more standing privilege than the task in front of it actually needs. This is exactly what turned the "Comment and Control" research, covered in the prompt injection article, from a clever proof of concept into real credential theft: AI coding agents connected to CI/CD pipelines held standing access to secrets they didn't need for the specific task at hand, and a single malicious pull request title was enough to reach them.
Excessive permissions turn every other item on this list into a bigger problem
Prompt injection, tool abuse, a malicious tool, a poisoned memory entry, all of them are bounded by whatever the agent is actually allowed to do. An agent scoped to read-only access on one system has a small blast radius no matter which of these techniques succeeds against it. An agent holding broad, unscoped credentials turns any single successful attack into a much larger one.
5. Data Leakage
Sometimes the goal isn't hijacking an action, it's quietly extracting data the agent has legitimate access to. In September 2025, security researchers at Koi Security discovered an npm package called postmark-mcp that mirrored a legitimate email-sending tool convincingly, until version 1.0.16 silently added code that BCC'd a copy of every email the agent sent to an attacker-controlled address. Anyone who installed the update got a functioning email tool that also happened to be exfiltrating every message through it.
6. Malicious Tools
The postmark-mcp case above is also the clearest example of this specific category, what Koi Security called the first confirmed real-world malicious MCP server: a tool that looks legitimate, functions correctly for months, and was never trustworthy from the moment it was published. Unlike tool abuse, there's no manipulation required at all. The tool does exactly what its author built it to do, and that was the problem from day one.
A working tool is not a trustworthy tool
postmark-mcp worked. It sent emails correctly. That's precisely why it went undetected for months, functioning correctly and behaving maliciously are not mutually exclusive, and an agent has no way to tell the difference on its own.
7. Supply-Chain Attacks
The malicious-package problem extends well past one npm listing. Across dozens of tracked 2026 campaigns, researchers have confirmed AI-specific supply-chain vectors moving from theoretical concern to active delivery mechanism: poisoned MCP server packages, hidden instructions embedded in .cursorrules files, manipulated CLAUDE.md project instructions, and compromised AI coding assistant startup hooks, each one a way to inject an attacker's instructions before a developer ever writes a line of their own code.
The uncomfortable framing: your agent's supply chain now includes every MCP server, skill, and configuration file it loads, not just the packages in your lockfile. Auditing dependencies used to mean checking a package registry. It now means checking what any of those newer artifact types are quietly instructing your agent to do.
8. Memory Poisoning
Agents with persistent memory, a database of notes, prior interactions, or retrieved context they trust across sessions, create a new target: corrupt what gets stored, and every future session inherits the corruption. In early 2026, a security researcher demonstrated exactly this against a customer service AI agent, submitting a carefully crafted support ticket that got written into the agent's own retrieval database as though it were legitimate prior context, then influencing every subsequent conversation that retrieved it.
This is prompt injection with a longer fuse
A normal prompt injection affects the request it arrived in. Memory poisoning affects every future request that happens to retrieve the poisoned entry, days or weeks later, long after the original malicious ticket is forgotten by whoever might have caught it at the time.
9. Model Manipulation
Distinct from prompt injection, which exploits confusion between instructions and data, model manipulation targets the model's own decision-making directly: adversarial inputs and jailbreak techniques specifically crafted to override a model's trained safety behavior, getting it to act against its own guidelines rather than tricking it about what its guidelines actually are. Where prompt injection smuggles in a fake instruction, model manipulation attacks the model's judgment about a real one.
Sandboxing: The Defense That Covers Almost Everything Above
Every category above assumes the agent can reach something worth attacking. Sandboxing is what limits what "reach" actually means, running tool execution and file operations inside an isolated, contained environment rather than directly on a host system, covered architecturally in AI Agents Are Not Chatbots and built hands-on, with real container isolation, resource limits, and a worked escape-attempt trace, in Build an AI Agent Sandbox.
Why this earns a place at the end of every list, not just one
A well-sandboxed agent that falls for a prompt injection, calls a malicious tool, or reads a poisoned memory entry still only has access to what that sandbox allows. It doesn't prevent any single attack in this list from succeeding. It bounds what succeeding actually gets an attacker, the same role excessive-permissions control plays for identity, applied at the execution-environment level instead.
What NIST Is Actually Doing About This
This isn't a distant standards effort. Since February 2026, NIST's Center for AI Standards and Innovation has run an active AI Agent Standards Initiative, developing voluntary guidance specifically covering identity and authorization, security and risk management, and monitoring and logging for agentic systems. Alongside it, the NCCoE's identity and authorization concept paper, the COSAiS project's work on SP 800-53 control overlays for single- and multi-agent deployments, and a planned AI Agent Interoperability Profile all point at the same conclusion this article opened with: the existing security and risk frameworks were built one layer below where agentic risk actually lives.
Threat Model Summary
| Category | Real example | Primary mitigation |
|---|---|---|
| Prompt injection | EchoLeak, Comment and Control | Treat all retrieved content as untrusted; see the dedicated article |
| Tool abuse | MCPTox benchmark findings | Least privilege, human approval on high-impact tools |
| Agent identity | Agents run as generic service accounts | Delegated, scoped agent identity; see the dedicated article |
| Excessive permissions | Comment and Control's CI/CD secrets | Scope credentials to the task, not the role |
| Data leakage | postmark-mcp BCC exfiltration | Audit what a tool actually does, not just what it claims |
| Malicious tools | postmark-mcp, the first confirmed case | Vet tool sources like any other dependency |
| Supply-chain attacks | Poisoned .cursorrules and CLAUDE.md files | Treat every loaded config and MCP server as a dependency to review |
| Memory poisoning | Poisoned RAG entry via a support ticket | Validate what gets written to persistent memory, not just what gets read |
| Model manipulation | Jailbreak and adversarial input techniques | Defense-in-depth beyond the model's own safety training |
The Bottom Line
None of these nine categories are exotic. Every one of them has a real, documented 2026 case behind it, not a research paper's hypothetical. What they share is the reason traditional cybersecurity tooling misses them: a WAF inspects a request for known attack patterns, not whether a retrieved document is subtly trying to redirect an agent's next decision. Static analysis finds bugs in code, not in a model's judgment about data it was handed in good faith.
The question worth asking about your own agent deployment
For each of the nine categories above, could you name the specific control you have in place, not the general one, "we use good practices," but the actual scoped credential, the actual sandbox boundary, the actual review process for a new MCP server? The 87-to-11 gap this article opened with exists because most organizations can answer that for maybe two or three.
The model didn't need a vulnerability. It just needed to trust something it was never supposed to.
Written by
Chetan Yamger
Cloud Engineer · AI Automation Architect · Modern Workplace Consultant
Cloud Engineer, AI Automation Architect, and Modern Workplace Consultant based in Amsterdam, Netherlands. Specializing in scalable, secure enterprise solutions with Microsoft Azure, Intune, PowerShell, and AI-driven automation using ChatGPT, Gemini, and modern LLM technologies.
Stay in the loop.
New articles, straight to you.
Deep-dive technical articles on Intune, PowerShell, and AI — no noise, no spam.
Discussion
Share your thoughts — your email stays private
Leave a comment