The access problem with AI coding agents
A coding agent is not a code completion tool. Claude Code, Cursor, and Devin read and write files, run shell commands, execute git operations, interact with package registries, and call cloud APIs. In many setups, they have the same access as the developer running them: SSH keys, cloud credentials, CI/CD tokens, database connection strings.
This is a different threat model than a chatbot that generates text. A coding agent can git push --force to main, run terraform destroy against production, install a dependency with known CVEs, or read environment variables containing API keys. A public example: developer Alexey Grigorev documented a Claude Code workflow that executed destructive Terraform actions and wiped production data after a state mismatch, as reported by Tom's Hardware.
What top coding-agent security docs still miss
Official docs explain local safeguards well. The missing layer is cross-tool governance at organizational scale. That is where most operational risk accumulates.
| Source | What it covers well | Gap for production governance |
|---|---|---|
| Claude Code Security Docs | Permission architecture, sandbox mode, and prompt-injection guidance. | No central multi-tool policy engine for fleet-level enforcement across all coding agents. |
| Cursor Security + Agent Security Docs | Infrastructure/client security posture, privacy mode behavior, and explicit trust-model caveats. | No immutable cross-session audit evidence linking risky action, reviewer, and final side effect. |
| Devin Enterprise Security Docs | Enterprise security controls, compliance posture, and operational safeguards. | No portable policy-as-code contract to govern Claude/Cursor/Devin uniformly from one layer. |
Minimum bar: every risky action emits one immutable evidence record. Without that, incident reviews become screenshot archaeology instead of engineering.
{
"agent": "claude-code",
"session_id": "sess_01JTRX4WGN2TZJG4B99RGV8M2K",
"action": "git.push",
"target": "origin/main",
"decision": "require_approval",
"policy_version": "v1.7.1",
"reviewer": "[email protected]",
"outcome": "approved",
"timestamp": "2026-04-01T10:41:55Z"
}Three risk scenarios platform engineers recognize
Developer Alexey Grigorev lost 2.5 years of production data when Claude Code ran terraform destroy. A missing state file caused the agent to create duplicates; when the state was uploaded, the agent treated it as truth and destroyed everything including databases, snapshots, and records across two sites.
Cursor's official security page states Workspace Trust is disabled by default and extension signature verification is not currently enforced by default in Cursor. Those are documented tradeoffs, not hidden bugs. In high-sensitivity environments, these defaults expand attack surface unless enterprises enforce hardened configuration policy at scale.
Claude Code's security docs explicitly say Anthropic does not manage or audit MCP servers. Devin's enterprise docs explicitly warn about hallucinations and insecure suggestions, and recommend branch protections plus code review before deployment. Put together: tool trust and secret handling remain operator-owned problems unless you add an external governance layer.
Built-in guardrails: what exists and what is missing
Each coding agent ships some safety features. None ship governance.
Claude Code has a three-tier permission system (Allow/Ask/Deny), five permission modes, and enterprise-managed settings. Its OS-level sandbox restricts filesystem and network access. These are real controls that prevent accidental damage in normal use.
Cursor has YOLO mode with allowlists and denylists, SOC 2 Type II certification, and workspace-level settings. Cursor also documents important trust caveats: Workspace Trust is disabled by default, and extension signature verification is not currently enforced by default.
Devin uses a PR-based workflow with planning approval and pull request approval checkpoints. SOC 2 Type II certified since September 2024. The strongest built-in model of the three, but limited to the two-checkpoint pattern.
What none of them provide:
- - Policy-as-code: Declarative, version-controlled rules evaluated at runtime. Not scattered settings files.
- - Fleet-level audit trails: Centralized record of what every agent did across the organization.
- - Runtime resource constraints: Token budgets, time limits, blast-radius boundaries per action.
- - Cross-tool governance: Unified policy layer across Claude Code, Cursor, and Devin simultaneously.
AI coding agent governance model
Governance for coding agents needs three pillars. Each addresses a different class of risk.
Separate read from write. Separate staging from production. An agent fixing a frontend bug should not have kubectl access to your production cluster. Enforce at the protocol level, not with prompt instructions the agent can ignore.
Git push, deploy commands, infrastructure changes, dependency additions: all should pause for human review. Not every file write. The risky ones. A developer reviews the diff and approves in under a minute.
Every action recorded: what file was read, what was written, what command ran, who approved it, what policy version was active. Not IDE-level logs that disappear when the session ends. Structured, queryable, permanent records.
MCP as the governance hook for coding agents
Here is the key insight: coding agents already use MCP (Model Context Protocol) for tool access. Claude Code connects to MCP servers for file operations, git commands, and external tool calls. Cursor integrates MCP servers via its extensions system. MCP is the protocol layer where tool calls happen.
Governing the MCP layer means intercepting every tool call at the protocol level, before the tool executes. A governed MCP server evaluates each call against policy: reads pass through, writes pause for review, destructive operations are blocked. The coding agent does not need to be modified. The governance layer sits between the agent and the tools it calls.
Step-by-step: governing coding agents with Cordum
Cordum's MCP server sits between the coding agent and the tools it accesses. Every tool call routes through the Safety Kernel for policy evaluation. Here is what the policy looks like:
# safety.yaml - coding agent governance
version: v1
rules:
- id: allow-code-read
match:
topics: ["job.mcp-bridge.read.*"]
risk_tags: []
decision: allow
reason: "File reads, git log, ls are safe"
- id: approve-code-write
match:
topics: ["job.mcp-bridge.write.*"]
risk_tags: ["code-change"]
decision: require_approval
reason: "File writes need developer review"
- id: approve-git-push
match:
topics: ["job.mcp-bridge.git.push", "job.mcp-bridge.git.force-push"]
risk_tags: ["deploy"]
decision: require_approval
reason: "Git push to remote requires approval"
- id: deny-infra-destroy
match:
topics: ["job.mcp-bridge.*.destroy", "job.mcp-bridge.*.delete"]
risk_tags: ["destructive", "infrastructure"]
decision: deny
reason: "Infrastructure destruction blocked"
- id: deny-secrets-access
match:
topics: ["job.mcp-bridge.read.env", "job.mcp-bridge.read.secrets"]
risk_tags: ["credentials"]
decision: deny
reason: "Direct secrets access blocked by policy"File reads and git log pass through instantly. File writes and git push pause for developer review. Infrastructure destruction and direct secrets access are blocked outright. The rules are YAML, version-controlled, reviewed in pull requests alongside your application code.
Setup is straightforward: point Claude Code's MCP configuration at Cordum's MCP server instead of (or in front of) your existing tool servers. The agent's capabilities do not change. What changes is that every capability is now evaluated against policy before it executes. See our quickstart guide for the configuration.
The governed coding agent workflow
Here is what a governed workflow looks like end to end. The developer asks the agent to fix a bug. The agent reads files (allowed instantly), writes a fix (pauses for approval), and pushes to a branch (pauses again). Each decision is recorded in the audit trail with the developer who approved it.
# Governed coding agent workflow
#
# 1. Developer asks agent: "Fix the auth bug in login.ts"
#
# 2. Agent reads files via MCP
# tool: file_read("src/auth/login.ts")
# Safety Kernel: ALLOW (read, no risk tags)
#
# 3. Agent writes fix via MCP
# tool: file_write("src/auth/login.ts", patch)
# Safety Kernel: REQUIRE_APPROVAL (code-change tag)
# -> Developer reviews diff in dashboard
# -> Approves
# -> File written
#
# 4. Agent pushes to branch via MCP
# tool: git_push("fix/auth-bug", "origin")
# Safety Kernel: REQUIRE_APPROVAL (deploy tag)
# -> Developer reviews branch + commit
# -> Approves
# -> Push proceeds
#
# 5. Audit trail records:
# - Files read: src/auth/login.ts
# - Files written: src/auth/login.ts (approved by [email protected])
# - Git push: fix/auth-bug -> origin (approved by [email protected])
# - Policy version: v1.2.3
# - Total duration: 47sIn this example, added latency is under a minute for the two approval steps. The value is a complete record of what the agent did, who approved it, and what policy was active. When your security team asks for an audit, you have it.
We built this at Cordum because we kept seeing the same pattern: teams adopt a coding agent, give it broad access because that is the default, and then scramble after the first bad action. The governed workflow reduces that scramble.