The Problem: Your Agent Can't Tell Instructions From Attacks

Every instruction your AI agent reads looks exactly the same to it — whether it came from you, your developer, or an attacker. That single design reality is why OWASP ranks prompt injection as LLM01:2025, the number-one security risk for LLM applications, ahead of every other threat in its 2025 list.

The problem is architectural, not a bug waiting to be patched. LLMs process instructions and data as undifferentiated natural-language text — your carefully written system prompt, a user's question, and a malicious command hidden in a webpage are all just strings competing for the model's attention, as IBM explains. OWASP is blunt about the implications: given the stochastic nature of how models work, "it is unclear if there are fool-proof methods of prevention for prompt injection."

The vulnerability comes in two flavors:

• Direct injection — an attacker types malicious instructions into the prompt itself, overriding your developer instructions.
• Indirect injection — hostile instructions hide in content the agent reads autonomously: emails, web pages, documents, GitHub issues. Since 2024 this has become the dominant enterprise attack pattern.

Indirect injection is what makes agents uniquely dangerous. Security researcher Simon Willison calls the combination the "lethal trifecta" — an agent that has access to private data, ingests untrusted content, and can communicate externally. Remove any one leg and the attack collapses; leave all three and you have a confused deputy ready to be weaponized.

The empirical numbers are sobering. NIST testing found novel red-team attacks succeeded 81% of the time against upgraded Claude 3.5 Sonnet — one of the most hijack-resistant models available — and success rates climbed from 57% to 80% when attacks were simply retried 25 times. OpenAI reported that a 2025 attack on ChatGPT succeeded 50% of the time in testing.

For the agent-skills ecosystem, this cuts especially close. Rules File Backdoor attacks hid malicious directions in .cursorrules and copilot-instructions.md files that could fire shell commands — proof that instruction packages loaded into coding agents are a live attack vector, not a theoretical one. It's a key reason SkillzBench treats every skill, rule file, and instruction package as untrusted input until independently scanned, and why its per-agent loadouts are designed so an agent only sees what was explicitly chosen for it.

NIST calls this "the latest incarnation of an age-old computer security problem" — and like SQL injection before it, it won't be patched away. It must be architected around.

Why Agent Skills and Rule Files Are a Proven Attack Vector

Prompt injection against coding agents isn't a theoretical concern anymore — it has produced named CVEs, working exploits, and remote code execution on developer machines. The most alarming pattern: in every documented incident, the attack arrived through content the agent was supposed to load and obey.

The "Rules File Backdoor" attacks showed how attackers hid malicious directions in .cursorrules and copilot-instructions.md files — the exact configuration files coding agents read as trusted instructions. Those hidden directions could fire shell commands on the developer's machine. No exploit chain, no malware — just text an agent dutifully followed.

The GitHub MCP "Toxic Agent Flow" exploit worked the same way. A single booby-trapped public Issue on GitHub walked an agent across security boundaries, demonstrating how easily agents can be steered by content they encounter during routine tasks. And the damage scaled fast:

• CVE-2025-54135 — Cursor remote code execution via MCP prompt injection
• CVE-2025-53773 — GitHub Copilot RCE via prompt injection, scoring CVSS 9.6 and potentially compromising millions of developer machines
• EchoLeak — the first zero-click data exfiltration against Microsoft 365 Copilot, triggered by an email the victim never opened

The success rates behind these techniques are sobering. NIST testing found novel red-team attacks achieved an 81% success rate against upgraded Claude 3.5 Sonnet — one of the most hijack-resistant models available — versus 11% for the strongest baseline attack. Worse, because LLMs are probabilistic, retrying an attack 25 times pushed average success from 57% to 80%, according to NIST's technical analysis. An attack that "fails" nine times in a row may simply succeed on the tenth.

Now connect this to agent skills. A SKILL.md file is precisely the kind of content agents load and obey: natural-language instructions injected directly into context, often pulled from public repositories with no independent review. The rules-file incidents prove the vector works. The question for any team adopting skills is not whether the instruction file can carry malicious directions — it's whether anyone checked before the agent loaded it.

That's the gap SkillzBench is being built to close: security-scanning every skill version, pinning it to a commit SHA, and testing it in a sandbox before it ever reaches a live agent. Script-bearing skills are listed link-out only at launch precisely because the incident record says instruction packages are dangerous enough on their own. Treat every skill, rule file, and MCP-connected instruction package as untrusted input until someone has scanned it — because the attackers already are.

The Solution: Defense-in-Depth, Not Detection Magic

If a filter could stop prompt injection, this article would end here. It can't — and the experts are unusually blunt about why.

OWASP states plainly that "it is unclear if there are fool-proof methods of prevention for prompt injection," given the stochastic nature of how models work. NIST reached the same conclusion in its red-team evaluations, finding that novel attacks succeeded 81% of the time against one of the most hijack-resistant models available — and that success rates climbed from 57% to 80% simply by retrying the same attack 25 times.

OpenAI's own security team adds a crucial insight: the most effective real-world attacks increasingly resemble social engineering more than prompt overrides. Detecting a malicious input, they argue, becomes "the same very difficult problem as detecting a lie or misinformation." The conclusion: stop trying to catch every malicious instruction, and start constraining what happens when one gets through.

That reframing points to an architectural playbook, not a detection one:

• Treat the model as untrusted. Per OWASP's prevention guidance, keep authorization and least-privilege controls outside the model — never rely on prompt wording as an enforcement boundary.
• Sandbox execution and require human-in-the-loop approval for consequential actions, so a successful injection has limited blast radius.
• Pin every instruction package, skill, and rule file to a verified version, and re-scan when upstream changes land — a skill that was safe at install time can become dangerous later.

