AI Coding Assistant Security: Controlling Source Code, Secrets, and Agent Permissions

In August 2025, attackers published malicious versions of Nx, a widely used JavaScript build system, to the npm registry. The payload was unusual. It did not carry much of its own logic for hunting secrets. It first checked whether the developer had an AI coding agent installed, and if one was present, it put that agent to work. Claude Code was launched with --dangerously-skip-permissions, Gemini CLI with --yolo, and Amazon Q with --trust-all-tools. Each of those flags switches off the confirmation prompts that normally sit between the agent and the developer's filesystem.

No model was jailbroken in that attack, and no vulnerability in any of the agents was exploited. The malware borrowed permissions the developer had already granted: read access to the home directory, a working shell, and whatever credentials were sitting in environment variables and config files. That is the problem AI coding agent security actually has to solve. The risk is not only the code an agent writes. It is everything the agent is allowed to read, run, and send while it writes it.

This guide breaks that risk into three planes: what enters the agent's context, what the agent can execute, and where data can leave. It shows where the native controls in Claude Code, Cursor, and GitHub Copilot each stop, using the vendors' own documentation.

It then sets out a control framework you can enforce across every developer workstation, and explains how to red team your coding agents so the gaps surface in testing rather than in an incident review.

What Is AI Coding Assistant Security?

AI coding assistant security is the set of controls that govern what coding agents such as Claude Code, Cursor, and GitHub Copilot can read, execute, and send. It covers three planes: source code and secrets entering the model's context, shell and tool actions on the workstation, and data leaving through the network or MCP connections.

That definition is broader than most teams expect, because the tools themselves have changed. The first generation of coding assistants completed the line you were typing and had no ability to act on their own. The current generation works as an agent: it plans a task, opens files across the repository, runs terminal commands, installs packages, calls external services through the Model Context Protocol (MCP), and keeps iterating until the task is done, often with very little human review between steps.

Coding Agent

A coding agent is an AI coding assistant that can take actions in a development environment rather than only suggesting code. It reads and writes files, executes shell commands, and invokes tools on the developer's behalf, using whatever permissions the developer's user account and configured integrations already hold.

Because a coding agent acts, securing it means controlling three distinct things. Each one fails in a different way and needs its own control, which is why the rest of this guide is organized around them.

Why Are AI Coding Agents a Bigger Risk Than AI-Generated Code?

AI coding agents are a bigger risk than AI-generated code because the code is only the output, while the agent is an actor. An insecure function can be caught by review and scanning before it merges. An agent that reads your credentials or runs a command does so immediately, with your identity, before any review happens.

Most published guidance on this topic still treats it as a code-quality problem: scan what the model writes, catch the hardcoded key, block the vulnerable dependency at the pull request. That work matters, and we have covered it in depth in our analysis of security risks in AI-generated code. It does not address the larger exposure, which is what the agent is permitted to do on the workstation while it generates that code.

The data already shows both problems compounding. GitGuardian's State of Secrets Sprawl 2026 report found that Claude Code-assisted commits on public GitHub leaked secrets at a rate of 3.2%, compared with a 1.5% baseline across all public commits. The same research identified 24,008 unique secrets exposed in MCP configuration files, 2,117 of which were still valid when discovered. GitGuardian is careful to note that many of these leaks reflect human decisions rather than model failures, and that caveat is the point: agents increase the number of places where a credential can be written down, read, or passed along, and they do it at a speed that outruns manual review.

The tools themselves have also proven exploitable. The IDEsaster research disclosed in December 2025 found more than 30 vulnerabilities across ten AI-integrated development environments, and every one of the ten tools tested could be pushed into code execution or data exfiltration through prompt injection. Adoption is moving faster than defenses: Cisco's State of AI Security 2026 report found that 83% of organizations plan to deploy agentic AI, while only 29% feel prepared to secure it.

The Agent Inherits the Developer's Identity

A coding agent does not get its own restricted account. It runs as a process under the developer's user, which means it can typically reach everything that user can reach: the source tree, cloud CLI sessions in the GitHub CLI token, SSH keys and the SSH agent, environment variables, and every MCP server the developer has connected. In identity terms, a coding agent is a non-human identity holding a human's full privileges, with no separate owner, no scoped permission set, and usually no audit trail of its own.

