Enterprise AI Coding Agent Security: Controls to Check

A coding agent is a program that reads your files, runs commands and sends context to a model, so its security comes down to four layers: what it may do without asking, what it can reach on the network, what data leaves for the model, and who can change those settings. This page maps each layer to what Claude Code, Cursor and GitHub Copilot document.

The threat model in plain words

Most of the risk comes from one fact. An agent obeys instructions in text, and it reads a lot of text it did not write. That includes source files, issue comments, web pages, package READMEs and the output of tools. Anthropic's security page defines the attack: prompt injection is a technique where an attacker tries to override or manipulate an assistant's instructions by inserting malicious text. Cursor's agent security page says the same thing in other words: AI can behave unexpectedly due to prompt injection, hallucinations and other issues, so guardrails limit what agents can do.

That produces five concrete risks.

None of these is solved by choosing a vendor. All of them are reduced by the settings below, and each of them needs an owner in your company. For the buying process around them see enterprise AI agents.

Layer one: approvals and what the agent may do alone

Both big agents default to asking before sensitive actions, and both explain the limits of that.

Claude Code. A session's permission mode sets which actions Claude can take without asking. In Manual mode it starts with read-only permissions, and when it needs to edit files, run tests or execute commands, it asks, and you approve once or allow from then on. The security page lists several protections that apply in Manual mode:

• Commands that fetch content from the web, such as curl and wget, are not auto-approved. You can add a deny rule to stop them entirely.
• Unmatched commands require approval, which the docs call fail-closed matching.
• Claude asks before running a Bash command it cannot fully analyze, and an allow rule for part of a command, such as Bash(git *), does not skip that prompt.
• Most tools that make network requests need approval.
• Credentials are stored in the macOS Keychain where available, and in a file with mode 0600 on Linux.

The docs also say that Auto mode is the built-in starting permission mode for interactive terminal and VS Code sessions, and they note that the working-directory boundary is a permission prompt. A Bash command you approve can still write anywhere your account can. That is why the next layer matters.

Cursor. By default, terminal commands need approval. Reading files and searching code do not. Agents can edit workspace files without approval, except configuration files, so version control is the recovery tool. All MCP connections need approval, and after approval each tool call still needs approval unless you pre-approve it in an MCP allowlist. Run Modes let trusted calls run without a prompt, from a simple allowlist to an Auto-review classifier, and Cursor says they are best-effort guardrails rather than a hard security boundary.

Read those last words twice. The vendors themselves say approvals are not a wall. Plan on that.

Layer two: isolation

Isolation limits damage when an approval is wrong. Claude Code has a sandboxed bash tool, configured with /sandbox, which isolates the filesystem and network and defines boundaries where the agent can work autonomously. The docs add that sandboxed commands can run without the command-injection prompt. For untrusted content, Anthropic's best-practice list includes running scripts and tool calls inside virtual machines, especially when talking to external web services.

For a company, three isolation patterns are worth knowing.

Cursor's cloud agents are the third pattern. The docs say cloud agents are the only feature that requires Cursor to store code, because they need repository access over time. Conversation history is kept indefinitely by default, and environment snapshots are kept for at most 30 days of inactivity, extended by 30 days each time an agent starts or resumes from one. Weigh that against the benefit that the agent never touches a developer laptop.

Layer three: the network

A hostile instruction usually needs the network to do harm, either to fetch a payload or to send data out. Cursor's cloud agents have internet access by default, and the docs describe three egress modes for users, teams and saved environments:

These settings apply to Cursor-hosted cloud agents. Runs on self-hosted machines use the machine's own network and firewall. For private services in a VPC or intranet, Cursor describes using Tailscale or Cloudflare Tunnel so that services need not accept inbound traffic from the public internet. For Claude Code, network enforcement is a permissions and sandbox matter, and the docs warn that a deny rule on a command name does not by itself stop every route to the network. The sandboxing docs say sandboxed commands reach the network only through a proxy that checks each host against your allowed domains, which start empty, and that network.deniedDomains blocks hosts even when a broader wildcard allows them.

A practical rule: for repositories that matter, run agents in a place where the firewall, not the agent, decides what is reachable.

Layer four: files, secrets and trust

Keeping files away from the agent. Cursor uses .cursorignore to block agent access to specific files. GitHub's content exclusion on Copilot Business and Enterprise stops excluded files from being used as context, from informing suggestions in other files, and from being reviewed by Copilot code review. Claude Code uses permission deny rules, set centrally through managed settings if you want users to be unable to remove them. Whichever tool you use, the rule is the same: keep secrets out of the repository, because an ignore rule is a second line of defence, not a first.

