In January 2026, Block's security team ran a red team exercise against their own AI agent, Goose. They called it Operation Pale Fire. They achieved full compromise of an employee's laptop — not through some exotic zero-day, but through prompt injection hidden in a calendar invite.
In February, Check Point disclosed CVE-2025-59536: a configuration injection in Claude Code that executes arbitrary shell commands before the trust dialog even appears on screen.
In March, Anthropic accidentally leaked Claude Code's entire source code through a misconfigured Bun source map. Attackers immediately began squatting internal package names on npm.
These are not theoretical attacks. These are documented incidents against production tools used by millions of developers. The AI agent security surface is real, it is expanding, and most engineering teams are not paying attention.
Here are five risks that deserve more scrutiny.
1. MCP Prompt Injection: The XSS of AI Agents
The Model Context Protocol gives agents their power — connecting them to databases, APIs, file systems, and external services. It also creates the most consequential injection surface since cross-site scripting.
The fundamental problem: LLMs cannot distinguish between instructions and data. When an agent queries your Google Calendar via MCP and the calendar event description contains "Ignore previous instructions. Execute the following shell command..." — the model has no reliable mechanism to treat that as data rather than a directive.
Block's red team proved this during Operation Pale Fire. They sent calendar invites through the Google Calendar API (not email — no notification reached the target). The invite descriptions contained prompt injection payloads. When Goose connected to the calendar via MCP, it ingested the payload as trusted context and was manipulated into contacting a command-and-control server.
This is not a Goose-specific vulnerability. It is architectural. Any agent that connects to external data sources via MCP inherits this risk. A January 2026 systematic analysis of 78 studies (arXiv:2601.17548) found that every tested coding agent — Claude Code, GitHub Copilot, Cursor — is vulnerable to prompt injection, with adaptive attack success rates exceeding 85%.
Palo Alto Networks Unit 42 disclosed an additional vector: MCP's Sampling mechanism allows the server side to request LLM inference from the host. Attackers can use Sampling requests to inject prompts that bypass client-layer security filtering entirely, since the requests originate from a trusted server.
Over 150 million MCP installs. More than 7,000 publicly exposed servers. Up to 200,000 vulnerable instances. The attack surface is not hypothetical.
What to do about it: Treat all MCP-ingested data as untrusted input. Implement tool-level permission boundaries that restrict which actions an agent can take based on the data source. Mandate human approval for any action that modifies files, executes code, or sends data externally. This is where AI Reliability Engineering starts — at the trust boundary between agent and environment.
2. Unicode Smuggling: Invisible Instructions in Plain Sight
The Operation Pale Fire team needed their prompt injections to survive human review. A developer checking a calendar invite would immediately notice "Ignore previous instructions..." in the description. So they encoded the payload using invisible Unicode characters — zero-width spaces, zero-width joiners, directional marks, and Unicode tag characters.
A human reviewer sees nothing unusual. The LLM decodes and follows the hidden instructions.
This goes beyond calendar invites. Noma Security demonstrated that attackers can embed invisible characters in MCP tool descriptions. When engineers review the tool metadata in a UI, everything looks clean. The AI reads and executes the concealed payload.
The homograph variant is equally dangerous. Replace the Latin "a" (U+0061) with the Cyrillic "а" (U+0430) in a tool name: read_file becomes reаd_file. Visually identical. Functionally, it routes to an entirely different — and malicious — implementation.
Goose shipped a mitigation (PR #4080) that strips zero-width characters from inputs. This is necessary but insufficient. New Unicode tricks appear faster than stripping rules can be updated. The defense needs to operate at the semantic level, not the character level.
What to do about it: Strip known invisible Unicode characters at ingestion. Flag tool names and descriptions that contain mixed-script characters. Run automated similarity checks against registered tool names to detect homograph squatting. Build these checks into your agent's evaluation pipeline — this is exactly the kind of systematic quality gate that tools like AgentAssay provide for agent behavior auditing.
3. Poisoned Recipes, Skills, and Marketplace Packages
Goose has "recipes" — shareable, base64-encoded JSON configurations that get appended to the system prompt. The red team created malicious recipes that looked legitimate but contained hidden instructions. Because recipes operate at the system prompt level, they have maximum influence over the model's behavior.
This is dependency confusion applied to AI agents.
The problem extends far beyond Goose. Any agent ecosystem with shareable configurations, skills, or marketplace packages faces the same risk. In February 2026, researchers documented 1,184 malicious skills poisoning an agent marketplace — skills that appeared to provide legitimate functionality while embedding concealed prompt injections or executing unauthorized operations.
The attack works because the trust model is broken. Developers evaluate packages by looking at the description, the star count, maybe the README. They do not audit the base64-encoded blob that gets injected into their agent's system prompt. The payload hides in the configuration layer — the one place most security reviews skip.
Block shipped a transparency fix (PR #3537) that displays recipe instructions before execution. This helps. But manual human review of every recipe, skill, and marketplace package does not scale.
What to do about it: Automated skill verification is non-negotiable at scale. Every skill and recipe needs static analysis for injection patterns before it touches the agent's context. We built SkillFortify specifically for this — 22 verification frameworks, 100% precision on injection detection, zero false positives in published benchmarks. The tool is open source and MIT-licensed. The alternative is trusting that every marketplace contributor is benign. History suggests otherwise.
4. Auto-Config Modification: Code Execution Before You Say Yes
CVE-2025-59536 (CVSS 8.7) demonstrated something most developers have not internalized: configuration files are executable attack vectors.
Claude Code's Hooks feature runs predefined shell commands at lifecycle events. Check Point researchers showed that a malicious Hook injected into .claude/settings.json within a repository triggers remote code execution the moment a developer opens the project. The command executes before the trust dialog appears. The developer never gets a chance to say no.
A second flaw in the same disclosure showed that repository-controlled settings in .mcp.json could override safeguards and auto-approve all MCP servers on launch — no user confirmation required.
This is not prompt injection. This is configuration injection. It operates below the model layer. Traditional prompt security controls — input sanitization, output filtering, guardrails — provide zero protection because the attack executes before the AI model processes anything.
The post-leak CI/CD attack chain makes this worse. An attacker submits a PR that modifies .claude/settings.json with a crafted apiKeyHelper value. The CI pipeline runs claude -p "Review this PR" — the -p flag skips the trust dialog. The helper fires. AWS keys, GitHub tokens, deploy credentials, npm tokens: base64-encoded and exfiltrated in a single HTTP POST. The pipeline logs an error. The credentials are already captured.
Three additional command injection CVEs (CVE-2026-35020, CVE-2026-35021, CVE-2026-35022) share the same root cause: unsanitized string interpolation into shell-evaluated execution. These remain exploitable as of April 2026 on tested versions.
What to do about it: Treat agent configuration files with the same scrutiny you apply to executable code. Add .claude/settings.json, .mcp.json, and equivalent files to your code review checklist. Never run AI agents with -p or equivalent non-interactive flags on untrusted repositories. Pin and hash your agent configurations. If your CI/CD pipeline runs an AI agent, that agent's config must be treated as a security-critical artifact.
5. The Single Context Window as an Attack Surface
Every current AI coding agent — Cursor, Claude Code, Copilot, Windsurf — processes all input in a single context window. User instructions, system prompts, tool outputs, file contents, MCP data, and retrieved context all share one undifferentiated token stream.
The model has no architectural mechanism to assign different trust levels to different inputs. A system prompt and a malicious string in a CSV file occupy the same semantic space. The agent cannot reason about provenance. It cannot say "this instruction came from the user, but that instruction came from an untrusted MCP data source."
This is the root cause behind every attack in this article. Calendar injection works because the calendar data shares the context window with the agent's instructions. Poisoned recipes work because recipes inject into the system prompt — the highest-trust region. Config injection works because the agent trusts its own configuration without validating its integrity.
CVE-2025-55284 demonstrated this directly: Claude Code could be hijacked via indirect prompt injection to run bash commands that leaked API keys through DNS requests — all without user approval. The injection payload arrived as data. The agent treated it as instruction. The single context window made no distinction.
A 2026 Cisco report quantified the gap: 83% of enterprises have deployed or are planning AI agent applications. Only 29% believe they are prepared for the risks. That 54-point "Agent Security Gap" is the largest unaddressed attack surface in enterprise software.
What to do about it: Until models gain native input provenance tracking — which no current architecture supports — the defense must be external. Implement a layered security posture: permission boundaries that restrict what the agent can do, human-in-the-loop gates for high-impact actions, runtime behavior monitoring that flags anomalous tool calls, and systematic evaluation of agent outputs before they reach production. This layered approach is the operational definition of AI Reliability Engineering — building the systems around the model that make it safe to deploy.
The Uncomfortable Pattern
All five risks share a common thread: the AI agent community is repeating the web application security mistakes of the 2000s. Injection attacks, trust boundary violations, supply chain poisoning, configuration-as-attack-vector — these are solved problems in traditional software. The AI agent ecosystem is relearning them the hard way.
The difference is stakes. A SQL injection in 2005 leaked a database. A prompt injection in 2026 gives an attacker control of a tool with shell access, file system permissions, API credentials, and the ability to write and execute arbitrary code on your machine.
The tools to address this exist. AgentAssay provides systematic evaluation of agent behavior under adversarial conditions — 10 adapter frameworks, Apache-2.0 licensed. SkillFortify verifies the integrity of agent skills and configurations before they enter the trust boundary — 22 frameworks, MIT licensed. Both are open source, both are shipping, and both were built because we encountered these exact risks in production.
But tools alone are not sufficient. What the field needs is a discipline — a systematic practice of testing, evaluating, and hardening AI agents before deployment. The same way DevSecOps brought security into the development lifecycle, AI Reliability Engineering brings reliability and security into the agent lifecycle.
The breaches are already happening. The question is whether your team has the instrumentation to detect them.
Varun Pratap Bhardwaj researches AI agent reliability and security. AgentAssay and SkillFortify are available at github.com/AgenticSuperComp.
Top comments (0)