Every developer asking “Is my AI trustworthy?” is asking the wrong question. The real question is: what can a malicious repository do to your AI? AI coding agent security isn’t about whether Cursor or Claude Code is well-built — it’s about what happens when your agent faithfully executes instructions hidden inside a README, a GitHub Issue, or a `.cursorrules` file from a repo you just cloned. With 95% of developers now using AI coding tools at least weekly, the attack surface has grown faster than our threat models. This guide gives you the mental model shift you need — and then the concrete, tool-specific steps to lock down your setup before someone else does it for you.
The Threat Model You’re Probably Missing: Your AI Coding Agent Trusts Everything It Reads
The assumption baked into most developer setups is dangerous: your AI agent reads a file, interprets it as data, and does something useful. In reality, there’s no enforced boundary between “data” and “instruction” in the context window. A markdown file containing `` looks like a comment to you. To your agent, it might be a command.
This pattern — indirect prompt injection — doesn’t require an attacker to touch your AI system directly. They need only place malicious instructions somewhere your agent will read. That could be:
- A README in a public repo you cloned
- A GitHub Issue you asked your agent to summarize
- A commit message in a dependency’s history
- A `.cursorrules` or `CLAUDE.md` file in an untrusted project
According to a 2026 meta-analysis of 78 studies (arXiv:2601.17548), attack success rates against state-of-the-art defenses exceed 85% when adaptive strategies are used. Even baseline success rates run from 50–84% depending on your model configuration. These aren’t theoretical edge cases.
The mental model upgrade: treat every file your agent reads as a potential attacker instruction, not just passive data. Once you internalize this, the rest of the hardening decisions become obvious.
What the 7-Client Study Actually Found (And Why Cursor Is the Riskiest Tool in Your Stack)
In March 2026, researchers published arXiv:2603.21642 — “Are AI-assisted Development Tools Immune to Prompt Injection?” — empirically testing seven real MCP clients: Claude Desktop, Claude Code, Cursor, Cline, Continue, Gemini CLI, and Langflow.
5 out of 7 clients apply zero static validation to tool inputs. They trust whatever a tool description or server response tells them. A malicious MCP server can instruct your agent to do almost anything the agent is capable of — and your client won’t flag it.
Cursor’s rating is the most concerning: Critical risk across all four attack vectors tested:
- Reading sensitive files (`.env`, SSH keys, API credentials)
- Logging and exfiltrating tool invocations
- Serving phishing links in generated output
- Executing remote scripts via fabricated tool priority claims
The MCP protocol itself amplifies the problem. A separate study (arXiv:2601.17549) found MCP increases attack success rates by 23–41% compared to equivalent non-MCP integrations — due to three protocol-level flaws: absent capability attestation, unauthenticated bidirectional sampling, and implicit trust propagation in multi-server configurations.
The broader context makes this more urgent. Prompt injection attacks surged 340% in 2026. Tool misuse via prompt injection triggers unauthorized actions in 31% of evaluated agent scenarios.
Only 11% of enterprises have security tooling specifically designed for AI systems — despite 73% of engineering teams using AI coding tools daily. The gap between adoption and protection is exactly where attackers operate.
The Four Attack Vectors Targeting AI Coding Agents Right Now
Understanding the specific attack patterns makes hardening feel less abstract.
Tool poisoning via MCP server descriptions (MCPoison)
MCP server descriptions — the text that tells your agent what a tool does — are not validated by most clients. An attacker who controls a public MCP server (or compromises one) can inject instructions directly into the tool description field. Your agent reads it, treats it as authoritative, and acts accordingly. Researchers named this MCPoison.
.cursorrules and CLAUDE.md injection
Both Cursor and Claude Code support project-level instruction files that shape agent behavior. This is useful by design — and a direct injection surface. When you clone a repo with a malicious `.cursorrules` or `CLAUDE.md`, you may be handing an attacker a persistent instruction channel into your agent. Never apply these files from untrusted repositories without reviewing their full contents first.
Cross-tool poisoning (CurXecute)
This attack uses one compromised tool to manipulate the behavior of another tool the agent trusts. Because MCP multi-server configs propagate trust implicitly, a low-privilege tool can potentially instruct a high-privilege one. The agent stitches together tool outputs without enforcing a security boundary between them — and the attacker exploits that seam.
Remote script execution via fabricated tool priority
The most alarming vector: a malicious tool description claims elevated priority over other tools and instructs the agent to execute a remote script as a “required” workflow step. Since agents generally cannot verify tool priority claims, they comply. Combined with default full-filesystem and shell access on most developer machines, this is arbitrary code execution — triggered by a description string.
Hardening Cursor: Turning Off the Features That Make It Dangerous
Given Cursor’s Critical rating, these changes are non-negotiable:
Disable auto-approve for all MCP tool calls. Navigate to Cursor Settings → Features → MCP and ensure every tool action requires explicit confirmation. Auto-approve is what makes CurXecute work in under three seconds.
Audit your MCP server list ruthlessly. Remove any server you’re not actively using. Each connected server is an attack surface. For servers you retain, review their source code if available, or isolate them in a Docker container if not.
Add egress controls. Run Cursor in an environment where outbound network requests route through a proxy you control. Log all outbound connections. Many exfiltration attacks fail or get caught at this layer — even when the injection itself succeeds.
Review `.cursorrules` before applying. Before opening any cloned repo in Cursor, read the `.cursorrules` file in plaintext. Look for anything that instructs the AI to perform actions outside the project scope — especially parent directory traversal, environment variable reads, or references to external URLs.
Scope your workspace to the project directory. Don’t open your home directory (`~/`) as a workspace. MCP-connected tools only need access to the active project. Opening `~/` exposes `.env`, `.ssh/`, `.aws/credentials`, browser profiles, and everything else on your machine.
Securing Claude Code: Leveraging Its Built-In Controls and Closing the Gaps
Claude Code fared better in the 7-client study — but “better than Critical” isn’t a security posture.
Keep mandatory tool confirmation enabled. Claude Code’s confirmation prompts before tool execution are a meaningful friction layer. When a prompt injection fires, those prompts are the difference between an annoying alert and an attacker with shell access. Don’t disable them for speed.
Treat `CLAUDE.md` as a security boundary. The `CLAUDE.md` file shapes agent behavior at the project level. Before running Claude Code in any repo you didn’t author, read it. If there isn’t one, create one that explicitly scopes what the agent is allowed to do in this project context.
Scope MCP server permissions per project. Claude Code allows project-level MCP server configuration. Don’t use a global config that grants all servers to all projects. A database read server needed for one project should not be active when you’re reviewing an unfamiliar codebase.
Address the CVE-2025-59536 exposure. The Claude Code source code leak on March 31, 2026 — 513,000 lines of unobfuscated TypeScript exposed via a source map in npm package `@anthropic-ai/claude-code v2.1.88` — lowered the barrier for exploiting CVEs including CVE-2025-59536 (RCE via malicious repo configs). Update to the patched version immediately and audit any repos opened in Claude Code between March 28 and April 2.
Pin your Claude Code version. Don’t auto-update developer tooling. Review release notes for each version — especially now that the internal implementation is publicly documented.
GitHub Copilot & Cline: The Configuration Changes That Matter
GitHub Copilot
Copilot’s primary attack surface is what it reads as context, not what it executes as tools — but that surface is broad.
Audit GitHub Issues and PRs as injection vectors. CamoLeak (CVSS 9.6), patched in June 2025, demonstrated that attackers could embed invisible Unicode characters in Issues to silently exfiltrate code through Copilot completions. The specific vulnerability is patched; the underlying surface — Copilot reading attacker-controlled content — is not.
Scan every Copilot-assisted commit for secrets. Research shows Copilot-assisted repos have a 40% higher secret leakage rate than baseline (6.4% vs. 4.6%). Run `git-secrets` or Trufflehog on every Copilot-assisted commit before it reaches `main`.
Configure content exclusions. Copilot’s content exclusion settings can prevent it from reading specific files. Add `.env`, `.pem`, `.key`, and `credentials` to this list as a baseline.
Cline
Cline was flagged in the 7-client study for the same static validation gaps as Cursor. The Cursor mitigations apply directly:
- Require confirmation for every tool call
- Review each MCP server before connecting it
- Restrict workspace scope to the active project directory only
MCP Server Security: Least Privilege, Allowlisting, and Audit Logging
MCP servers are the permission layer of your AI coding stack. Most developers grant broad access because setup guides say to — not because the tasks require it. The five controls below close the most common paths to compromise.
Apply the principle of least privilege aggressively. Map what each MCP server needs. A code search server needs read access to your project directory. It does not need write access, shell execution, or outbound network access. Strip every permission that isn’t functionally required.
Allowlist tool calls — don’t blocklist. Rather than blocking dangerous actions reactively, define an explicit allowlist of what each server is permitted to do. Anything outside that list should fail loudly with a logged error.
Log every MCP tool invocation with: timestamp, tool name, input parameters, output summary, and the agent context that triggered it. Without this, you cannot determine what happened during a compromise — or whether one occurred. The OWASP Practical Guide for Secure MCP Server Development (February 2026) provides a reference schema.
Validate tool descriptions at load time. Before connecting to an MCP server, check that tool descriptions don’t contain instruction-like patterns — imperative verbs targeting the AI, references to overriding previous instructions, or commands that reference other tools. This doesn’t catch sophisticated attacks, but it stops low-effort ones.
Network-isolate MCP servers. Run MCP servers in containers with no outbound internet access unless they specifically require it. If a poisoned tool call attempts exfiltration via a network request, isolation stops the data from leaving — even if it doesn’t stop the injection.
Detecting a Compromise: What Agent Hijacking Looks Like in Practice
Layered defense frameworks can reduce AI agent attack success rates from 73.2% to 8.7% according to OWASP’s Agentic AI Security research. The final layer is detection — assuming a compromise gets through, you want to know fast.
Watch for these behavioral anomalies:
- File reads outside the active project directory, especially targeting `~/.env`, `~/.ssh/`, or `~/.aws/`
- Outbound network calls not explicitly initiated by you
- Shell commands that don’t match your recent prompt history
- MCP tool calls firing at unusual times — especially if you run background or scheduled agents
- Multiple rapid-fire tool calls in sequence, which often indicates injection-triggered automation
Set up alerting, not just logging. Logs you don’t review in real time are forensic artifacts after the fact, not detections. A simple script that tails your MCP audit log and fires a desktop notification for out-of-scope file reads or unexpected outbound MCP network calls gives you near-real-time visibility without a full SIEM.
Treat unexpected agent output as a signal. If your agent returns content that includes URLs you didn’t request, references “previous instructions,” mentions files you didn’t ask about, or generates code with undisclosed network calls — stop, review the logs, and treat the session as potentially compromised.
Rotate secrets immediately on suspicion. Don’t spend an hour confirming a compromise before acting. Rotate `.env` secrets, regenerate SSH keys, and revoke any API tokens accessible within the workspace scope. Unnecessary rotation costs minutes. An exfiltrated key can cost much more.
Lock It Down Before Someone Else Does It for You
AI coding agent security isn’t a vendor problem you can outsource. The 7-client study makes clear that the tools most developers depend on have real, documented vulnerabilities — and the March 2026 events demonstrated that attackers are paying attention. The mental model matters most: stop asking whether your AI is trustworthy and start asking what a malicious file in your project could instruct your AI to do.
Lock down MCP permissions, review project-level instruction files before applying them, enable audit logging, and know what agent hijacking looks like before you’re diagnosing it under pressure.
Start with one change today: open your MCP server config, map every permission currently granted, and remove anything that isn’t strictly necessary for the task it performs. That single step eliminates the most common path to arbitrary code execution in MCP-connected dev environments — and it takes less than fifteen minutes.