That is what turns a single successful manipulation into a business problem rather than a local bug. The realistic consequences fall into four categories:

• Source code and IP exposure: proprietary code indexed into context and transmitted to model providers or unapproved tools, outside any data handling agreement your legal team has reviewed.
• Credential compromise and lateral movement: a cloud key or repository token read from the workstation becomes access to production infrastructure, far beyond the developer's laptop.
• Supply chain entry: a poisoned repository, package, or instruction file reaches every developer who opens it, and through them, every system those developers can push to.
• Audit failure: when an incident occurs, standard logs show a trusted developer process doing ordinary things, leaving security teams unable to reconstruct what the agent read, ran, or sent.

The organizations that handle this well stop treating coding agents as editor plugins and start governing them the way they govern any privileged identity. Before getting to the controls, it helps to see exactly how these attacks unfold in practice.

What Do Real Attacks on AI Coding Agents Look Like?

Real attacks on AI coding agents rarely break the agent itself. They feed it instructions through content it already trusts, such as a repository rules file, a GitHub issue, a project config, or a malicious package, and then let the agent use its own file access, shell, and network reach to move code or credentials out.

Every incident below is publicly documented. Read them as patterns rather than one-off bugs, because each one exploits a capability that coding agents need in order to be useful.

Rules-File Backdoors: Hidden Instructions in Files the Agent Treats as Configuration

In March 2025, Pillar Security disclosed the Rules File Backdoor, an attack against the instruction files that Cursor and GitHub Copilot load for project context, such as .cursorrules and .github/copilot-instructions.md. Attackers embedded instructions using zero-width joiners and bidirectional text markers, characters that render as nothing in an editor or a pull request diff but remain fully readable to the model. A poisoned rules file could direct the assistant to insert a backdoor into generated code, with nothing visible to the developer approving the change.

The reason this works is organizational as much as technical. Rules files get shared across teams, copied from public template repositories, and merged with far less scrutiny than a package.json change, because nobody thinks of them as code. GitHub has since added warnings for hidden Unicode in files, but the underlying trust problem remains: the agent treats these files as standing orders.

Issue and README Injection: When Routine Project Content Becomes a Command

The RoguePilot attack disclosed by Orca Security in February 2026 showed how little an attacker needs. They opened a GitHub issue with a prompt injection hidden inside HTML comments. When a developer launched a Codespace from that issue, Copilot received the issue text as context, followed the hidden instruction, and exfiltrated the "GITHUB_TOKEN", which was enough to take over the repository.

The attacker never touched the victim's machine, never phished a credential, and never needed write access to the repository. They only needed the agent to read text they controlled. That is the defining property of indirect prompt injection, and coding agents read untrusted text constantly: issues, pull request descriptions, dependency READMEs, documentation pages, and MCP tool responses.

Exfiltration That Looks Like Normal Traffic

Two Claude Code vulnerabilities show how exfiltration can hide inside ordinary developer activity:

• CVE-2025-55284 (Claude Code before v1.0.4): as documented by Embrace the Red, an injected prompt could make the agent read .env file contents and leak them by encoding the data into the subdomain of a ping request. The secrets left as DNS lookups, which most egress monitoring never inspects.
• CVE-2026-21852: Check Point Research found that a malicious ANTHROPIC_BASE_URL set in a project configuration file could redirect API traffic before any trust dialog appeared, capturing the developer's API key in plaintext. The same research covered CVE-2025-59536, in which malicious "SessionStart" hooks in project files achieved code execution the moment the agent launched.

Both issues have since been patched. The pattern has not gone away, because opening a repository runs a file-driven configuration process that most developers never inspect.

Supply Chain Packages That Weaponize the Agent

The Nx compromise described at the top of this guide was not an isolated case. In February 2026, Kodem Security documented SANDWORM_MODE, a family of 19 typosquatted npm packages. After a 48-hour delay, they installed a rogue MCP server into a hidden directory. The server registered innocuous tool names such as"index_projec" and "lint_check", with embedded instructions telling the AI assistant to extract SSH keys, AWS credentials, npm tokens, and environment variables, and to hide that activity from the user.

That is a meaningful shift in attacker economics. Malware no longer has to implement its own credential theft. It can delegate the job to an agent that already holds the developer's access. We have seen the same trust-in-a-third-party-integration pattern in OAuth-based supply chain attacks on AI infrastructure, and coding agents extend it to every package a developer installs.

