# Coding agent security: how to secure AI coding agents on laptops and in CI

> Coding agent security is the set of controls that limit what AI coding agents, such as Claude Code, OpenAI Codex, GitHub Copilot and Cursor, can do with a developer's files, credentials, shell and network. It combines each tool's sandbox and approval settings with least-privilege credentials, separate environments for autonomous runs, MCP server allow-lists, egress control, review gates and audit.

Source: https://agentfort.net/agent-security/coding-agents · Updated 2026-10-28 · AgentFort

## Why coding agent security is different

Coding agent security is the practice of limiting what an AI coding agent can read, run and change on the machines where it works. A coding agent is an AI agent that edits code and runs shell commands to build, test and commit it. It usually runs on a developer's laptop or a continuous integration (CI) runner, as that developer, with their credentials.

That placement makes coding agents unusual. Most agents reach a few APIs through narrow tools. A coding agent gets a shell, which reaches everything the developer can: source code, SSH keys, cloud credentials in the home directory, package registries, the corporate network and Git remotes. It also reads a steady stream of untrusted text: issues, pull request comments, README files, dependency source code and web pages.

So a coding agent holds private data, reads untrusted content and can send data out through `git push`, `curl` or a package install. When those three meet, one hidden instruction can become a leak. This guide covers the risks, the controls built into four popular tools as of October 2026, and the controls you add around them to secure AI coding agents. For the wider program, see the [AI agent security guide](/agent-security/).

## The main risks to AI coding agents

Five risks account for most of what goes wrong. Each one turns the agent's access into someone else's, or turns an honest mistake into damage.

### Prompt injection through repositories, issues and web pages

Any text the agent reads can carry instructions: a comment in a file, a line in a README, a GitHub issue or a page it fetches while debugging. A malicious issue in a public repository has already been used to make an assistant leak data from a private one; [MCP security](/agent-security/mcp-security) describes the case. The agent doesn't need to be hacked. It needs to read the wrong text while holding the right access.

### Secret exposure

Secrets sit within reach: `.env` files, `~/.ssh`, `~/.aws`, shell history and tokens in config files. An agent can read them while debugging, paste them into a prompt or commit them. Sandboxes don't always help by default. Claude Code's sandbox, for example, allows reads across most of the machine, including credential files such as `~/.ssh`, unless you restrict them.

### Destructive commands

Agents make mistakes at machine speed: `rm -rf` on the wrong path, a force push, a dropped table, an infrastructure change applied to the wrong account. Approval prompts catch some. Prompt fatigue, broad allow rules and auto-approve modes let others through.

### Malicious MCP servers and extensions

A local Model Context Protocol (MCP) server is a program that runs as the user. Claude Code's documentation says hooks and local MCP servers "run with your full access," outside its sandbox. Editor extensions carry the same risk: they are code installed from a marketplace and often updated automatically.

### Supply-chain installs

