Coding Agent Security: How to Roll Out Claude Code and Cursor Without Unlimited Authority

Rolling out AI coding agents is not the same as rolling out a code-completion tool.

A coding agent can read a repository, edit files, run tests, execute shell commands, call MCP tools, inspect secrets, interact with cloud services, and trigger deployment workflows.

That is what makes it useful. It completes real work instead of suggesting the next line.

It is also why "Can developers use this tool?" is the wrong first security question. A better one is:

Which actions should an agent be allowed to perform automatically, which should require approval, and which should never run?

This guide gives platform, DevSecOps, and security teams a practical model for coding agent security: how to roll out tools like Claude Code and Cursor across engineering teams without handing them unlimited authority.

Every agent action falls into one of three tiers: auto-allow for safe, low-risk actions, needs approval for potentially sensitive ones, and never run for dangerous or destructive ones.

Step 1: Inventory Every Action Surface

Before you write any policy, understand what the agent can touch. For each coding agent you plan to approve, document its access to:

• Shell commands
• Filesystem reads and writes
• Repository operations
• Environment variables and local secrets
• MCP servers and tools
• Cloud APIs
• Databases
• CI/CD systems
• Production infrastructure
• Browser or network access

Do not treat "the coding agent" as a single permission. The risk lives in the individual action surfaces.

A tool that can read source code and run tests has a very different blast radius from the same tool holding production Kubernetes credentials.

The coding agent sits at the center of every surface it can reach, from files, shell, and the repository out to secrets, the network, and production.

Step 2: Separate Developer Permissions From Agent Authority

A common mistake is assuming that if a developer is allowed to do something, an autonomous agent working for that developer should inherit the same unrestricted authority.

That is not always the right model. A senior engineer may have permission to delete a production resource, but the organization may still want an agent to get human confirmation before using that permission.

Think in terms of delegated authority:

• The developer is trusted.
• The agent acts on the developer's behalf.
• The agent receives only the authority the task requires.

This matters most for open-ended interfaces such as shells, generic HTTP clients, and powerful MCP servers, where one tool can perform almost any action.

Step 3: Start With Five High-Confidence Policy Areas

You do not need hundreds of rules on day one. Start with controls that are easy to explain and hard to argue with.

The five starter areas, one card each: protected paths, sensitive files, production writes, destructive commands, and high-risk tool calls.

Protected paths

Critical release, migration, infrastructure, security, and policy files can stay readable but should not be modified automatically.

Sensitive files

Private keys, credentials, token stores, and other secret locations should not be readable by default.

Production writes

Separate read access from write access. A coding agent that can inspect production should not automatically be able to change it.

Destructive commands

Recursive deletes, destructive database operations, IAM changes, and other high-impact actions should be denied or escalated to a human.

High-risk tool calls

For MCP servers and APIs, evaluate the operation and its arguments, not just whether the tool is installed. The same tool can be harmless with one set of arguments and dangerous with another.

Step 4: Apply Least Privilege at the System Level Too

Runtime policy should not replace basic least privilege. OWASP's guidance on Excessive Agency recommends limiting an agent's functionality and permissions to the minimum it needs.

Use both layers. If an agent only needs database reads, give its identity read-only database permissions. Then use runtime policy to add context the permission system cannot express, such as:

• reads are allowed in production
• writes are denied
• schema operations are denied
• selected administrative operations require approval

Defense in depth matters because no single layer should carry the entire security burden.

An agent action passes through least privilege (IAM and database roles) and then runtime policy (allow, deny, approve) before it reaches production. Either layer can stop it.

Step 5: Observe Before You Enforce

The fastest way to create developer resistance is to deploy a security layer that blocks normal work before you understand the workflow.

Start with an observation, or log-only, phase. Collect:

• commands agents attempt
• paths they read or modify
• MCP tools they call
• production resources they touch
• rules that would have matched
• false positives
• actions developers believe should be approved automatically

Then sort those actions into three groups: clearly safe, clearly unsafe, and context-dependent.

Enforce the high-confidence rules first, before you try to model every edge case.

ControlZero's advanced playbooks include a log-only rollout pattern built for exactly this: tuning policy against real agent behavior before turning on enforcement.

The rollout runs in three stages: observe every agent action in log-only mode, classify each one as safe, unsafe, or context-dependent, then enforce policies that allow, warn, or deny.

Step 6: Define Clear Approval Boundaries

Not every risky action should be permanently denied. Some actions are legitimate but deserve a human checkpoint, for example:

• production deployments
• destructive database migrations
• IAM policy changes
• deleting a cloud resource
• modifying a protected release file

For each one, decide who can approve it and what evidence the approver needs.

The important part: approval must happen before execution, not as a notification after the incident.

Step 7: Know Each Coding Agent's Enforcement Boundary

Different coding agents, whether Claude Code, Cursor, or a CLI-based agent, expose different hooks and enforcement behavior.

That means a security product should never claim "this host is protected" without being specific about which events it can actually intercept.

ControlZero's coverage documentation takes an event-level approach. It lists which supported agent surfaces expose enforceable pre-execution hooks and where vendor limitations remain.

That is the standard teams should demand from any agent security product: tell me exactly which actions are stopped, which are only observed, and which are not visible at all.

An example coverage matrix: for each action type, can the security layer stop it, only observe it, or not see it at all?

Step 8: Keep Policy Close to Developers

A good control should not turn every routine agent action into a network-dependent security ceremony.

For deterministic rules, local or in-process evaluation reduces latency and keeps developers in flow.

ControlZero supports local policy files in YAML or JSON, including allow and deny rules with optional resource and condition matching. That makes policies reviewable like any other engineering configuration, and gives teams a path to local or restricted-network operation.

Coding Agent Rollout Checklist

Before approving coding agents across the organization, answer these ten questions:

1. Which shell commands can the agent run?
2. Which paths are read-only, writable, or prohibited?
3. Which secrets can the agent access?
4. Can it reach production?
5. Which MCP and API tools can it call?
6. Which actions require human approval?
7. Can you prove whether a denied action actually ran?
8. What happens when a policy cannot be evaluated?
9. How are exceptions reviewed?
10. Who owns the policy over time?

If several answers are "we don't know," the rollout is not ready for unlimited authority.

Conclusion: Design Agent Authority, Don't Assume It

The goal is not to make coding agents powerless. The goal is to let them move quickly inside a deliberately defined operating envelope.

1. Start with visibility.
2. Reduce unnecessary permissions.
3. Define a small set of deterministic action policies.
4. Add approvals for legitimate high-risk work.
5. Expand coverage based on real usage.

Coding agents are valuable because they can act. That is exactly why their authority needs to be designed, not assumed.

Use the checklist to define your first coding agent policies, then test them in observe mode.

Get started