The Five Eyes intelligence agencies (CISA, NSA, and their UK, Canadian, Australian, and NZ counterparts) frame it the same way: assume agentic AI may behave unexpectedly, and prioritize resilience, reversibility, and risk containment over efficiency gains, as documented threat analysis summarizes.

This is why SkillzBench is being built around containment rather than detection: independent security scanning of every pinned skill version, sandboxed benchmarking, and per-agent loadouts where the agent only sees the tools and skills explicitly chosen for it. Script-bearing skills are listed link-out only at launch precisely because the blast radius of an unsandboxed script is unacceptable.

The attacker only needs one working prompt; defenders must block every malicious instruction across every input. Architecture, not magic, is how you win that asymmetry.

What This Means for the Agent-Skills Ecosystem

The rules-file backdoor attacks proved something uncomfortable: the same instruction files developers load into coding agents to make them smarter — .cursorrules, copilot-instructions.md, and by extension SKILL.md packages — are a proven delivery vehicle for hidden commands that can fire shell commands on real machines. Agent skills sit squarely in that blast zone, and the ecosystem has almost no defenses built for it.

The numbers make the stakes concrete. Published research has found that roughly 26% of agent skills carry at least one vulnerability, and the problem is worse than a static snapshot suggests. A skill that passed review at install time can become dangerous upstream when its maintainer pushes a new commit — or when a repository is transferred to a new owner. Pulling "latest" means trusting whoever controls the repo today, not whoever you vetted last quarter.

This is why the OWASP guidance maps so cleanly onto skills. The Prompt Injection Prevention Cheat Sheet is blunt: keep authorization and least-privilege controls outside the model, and never treat prompt wording as an enforcement boundary. Translated to skills, that means three practices:

• Treat every skill as untrusted input until it has been independently security-scanned — not just read by the author who published it.
• Pin to verified commit SHAs rather than pulling latest, so upstream changes can't silently alter what your agent executes.
• Test in sandboxes and re-scan continuously as upstream changes land — NIST found attack success climbed from 57% to 80% across repeated attempts, so one-time evaluation systematically understates risk.

NIST's broader warning reinforces the last point: aggregate metrics mask high-impact risks like remote code execution, so a skill that "mostly behaves" in testing can still carry catastrophic edge cases.

This is the gap SkillzBench is being built to close. Its approach — independent security scanning, version pinning to commit SHAs, sandboxed benchmarking, and per-agent loadouts where the agent only sees what was explicitly chosen — is essentially OWASP's least-privilege principle operationalized for the skills era. Instead of an agent inheriting every skill and tool in reach, each loadout deliberately removes parts of the "lethal trifecta": fewer untrusted instructions, fewer tools, less blast radius when an injection does land.

The market conversation is already shifting. Five Eyes guidance now tells organizations to assume agentic AI will behave unexpectedly and prioritize risk containment over efficiency — and skills are the fastest-growing supply chain for agentic behavior. The question is no longer just "does this skill help?" but "was this skill safe when I installed it, and is it still safe today?" Until the ecosystem can answer both questions with evidence rather than trust, every skill install is a small act of faith.

Your Action Plan: Hardening Your Agent Stack Today

No foolproof prevention for prompt injection exists — that's the consensus from OWASP, NIST, and IBM alike. But there's a wide gap between "no perfect fix" and "no defense," and the right checklist can shrink your attack surface dramatically. Here's what to do today.

• Audit everything your agents load. Every skill, rules file, and MCP-connected package is untrusted input until verified. The Rules File Backdoor attacks showed that .cursorrules and copilot-instructions.md files can smuggle hidden directions capable of firing shell commands, and the GitHub MCP "Toxic Agent Flow" exploit let a single booby-trapped public Issue lead an agent across security boundaries. Read what your agents read.
• Pin versions to commit SHAs. Pulling "latest" means your agent's instructions can change overnight without your knowledge. A skill that was safe when you installed it can become dangerous after an upstream update — pinning gives you a stable, reviewable baseline.
• Strip hidden instructions from instruction files. Prompt injection is effective precisely because LLMs process instructions and data as undifferentiated text — the model cannot reliably tell your trusted directives from attacker-controlled content. Remove anything in a skill file that tries to direct the agent beyond its stated purpose.
• Enforce least privilege per agent. The "lethal trifecta" — private data access, untrusted content, and external communication — is what turns injections into full compromise. Remove any one leg and the attack path breaks. Configure each agent to see only the skills and tools it actually needs.
• Require human approval for consequential actions. OpenAI's research shows the most effective real-world attacks resemble social engineering, and NIST testing found novel red-team attacks succeeded 81% of the time against upgraded Claude 3.5 Sonnet. Assume some attacks will land — constrain what a successful attack can actually do.

One more habit: re-scan whenever upstream changes. NIST found that single-attempt evaluations underestimate risk — attack success rates rose from 57% to 80% when retried 25 times — and stored injections can persist across sessions in memory and knowledge bases. A one-time audit is not a defense.

This is the gap SkillzBench is being built to close. Its planned per-agent loadouts let you toggle skills and tools so each agent only sees what was explicitly chosen, and every skill version gets pinned, security-scanned, and benchmarked in a sandbox — with re-scanning when upstream changes land. The waitlist is open now for early access to independent skill verification, trust scores, and loadout management. Until then, treat your agent's instruction files the way you'd treat any third-party code: untrusted until proven otherwise.