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. Not hypothetically. These things have happened.
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.
Backslash Security researchers found four bypass methods for Cursor's YOLO mode denylist: base64-encoded commands, subshell execution, shell script creation, and bash quote variations. Their conclusion: "Cursor's denylist cannot be relied upon. It cannot prevent a compromised agent from running any command."
Check Point researchers disclosed three Claude Code vulnerabilities, including CVE-2025-59536 (arbitrary shell command execution) and CVE-2026-21852 (API key exfiltration from malicious repos). Separately, 32% of developers using Claude Code's --dangerously-skip-permissions flag encountered unintended file modifications; 9% reported data loss.
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. As shown above, the denylist is bypassable, and Workspace Trust is disabled 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 takes five minutes: 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 dev@company.com)
# - Git push: fix/auth-bug -> origin (approved by dev@company.com)
# - Policy version: v1.2.3
# - Total duration: 47sTotal added latency: under a minute for the two approval steps. Total value: 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 watched the same pattern repeat across our design partners: teams adopt a coding agent, give it broad access because that is the default, and then scramble when the first incident happens. The governed workflow prevents the scramble.