How to secure AI coding agents

An AI coding agent is not just a faster autocomplete. Once it can read a repository, edit files, run a terminal, install packages and use cloud credentials, it has become an operator inside your development environment.

That changes the security question. Reviewing generated code still matters, but it only covers one part of the risk. You also need to control what the agent can reach, inspect what it brings into the workspace and stop high-impact operations before they execute.

A practical cross-provider model separates code, supply chain, local actions and remote systems. Each surface gets its own control and an explicit boundary.

The safest useful agent is not one with no authority. It is one with enough authority to work and independent limits around the actions that could cause lasting harm.

Start with the four things an agent can change

Agent security becomes easier to reason about when you separate four surfaces. Each surface needs a different control.

Surface	Common risk	Useful control
Code	Authentication flaws, injection, insecure defaults	Continuous scanning, tests and semantic review
Supply chain	Invented packages, poisoned MCP servers, malicious skills	Provenance checks and policy before installation
Local actions	Recursive deletion, history loss, database destruction	Sandboxing plus pre-execution policy on supported paths
Remote systems	Cloud deletion, production mutation, secret exposure	Scoped credentials and downstream enforcement

No single product controls all four surfaces. Provider sandboxes can restrict an agent process. Code scanners inspect the repository. Shell hooks can evaluate commands that pass through them. Cloud IAM controls remote authority. A sound design composes these layers instead of pretending one of them is universal.

1. Inventory the authority agents already have

Before writing policy, record how each agent is actually used. Include desktop applications, editor extensions, terminal agents, hosted workers and CI jobs. For each one, answer:

• Which directories can it read and write?
• Can it execute shell commands without per-command approval?
• Is network access enabled?
• Which environment variables, keychains or credential files can it reach?
• Can it use Docker, Kubernetes, Terraform or a cloud CLI?
• Which MCP servers, plugins, skills and persistent instruction files does it load?
• Can it open a pull request, push a branch or trigger a deployment?

Do not document the vendor’s theoretical default. Document the state on the developer’s machine. Teams often enable broad permissions because repeated prompts interrupt normal work. The real risk lives in the resulting configuration.

2. Keep the provider sandbox and permission system

Native provider controls are the first boundary. They can limit filesystem writes, network access and tool execution close to the agent. OpenAI describes Codex sandboxing in terms of filesystem and network boundaries. Anthropic recommends project-specific permissions, managed settings and development containers for Claude Code.

Use those controls. Do not weaken a working sandbox merely because you plan to add another product. Defence in depth only works when the layers stay intact.

At the same time, treat approval prompts as an authority decision rather than a complete policy. “May this agent use the shell?” is not the same question as “May this command drop the production database?” A developer may legitimately approve the first and still need a non-negotiable veto on the second.

3. Protect the shared result continuously

A provider only sees the work performed inside its own session. The repository is shared by agents, editors, humans and automation. Security checks should follow that shared result.

Run fast deterministic checks on save, commit and in CI. They should cover source code, configuration, infrastructure definitions, dependency manifests and lockfiles. Store the revision, ruleset and policy with the result so a later reviewer can reproduce the decision.

Use frontier security models for the cases rules struggle with: novel business-logic flaws, subtle authorization paths and long multi-file reasoning. Then turn confirmed discoveries into regression tests or deterministic rules where possible. The model finds a new class once. The control plane remembers it.

4. Verify everything the agent brings in

An agent can change the trust boundary without writing vulnerable application code. It can add a dependency, install an MCP server, enable a plugin or edit a persistent instruction file.

Before a new component becomes trusted, check:

• Whether the package or server exists in the expected registry
• Its publisher, repository and release history
• Whether the name resembles a popular package or a model-generated invention
• Install scripts, binary downloads and unusual network behaviour
• Requested scopes, tools and filesystem paths
• Changes to agent memory, rules or project instructions

This is where ordinary dependency scanning is necessary but insufficient. A clean vulnerability database result does not prove that a newly published package is legitimate. Provenance and behaviour matter before the first CVE exists.

5. Put a narrow veto around catastrophic local actions

Developers should not have to approve every ls, test run or package query. That creates prompt fatigue. Focus independent runtime policy on high-confidence operations whose impact is hard to reverse.

• Recursive deletion across a repository, home directory or mounted volume
• Git hard reset, destructive clean, branch deletion or force push
• Database drop, truncate or broad mutation without a restrictive predicate
• Container prune, volume removal or Kubernetes namespace deletion
• Terraform destroy or broad cloud resource deletion
• Permission changes that weaken protected paths
• Secret collection followed by a network or shell-visible destination

A rule only protects actions that pass through an interception point it controls. A shell hook can inspect supported shell commands. It cannot silently govern a native desktop API call or a hosted worker elsewhere. The product must show that difference clearly.

6. Treat remote operations as an identity problem

If an agent can reach production, the decisive boundary is usually downstream. Give it a purpose-built identity with the smallest useful scope. Separate development and production credentials. Require stronger approval for production writes and make destructive APIs enforce policy on the server side.

Useful patterns include short-lived credentials, just-in-time elevation, separate read and write roles, protected deployment environments and cloud policy that denies specific destructive operations. Route sensitive MCP and API traffic through a gateway when you need consistent logging or organization-wide policy.

Do not depend on a local prompt to protect a remote database after the credential itself already permits unrestricted deletion.

7. Prove the controls are live

Installed is not the same as active. A hook may be configured but bypassed. A policy may be current in one editor and stale in another. A scanner may be enabled locally but absent from CI.

Track three separate states:

This distinction prevents a security dashboard from becoming a collection of reassuring green lights with no evidence behind them.

A practical rollout plan

1. Week one: inventory tools, credentials, MCP servers and permission modes.
2. Week two: standardize provider sandboxes and remove credentials agents do not need.
3. Week three: add continuous code, configuration and supply-chain checks.
4. Week four: add pre-execution guards to supported local paths and test them with safe canaries.
5. Next: move sensitive remote actions behind scoped identities, gateways and downstream policy.

The goal is not to make agents timid. It is to let them work quickly inside a system where known catastrophic actions remain difficult, changes remain visible and every security claim has a clear boundary.