Trust on first open. Claude Code shows a workspace trust dialog when you start it in a folder you have not trusted, and servers in a project's .mcp.json have their own approval prompt. A non-interactive -p session shows neither prompt, which matters for CI. The docs also list what a repository's files can run before you trust a folder, so a freshly cloned repository from outside your company deserves the same suspicion as an email attachment.

Layer five: MCP and tools

MCP servers extend the agent with new tools and, therefore, new risk. Anthropic's page says project-scoped servers live in .mcp.json, which you can check into source control, and that servers at other scopes, claude.ai connectors and plugins can add servers too, so reviewing .mcp.json does not show every server a session can load. Anthropic reviews connectors against listing criteria before adding them to its directory but does not security-audit or manage any MCP server. It encourages writing your own servers or using providers you trust, and it points to managed MCP controls to restrict which servers run in your organization.

Cursor makes the same point from the other side: every MCP connection needs approval, and each tool call needs approval unless allowlisted. For a company, the actionable step is an allowlist of approved servers, owned by one team. Our guides on installing an MCP server in Claude Code and what MCP servers are cover the basics.

Layer six: who can change the settings

Every layer above is worthless if a developer can turn it off. Claude Code accepts managed settings by a managed-settings.json file, an MDM or OS-level policy, or server-managed settings from the claude.ai console, and the docs say managed settings apply to everyone your organization deploys them to, with some settings decided for the user so that nothing in their own files changes them. You can run /status to see which managed source applies. Cursor documents MDM deployment and enterprise security features, and lets admins enforce Privacy Mode for a team. Ask each vendor which settings are lockable, and test that a developer cannot override them.

The three agents side by side

Treat the blank cells as questions for the vendor, not as missing features. We could only fill a cell where we had the vendor's own page open. For Claude Code's retention position, see the table on Claude Code, and for Cursor's plans, Cursor pricing.

An example baseline for Claude Code

A company baseline is easier to review when it is a file. The example below uses setting names that Anthropic documents, permissions.deny and Bash(...) rule syntax. It is a starting point to adapt, not a certified policy, and you should check it against the current settings reference before rollout.

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

Deliver it as managed settings so users cannot remove it. Two cautions apply, both from the docs. A deny rule matches the command as written, so it does not stop every route to the network, and a sandbox is the stronger control for that. And reading is not the same as exposure: an ignore rule stops the agent from reading a file, but a secret that sits in a log, a shell history or an environment variable can reach it by other paths. Keep secrets out of the places an agent can read.

For Cursor, the equivalent baseline is Privacy Mode enforced for the team, a .cursorignore file in each repository, an MCP allowlist, an egress mode for cloud agents, and MDM deployment. For Copilot, it is content exclusion rules set at organization or enterprise level plus audit logs.

Failure modes we would test in a pilot

These are scenarios to try, written as test cases. We have not run them.

Write the expected result before you run each case, and record the actual result. A pilot that finds three gaps is doing its job.

Layer seven: watching what happened

You need visibility after the fact. Claude Code exports metrics and events through OpenTelemetry, and a company can send them to its own collector, configured by environment variables such as OTEL_METRICS_EXPORTER and OTEL_LOGS_EXPORTER. Cursor's audit log records admin events and, in its own words, does not record prompts, agent responses or generated code, and it points to hooks for logging development activity. Cursor documents hooks as a security feature, since they let a company run its own checks around agent actions. Decide up front what you log and who may read it, because a store of every prompt is itself sensitive.

A control checklist by role

Rollout plan

1. Pick a pilot group and a non-sensitive repository set.
2. Lock the baseline through managed settings or admin console: approvals on, MCP allowlist, Privacy Mode or ZDR as required.
3. Add isolation for anything that runs untrusted code.
4. Turn on logging and prove you can find five events.
5. Run an attack drill. Put a harmless hostile instruction in a test file and see what the agent does, what it asks, and what the logs show. This is a test you can run yourself, and we have not run one for this page.
6. Widen to more repositories only after the drill is clean.

Our take

The vendors are candid, which helps. Anthropic says no system is immune, and Cursor calls its run modes best-effort. Both give you the right parts: approvals, sandbox or ignore rules, network controls, managed policy and telemetry. What they cannot give you is a decision about how much autonomy your company accepts. That is a governance choice, covered on AI agent governance. Our advice is to start with approvals on and a narrow MCP allowlist, move low-risk work to sandboxes first, and treat any request to switch off approvals "for speed" as a risk acceptance that needs a name against it.

We have not run tests for this page. It reflects the vendors' published documentation on 2026-10-31. This is not legal or security advice for your environment. If you want help setting this up, get quotes from AI service providers.

Related pages

Enterprise AI agents, AI agent governance, Claude Code, Cursor, secure a vibe-coded app.