Coding agents install packages, and package installs run code. The August 2025 "s1ngularity" attack on the Nx build system went further. Malicious Nx versions on npm stole tokens, then invoked AI command-line tools already installed on the machine, with flags that skip permission prompts: `--dangerously-skip-permissions` for Claude, `--yolo` for Gemini and `--trust-all-tools` for Amazon Q. The prompts asked the tools to search the disk for wallets, keys and `.env` files ([Wiz](https://wiz.io/blog/s1ngularitys-aftermath)). In Wiz's sample, the AI-driven step succeeded in under a quarter of cases. Still, any process running as the developer can drive the agent.

## Built-in controls in Claude Code, Codex, Copilot and Cursor

Each tool ships its own approval system and sandbox. The table summarizes what each vendor's documentation states as of October 2026. GitHub's docs call its hosted agent Copilot cloud agent. Defaults change often, so check current docs before relying on one.

| Control | [Claude Code](https://code.claude.com/docs/en/security) | [OpenAI Codex](https://learn.chatgpt.com/docs/agent-approvals-security.md) | [GitHub Copilot cloud agent](https://docs.github.com/en/copilot/concepts/security-governance-and-network-settings/risks-and-mitigations) | [Cursor](https://cursor.com/docs/agent/security) |
|---|---|---|---|---|
| Approval modes | Auto (a separate classifier reviews actions), Manual (read-only until you approve), Accept Edits, plus `bypassPermissions` and `dontAsk` | Policies `on-request`, `never` and `granular`; optional `auto_review` reviewer agent that fails closed on errors | Only users with write access can start it; workflows on its pull requests wait for approval by default | Run modes: Auto-review (allowlist, sandbox and a classifier), Allowlist, Run Everything |
| Sandbox | Off by default, turned on with `/sandbox`; Seatbelt on macOS, bubblewrap on Linux and WSL2 | `read-only`, `workspace-write` (default for the Auto preset) or `danger-full-access`; Seatbelt on macOS, bubblewrap and seccomp on Linux | Runs in GitHub's Actions environment, not on a laptop | Seatbelt on macOS; Landlock or bubblewrap on Linux |
| Files | Sandbox writes limited to the working directory and temp; reads allowed widely unless denied | `.git`, `.agents`, `.codex` and `.aws` stay read-only even in writable folders | Pushes to a single branch, usually a new `copilot/` branch | Workspace read and write; `.git/config`, `.git/hooks` and `.vscode` protected |
| Network by default | Sandboxed commands go through a proxy whose domain allowlist starts empty | Off in `workspace-write`; optional allowlist proxy; local and private addresses blocked | [Firewall](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/customize-the-agent-firewall) on, with a recommended allowlist | Blocked in the sandbox, then opened by network mode and `sandbox.json` |
| MCP servers | Servers in a project's `.mcp.json` need approval; managed configuration limits which servers run | Admins can list approved MCP servers in `requirements.toml` | The firewall does not apply directly to MCP server processes | Every MCP connection needs approval; tool calls too, unless allow-listed |
| Admin controls | Managed settings can require the sandbox, block unsandboxed retries and lock domains | Managed configuration sets allowed approval policies, web search modes and network rules | Owners set firewall rules; CodeQL, secret scanning and dependency checks run by default | Teams and Enterprise admins choose available run modes and sandbox network rules |
| Limits stated in the docs | Hooks, local MCP servers and built-in file and web tools run outside the sandbox | `danger-full-access` with no approvals (flag alias `--yolo`) removes both layers; the docs call it "not recommended" | The firewall "should not be considered a comprehensive security solution" | Run modes are "best-effort guardrails rather than a hard security boundary" |

### What the four tools have in common

Three patterns stand out. First, sandboxes wrap shell commands, not everything the agent starts; MCP servers in particular often sit outside them. Second, model-based approval is spreading: Claude Code's Auto mode, Codex's `auto_review` and Cursor's Auto-review all ask a model to approve or refuse actions. That cuts prompts, but a classifier is not a boundary, so keep the sandbox on beneath it. Third, full access is one setting away in every local tool, and s1ngularity shows that malware can choose it.

## Least-privilege credentials for coding agents

An agent's reach equals the credentials it can find. Shrink them before you tune prompts.

- Give agents their own short-lived tokens instead of the developer's long-lived ones: a repository token for one repository, a cloud role for one sandbox account, a database user for one test schema.
- Keep production credentials off machines where agents run, and deploy through pipelines with their own approval steps.
- Block reads of credential folders. Claude Code's sandbox supports `denyRead` entries for paths such as `~/.ssh` and `~/.aws`. Codex keeps folders such as `.git` and `.aws` read-only inside writable roots; read-only stops changes, not reading.
- Strip secrets from the environment the agent inherits. Every command it runs can read environment variables, and s1ngularity's malware read them directly.
- Give each agent its own identity, so logs show which agent acted and you can revoke one without stopping the rest. See [AI agent identity](/agent-security/identity).

## Separate machines and containers for autonomous runs

Approval prompts protect interactive sessions. Autonomous runs, with nobody watching, need a boundary that doesn't depend on someone clicking "deny."

Run them in a disposable container or virtual machine (VM) that holds only the repository, a scoped token and an egress allowlist, and destroy it afterward. The vendors point the same way. For extra isolation, Claude Code's docs recommend running the whole process inside a sandbox runtime or a dev container, because its built-in sandbox covers shell commands, not hooks or MCP servers. OpenAI's Codex docs suggest `danger-full-access` only inside a container that serves as the isolation boundary. They also advise using dev containers only with trusted repositories, since full access inside a container can expose its credentials.

Headless and CI runs need extra care. Claude Code's docs note that a `-p` session shows neither the workspace trust dialog nor the `.mcp.json` approval prompt. In CI, the repository's own files decide what loads, so run agents only on branches you trust, with secrets scoped to the job. Check how each tool behaves without a person present before you schedule it. [AI agent sandboxing](/agent-security/sandboxing) covers sandbox design in depth.

## MCP servers, extensions and egress control

Treat MCP servers and editor extensions as software installed with the developer's rights, because that is what they are.

- **Allow-list servers centrally.** Claude Code supports managed MCP configuration that restricts which servers run. Codex lets admins list approved MCP servers in `requirements.toml`. Cursor asks for approval on every MCP connection.
- **Scan configuration in repositories.** A `.mcp.json` checked into a repository proposes servers to everyone who clones it. Review MCP config files like build scripts, and flag new servers and changed launch commands.
- **Pin versions** of servers and extensions, and install them from an internal registry where you can.
- **Control egress.** Route agent traffic through a proxy with a short allowlist: package registries, your Git host and the APIs the task needs. Block cloud metadata endpoints and private address ranges. Be careful with broad domains: Claude Code's docs warn that allowing domains such as `github.com` "can create paths for data exfiltration."
- **Know what network controls miss.** GitHub's firewall for its cloud agent "does not apply directly to Model Context Protocol (MCP) server processes or processes started in configured Copilot setup steps."

See [MCP security](/agent-security/mcp-security) for tool pinning, and [AI agent data loss prevention](/agent-security/data-protection) for inspecting what leaves.

## Review gates for pushes and deploys, and audit

The last line of defense is what happens before agent work reaches shared branches and production.

- Protect the default branch with required reviews and status checks, and let agents push only to their own branches. GitHub's cloud agent pushes to a single branch, and GitHub prevents the user who asked it to open a pull request from approving that pull request.
- Don't run CI workflows on agent pull requests automatically. GitHub holds them until someone with write access approves.
- Keep deploy credentials out of agent environments, and treat any agent-initiated deploy as a case for [human approval](/agent-security/human-approval).
- Scan agent changes the way you scan anyone's: static analysis, secret scanning and dependency checks. GitHub runs CodeQL, secret scanning and a dependency check on its cloud agent's code by default.
- Record what agents did. Claude Code can export OpenTelemetry metrics, and Codex supports OpenTelemetry export, off by default. GitHub signs its cloud agent's commits and links them to session logs. Send records to a store the agent can't edit. See [AI agent audit trails](/agent-security/audit).

## Coding agent security checklist

- Inventory every coding agent, editor extension and MCP server in use, on laptops and in CI.
- Set organization-wide defaults through each tool's managed settings, not personal preferences.
- Turn on each tool's sandbox, and require it where the tool allows.
- Deny reads of credential folders such as `~/.ssh` and `~/.aws`.
- Replace developers' long-lived credentials with short-lived, task-scoped tokens for agents.
- Run autonomous and full-access modes only in disposable containers or VMs with no secrets.
- Allow-list MCP servers centrally, and review MCP config changes in code review.
- Route agent network traffic through an egress allowlist, and avoid broad domains.
- Require human review before agent branches merge, and block self-approval.
- Hold CI workflows and deploys from agent changes for approval.
- Scan agent-written code for vulnerabilities, secrets and risky dependencies.
- Export agent activity logs to a store the agent can't modify.

## How AgentFort handles this

AgentFort doesn't replace the approval modes and sandboxes built into coding tools. It adds controls around agents. AgentFort Discover's optional sensor on hosts and Kubernetes pods sees which process calls a model and exactly where it runs. It flags shadow AI, such as a script on a finance workstation calling a model that nothing accounts for. Its read-only GitHub connector shows where agents are built and who built them. For agent tasks that run code, AgentFort Isolation gives each task its own sandbox built from Linux kernel features, with no network and no credentials inside. The only way out is one socket to a broker, which inspects traffic with AgentFort Data Protection, adds credentials the sandbox never sees, and holds anything leaving the company for a person. See [AgentFort Isolation](/platform/isolation), [watch a demo](/demo) or [become a design partner](/design-partners).

## Frequently asked questions

### Do AI coding agents send my source code to the model provider?

Usually, yes. The files, diffs and command output an agent reads become part of the prompts it sends to the model, unless the model runs in your own environment. Check the provider's retention and training terms for your plan. Keep secrets out of what the agent can read, so they never land in a prompt. For regulated code, prefer enterprise agreements, regional processing where it is offered, or models you host yourself.

### How do I find which coding agents and MCP servers developers are using?

Look in three places. On endpoints, inventory installed coding tools and editor extensions, and read their MCP configuration files in home directories and repositories. On the network, look for traffic to model provider APIs and remote MCP endpoints in proxy and DNS logs. In repositories, search for agent configuration files and model SDKs. Compare the results with your approved list, and give every approved agent an owner.

### Does code written by AI coding agents need extra security review?

It needs the same review as any contributor's code, applied every time. Agents produce plausible code quickly, and reviewers tend to skim plausible code. Require a human review for every agent pull request, and run static analysis, secret scanning and dependency checks in CI. Look hard at new dependencies, changes to authentication or authorization logic, and edits to CI workflows or build scripts, which can change what runs with your secrets.

### Who is responsible when a coding agent runs a harmful command?

The people who let it run. Vendors place review on the user: Claude Code's security documentation says the user is responsible for reviewing proposed code and commands before approving them. In practice, the developer who approved the command or merged the change owns the outcome, and the team that set the organization's defaults owns how much the agent could do without asking. Clear defaults and good logs make both visible.

### Are cloud-hosted coding agents safer than local ones?

They remove some risks and add others. A cloud agent runs away from the developer's laptop, so it can't read local SSH keys or cloud profiles. Anthropic says Claude Code cloud sessions run in isolated virtual machines and that GitHub credentials never enter the session VM. But the provider now handles your code, the agent still has write access to the repository, and its network allowlist, branch rules and review gates become the controls that matter.

## Sources

- [Claude Code: Security (Anthropic documentation)](https://code.claude.com/docs/en/security)
- [Claude Code: Sandboxing (Anthropic documentation)](https://code.claude.com/docs/en/sandboxing)
- [Codex: Agent approvals & security (OpenAI documentation)](https://learn.chatgpt.com/docs/agent-approvals-security.md)
- [Risks and mitigations for GitHub Copilot cloud agent (GitHub Docs)](https://docs.github.com/en/copilot/concepts/security-governance-and-network-settings/risks-and-mitigations)
- [Customize the agent firewall (GitHub Docs)](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/customize-the-agent-firewall)
- [Agent Security (Cursor Docs)](https://cursor.com/docs/agent/security)
- [Run Modes (Cursor Docs)](https://cursor.com/docs/agent/security/run-modes)
- [Wiz: s1ngularity's aftermath: AI, TTPs, and impact in the Nx supply chain attack](https://wiz.io/blog/s1ngularitys-aftermath)