What One of These Attacks Looks Like in Your Logs

Most security teams would not see any of these attacks happen. The reconstruction below follows the CVE-2025-55284 pattern: a repository instruction file tells the agent to read ".en"` and "verify connectivity" by pinging an encoded hostname. The left side shows what endpoint, SIEM, and proxy telemetry records. The right side shows what the agent actually did.

Every event on the left is individually legitimate. A signed "node" process belongs to a logged-in developer. Traffic to "api.anthropic.com" is sanctioned. The ".env" read is by the file's owner, and a single DNS lookup is routine. The attack only becomes visible at the agent layer, where you can see that a repository file issued the instruction, that six secrets entered the model's context, and that a shell command encoded them into a hostname. The two numbered points mark where an inline control would have had the information to stop it.

Incident-to-Control Mapping

Every one of these controls exists in some form today. The harder question is why so few of them are in place, and why the controls teams do have keep missing these attacks.

Why Don't Native Settings, SAST, DLP, or EDR Stop These Attacks?

Native settings, SAST, DLP, and EDR each cover one layer of a coding agent's activity. None of them evaluates what the agent intends to do at the moment it reads a file, runs a command, or calls a tool. Vendor controls stop at the edge of their own feature, and traditional tools see a trusted developer process doing ordinary things.

This is not a criticism of the vendors. Coding agents need terminals, network access, and repository context to be useful, and every built-in control is a reasonable trade-off between safety and getting work done. The problem is that each trade-off leaves a different gap. Most enterprises assume the combination covers more than it does.

Every Vendor Control Stops at a Different Layer

Read each tool's documentation carefully and a consistent pattern appears: every control is scoped to one surface of the agent, and the agent operates across several.

Native controls mapped against the three planes of a coding agent, based on vendor documentation as of October 2026.

• Claude Code: the Bash sandbox is off by default. When it is on, it isolates shell commands at the operating system level. By default, sandboxed commands can still read most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials, unless you explicitly deny them. Anthropic's documentation is also clear that the built-in file tools, local MCP servers, and hooks run outside the sandbox.
• Cursor: .cursorignore keeps files out of indexing and AI context on a best-effort basis. Cursor's own staff have confirmed that terminal commands and MCP tools can still read ignored files, because they run at the OS level where Cursor cannot intercept them. Privacy Mode governs whether providers store or train on your code. It does not stop the code relevant to a request from being sent.
• GitHub Copilot: content exclusion keeps files out of completions, chat, and code review. GitHub's documentation states it is not currently supported in the Edit and Agent modes of Copilot Chat in VS Code and other editors. That is exactly where an agent reads the most files. Copilot's MCP server allowlist controls which servers can connect, not which calls an approved server is allowed to make.

Put together, an organization running all three tools with every native control switched on still has no single point that sees an agent read a secret and then send it somewhere.

Why SAST, DLP, and EDR Miss Agent Attacks

Traditional controls fail here for a structural reason. They were built to inspect artifacts and patterns, and agent attacks produce neither in a recognizable form.

The gap is the one we see across AI security generally: traditional tools evaluate the syntax of activity, while agent attacks live in its intent. We cover that architectural gap in depth in our analysis of why AI needs a security layer beyond traditional controls.

Instruction Files Are Code, but Nobody Reviews Them That Way

Coding agents load standing instructions from files inside the repository and the user's home directory:

• "CLAUDE.md" and "AGENTS.md"
• ".cursorrules" and ".cursor/rules/"
• ".github/copilot-instructions.md"
• ".mcp.json"
• ".claude/settings.json", which can define hooks
• ".vscode/settings.json"

These files change what the agent does as directly as source code changes what an application does. A large language model cannot reliably separate instructions from data within a single context window, a limitation AWS lists as the top risk in its control framework for AI coding agents.

The vendors already know this. Claude Code's sandbox denies shell commands write access to ".claude" settings files, ".mcp.json", and the ".vscode" directory by default, because a command that could edit them could grant itself new permissions or register a hook that runs outside the sandbox. If the tool's own maker treats these files as privileged, your review process should too. Instructions planted this way can also persist across sessions, the same dynamic we examined in our threat model for memory poisoning in AI agents.

Where the Controls Sit in a Coding Agent's Architecture

Seen as an architecture, a coding agent sits at the center of four trust boundaries. Each boundary is a point where data or authority changes hands, and each needs its own policy.

1. Untrusted content into context (TB1). Repository files, issues, tool responses, and fetched pages all become model input. There is no native control here, which is why every attack in the previous section starts at this boundary.
2. Context to the model provider (TB2). Privacy Mode and content exclusion govern retention and partial scope, but code and context still leave the machine.
3. Agent to local shell and filesystem (TB3). Sandboxing can contain commands, but it is off by default and permits credential reads unless configured otherwise.
4. Agent to MCP servers and external services (TB4). Allowlists approve servers, not individual calls, so an approved server can still be used for an unapproved action.

The dashed boundary in the diagram is the missing piece: an enforcement layer that sits inline with the agent and evaluates each read, command, and tool call against policy before it executes. The next section shows how to build that control layer, starting with the steps you can take this week.

How Do You Control Source Code, Secrets, and Agent Permissions in AI Coding Agents?

You control AI coding agents by applying detection, classification, and enforcement to each of the three planes: what the agent reads, what it executes, and where data can leave. Enforcement has to come from a centrally managed policy that developers cannot override. Every read, command, and tool call should leave an audit record.

We call this the Read / Act / Reach control framework. It does not replace your existing AI coding assistant security controls, SAST pipeline, or secrets scanning. It adds the layer those tools were never positioned to cover: the agent's behavior on the workstation, at the moment it happens.

The six steps below put the framework into practice, in the order most security teams can roll them out.

Step 1: Inventory Every Coding Agent, IDE Extension, and MCP Server

You cannot secure coding agents you cannot see, so the first control is a continuous inventory of every AI coding tool running on developer machines. That includes:

• Agents and versions: Claude Code, Cursor, Copilot, Codex CLI, Gemini CLI, and any IDE forks.
• Extensions: every AI extension installed in VS Code and JetBrains.
• Accounts: whether each tool is signed in with a corporate or personal account. Privacy Mode and admin policy follow the account, not the laptop.
• MCP servers: every server configured in a repository's ".mcp.json" or a user-level config.
• Rules and skills: the instruction files and skills each agent loads.

Run discovery continuously rather than as a quarterly audit, because new agents and MCP servers appear faster than a periodic review can catch. This is the same problem as shadow AI in browser tools, with higher privileges. We explain why name-based catalogues undercount it in our guide to detecting unlisted and zero-day AI tools.

Step 2: Set Source Code Boundaries That Developers Cannot Override

Source code boundaries only work when they are set at the organization level, because any setting a developer can change, a prompt injection can also talk the agent into ignoring. Configure each tool's boundary centrally:

• GitHub Copilot: set content exclusion at the organization or enterprise level for sensitive repositories and paths. Content exclusion does not apply in Agent and Edit modes, so where those paths matter, disable Agent mode through policy. Visual Studio exposes a group policy setting for exactly this.
• Cursor: enforce Privacy Mode for the whole team from the admin dashboard, so members cannot turn it off. Ship a standard ".cursorignore" through Team Rules. Remember that ".cursorignore" does not bind the terminal or MCP tools.
• Claude Code: Add "Read" deny rules in managed settings for sensitive paths. Consider "permissions.blockReadsOutsideWorkingDirectories", which stops sandboxed commands from reading the home directory and mounted volumes.

Then classify what leaves. Proprietary source code sent to an unapproved model provider is a data handling event, even if no secret is involved. Detect it at the prompt layer, the same way you would for a browser-based AI tool.

Step 3: Keep Secrets Out of the Coding Agent's Reach

The most reliable way to stop secrets leakage through AI coding assistants is to make sure plaintext secrets are not sitting where the agent can read them. Then catch the ones that slip through, both on the way into context and on the way out.

1. Move secrets out of flat files. Replace .env files and hardcoded MCP credentials with a secrets manager that injects values at runtime. MCP configuration secrets are now a measurable problem: GitGuardian found 24,008 unique secrets in public MCP config files, largely because setup guides tell developers to paste API keys directly into JSON.
2. Deny credential reads at the sandbox level. Claude Code's sandbox accepts credentials entries that block reads of files such as ~/.ssh and ~/.aws/credentials, and strip variables such as GITHUB_TOKEN from the environment of sandboxed commands.
3. Detect secrets in prompts and in agent output. Pattern-based secret detection should run on what the agent sends to the model and on what MCP tools return into the IDE. We break down why credentials need pattern-based detection rather than entity recognition in our Guardia detection guide.
4. Scan AI-assisted commits at higher sensitivity. AI-assisted commits leak secrets at roughly twice the baseline rate, so pre-commit and CI secret scanning should treat them as a higher-risk class.
5. Rotate on exposure, not on schedule. Any secret that entered an agent's context during a suspected injection should be treated as compromised.

Step 4: Enforce Coding Agent Permissions with Managed Policy

Coding agent permissions should be enforced through managed settings deployed by your MDM. Project or user settings are not enough, because those can be changed by the developer, by a repository, or by an agent that has been manipulated. In Claude Code, managed settings live at /Library/Application Support/ClaudeCode/managed-settings.json on macOS and /etc/claude-code/managed-settings.json on Linux, and users cannot override them.

A practical baseline for Claude Code security looks like this:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "credentials": {
      "files": [
        { "path": "~/.ssh", "mode": "deny" },
        { "path": "~/.aws/credentials", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    },
    "network": {
      "allowedDomains": ["registry.npmjs.org", "pypi.org"],
      "allowManagedDomainsOnly": true
    }
  }
}

Each setting closes a specific gap from the previous section:

• disableBypassPermissionsMode removes the bypass mode that the Nx malware relied on.
• failIfUnavailable stops Claude Code from quietly running unsandboxed when the sandbox cannot start.
• allowUnsandboxedCommands: false removes the escape hatch that lets the agent retry a blocked command outside the sandbox.
• allowManagedDomainsOnly prevents a repository from adding its own network destinations.

Keep the domain allowlist narrow. Anthropic's documentation warns that broad entries such as github.com can become exfiltration paths.

Apply the same principle to the other tools:

• Cursor: disable auto-run of terminal commands.
• Copilot: use the MCP server allowlist.
• Every agent: give it a dedicated, scoped, short-lived credential instead of the developer's own token, as AWS recommends in its control framework for coding agents.

Require human approval for irreversible actions such as pushes, publishes, deployments, and deletions. A coding agent is a non-human identity, and it should hold least privilege like one.

Step 5: Treat Instruction Files and MCP Configs as Security-Sensitive Code

Any file that changes what a coding agent does should go through the same review as code that changes what your application does. That covers CLAUDE.md, AGENTS.md, .cursorrules and .cursor/rules/, .github/copilot-instructions.md, .mcp.json, .claude/settings.json, and .vscode/settings.json.

Three controls cover most of the risk:

1. Require code-owner review. Add these paths to CODEOWNERS so a security reviewer approves every change.
2. Block hidden Unicode in CI. Rules-file backdoors depend on characters a human reviewer cannot see. A simple CI check catches zero-width and bidirectional characters before merge:

   grep -rnP '[\x{200B}-\x{200F}\x{202A}-\x{202E}\x{2066}-\x{2069}]' \
     CLAUDE.md AGENTS.md .cursorrules .cursor/ .github/copilot-instructions.md

3. Pin template sources. Do not let teams copy rules files from public repositories without review. Treat a new MCP server like a new dependency.

Instructions planted in these files can persist across sessions and developers, which is why we treat them with the same seriousness as memory poisoning in AI agents.

Step 6: Log Every Coding Agent Read, Command, and Tool Call

Coding agent audit logs need to record actions at the tool-call level, because network and endpoint logs show only that a trusted process ran. An investigation-ready record captures:

• the developer's identity, the agent and its version, and the repository
• the action type (file read, shell command, or MCP tool call) and its exact target
• the data classes detected, such as a secret or proprietary code
• the policy decision applied

Export these records to your SIEM so the SOC can correlate agent activity with endpoint and identity events. That is the visibility gap the log trace earlier in this guide shows. We cover the schema in detail in our guide to AI audit logs and forensic visibility. The same records become the evidence auditors ask for under SOC 2 for AI systems.

How the Framework Maps to the OWASP Top 10 for Agentic Applications

The Read / Act / Reach controls map directly to the OWASP Top 10 for Agentic Applications 2026, which gives your governance committee a recognized standard to measure against.

For how these agentic risks relate to the broader LLM risk taxonomy, see our OWASP LLM Top 10 compliance mapping.

How Do You Red Team an AI Coding Agent?

You red team an AI coding agent by running the real attack paths against its production configuration: repository instruction injection, issue and README injection, MCP tool-output injection, and secret exfiltration. Run them in a disposable environment seeded with canary secrets, then turn every successful path into an enforced policy and retest it whenever the agent or model changes.

A one-time assessment is not enough for coding agents, because the attack surface changes with every agent release and model update. The academic numbers explain why:

• AIShellJack: this framework tested 314 attack payloads mapped to 70 MITRE ATT&CK techniques against production AI coding editors. Cursor in auto mode was vulnerable to 83.4% of them.
• Adaptive attacks: a 2026 systematization of prompt injection attacks on coding assistants found that published defenses were bypassed more than 85% of the time.

A configuration that held last quarter is not evidence that it holds today.

Six Attack Paths Every Coding Agent Red Team Should Test

How to Run a Coding Agent Red Team Without Risking Real Credentials

Run every test in a disposable virtual machine or dev container that mirrors your managed settings exactly. Use canary secrets (honeytokens that alert when they are used) in place of real ones, and log all egress, including DNS. Map each finding to MITRE ATLAS and the OWASP agentic risks.

The Security Assessment Handbook for Agentic AI Coding Assistants, published by Singapore's Cyber Security Agency on 15 October 2026, provides trust boundaries and attack paths already mapped to ATLAS, with mitigations tiered by criticality. It is a strong scoping reference for a first engagement.

At LangProtect, we combine manual testing with automated attack generation driven by multiple AI agents we have trained for adversarial work. The manual side finds the novel, context-specific paths. The automated side replays known patterns at volume on every change. Our enterprise guide to LLM AI red teaming explains why both are needed.

Turn Every Red Team Finding into a Runtime Policy

A red team finding is only closed when it becomes a control the agent cannot bypass, and when a retest proves the control holds.

Each finding should end in one of three outcomes:

• a managed setting or deny rule
• a runtime policy that blocks or redacts the action
• a review rule for instruction files

Keep the original payload as a regression test. Rerun the full set on every agent version upgrade, every model change, and every new MCP server, with a deeper manual engagement each quarter.

How Does LangProtect Secure AI Coding Agents?

LangProtect secures AI coding agents by adding the enforcement layer the native tools leave out. Guardia detects and governs what developers and their agents send to AI models. Vector sits inline between coding agents and MCP servers to evaluate each tool call before it executes. AI Red Teaming tests whether those controls hold under real attack paths.

The goal is not to replace Claude Code's sandbox, Cursor's Privacy Mode, or Copilot's content exclusion. Keep all of them switched on. LangProtect covers the boundaries between them, where the attacks in this guide succeed.

Every decision LangProtect makes is logged in a human-readable audit trail and can be exported to Splunk, Microsoft Sentinel, or Datadog. When a policy fires, you choose the response. Some actions should be blocked outright, while others are better redacted or warned on so developers keep working. We explain how to choose in our guide to redact, warn, or block enforcement outcomes.

For the full capability overview across IDE extensions, VS Code forks, and terminal agents, see LangProtect AI Code Protection.

Frequently Asked Questions

What is AI coding agent security?

AI coding agent security is the set of controls that govern what coding agents such as Claude Code, Cursor, and GitHub Copilot can read, execute, and send. It covers three planes: source code and secrets entering the model's context, shell and tool actions on the developer's workstation, and data leaving through the network or MCP connections. Each plane needs its own detection, classification, and enforcement.

Is Claude Code safe to use in an enterprise?

Claude Code can be used safely in an enterprise when it is governed by managed settings that developers cannot override. Its Bash sandbox is off by default, and even when enabled it lets shell commands read credential files such as ~/.ssh and ~/.aws/credentials unless you deny them, while file tools, MCP servers, and hooks run outside the sandbox. Enterprises should enforce the sandbox, deny credential reads, disable permission bypass modes, and log every tool call.

Does Cursor Privacy Mode stop source code from leaving my machine?

No. Cursor Privacy Mode controls whether model providers store your code or use it for training, but the code relevant to each request is still sent for processing. Privacy Mode also follows the signed-in account rather than the device, so a developer using a personal account on a corporate laptop may not be covered. Teams and Enterprise admins can enforce it so members cannot turn it off.

Can .cursorignore stop an AI coding agent from reading my .env file?

Not reliably. A .cursorignore file keeps files out of Cursor's indexing and AI context on a best-effort basis, but Cursor's own staff have confirmed that terminal commands and MCP tools can still read ignored files because they run at the operating system level. Protect .env files by moving secrets into a secrets manager and blocking credential reads at the sandbox or policy layer.

Does GitHub Copilot content exclusion work in agent mode?

No. GitHub's documentation states that content exclusion is not currently supported in the Edit and Agent modes of Copilot Chat in VS Code and other editors. Content exclusion still applies to code completions, Copilot Chat responses, and Copilot code review. Where excluded paths are sensitive, organizations can disable Agent mode through policy.

What is a rules file backdoor attack?

A rules file backdoor is an attack in which hidden instructions are embedded in the configuration files that AI coding assistants load for project context, such as .cursorrules or .github/copilot-instructions.md. Pillar Security disclosed the technique in March 2025, using zero-width and bidirectional Unicode characters that are invisible to human reviewers but readable to the model. A poisoned rules file can make the assistant insert backdoors or vulnerable code without any visible warning.

How do secrets leak through MCP configuration files?

Secrets leak through MCP configuration files because many MCP setup guides tell developers to paste API keys, tokens, and database connection strings directly into JSON config files, which are then committed to repositories or read by agents. GitGuardian's State of Secrets Sprawl 2026 report found 24,008 unique secrets exposed in MCP configuration files on public GitHub, 2,117 of them still valid. Use a secrets manager or runtime credential injection instead of plaintext values in MCP configs.

What permissions should an AI coding agent have?

An AI coding agent should have the minimum permissions its task requires, granted through a dedicated, scoped, short-lived credential rather than the developer's own tokens. In practice that means write access limited to the working directory, no read access to credential files, a narrow network allowlist, an approved list of MCP servers, and mandatory human approval for irreversible actions such as git push, package publishing, deployment, and deletion.

Can SAST, DLP, or EDR detect attacks on AI coding agents?

Mostly no. SAST scans code at commit time, but coding agent attacks often steal secrets before any commit and leave nothing in the diff. DLP sees allowed TLS traffic to a sanctioned model API or a secret encoded into a DNS lookup, and EDR sees a signed developer process running ordinary commands such as git, curl, or ping. Detecting these attacks requires telemetry at the agent layer that records each read, command, and tool call.

What does --dangerously-skip-permissions do, and how do you block it?

The --dangerously-skip-permissions flag starts Claude Code without permission prompts, so the agent can run commands and edit files without asking. Attackers have abused it: the malicious Nx packages in August 2025 launched Claude Code with this flag, Gemini CLI with --yolo, and Amazon Q with --trust-all-tools to hunt for credentials. Block it by setting disableBypassPermissionsMode to disable in Claude Code managed settings and applying equivalent policy to other agents.

How often should you red team an AI coding agent?

You should red team an AI coding agent continuously through automated tests, and rerun the full test set whenever the agent version, the underlying model, or the set of connected MCP servers changes, with a deeper manual engagement each quarter. Point-in-time testing goes stale quickly: research published in 2026 found that adaptive attacks bypassed published prompt injection defenses for coding assistants more than 85% of the time.

Which OWASP risks apply to AI coding agents?

The OWASP Top 10 for Agentic Applications 2026 is the most relevant framework for AI coding agents. The risks that map most directly are agent goal hijack through rules-file and issue injection, tool misuse through approved MCP servers, identity and privilege abuse of developer credentials, agentic supply chain attacks through malicious packages and MCP servers, and unexpected code execution through settings overwrites and malicious hooks. Prompt injection, ranked LLM01 in the OWASP Top 10 for LLM Applications, underlies most of these.

Govern Your Coding Agents Like the Privileged Identities They Are

AI coding agents are now some of the most privileged identities in your environment. They hold your developers' source code, credentials, and shell access, and they take instructions from any file they read. The native controls in Claude Code, Cursor, and Copilot are necessary, but each stops at a different layer. The organizations that stay ahead will inventory every agent, enforce the Read / Act / Reach controls through managed policy, log every tool call, and red team the result on every release.

The attack paths in this guide are already public, and attackers are already using coding agents to do their credential theft for them. The control layer to stop them exists today.