Policy & Enforcementagent-as-actor · govern what agents can do

Engineering · Policy & Enforcement

Govern what agents are allowed to do — watch, then assist, then automate.

Policy is about behavior and capability first. We're in audit mode now; this is exactly what an enforcing policy would have intervened on — and on which agents by name.

Bottom line

In audit mode. An enforcing policy would have intervened on 6 actions this period — 3 ungoverned, 2 as root, 1 --yolo. Approval-policy coverage is 38% (3/8). Flipping to Enforce now would block 4 agents and halt 2 live runs — stage through Assist and define a tool allow-list first, starting with Claude Code.

Do nextDefine allow-list for Claude Code firstAdd approval policy to 5 agents

Enforcement mode

Audit live · Assist/Enforce projected

Audit

Observe every action. Build the inventory and surface what a policy would catch — no intervention.

live now

Assist

Warn and prompt for human approval on high-impact actions. Humans stay in the loop.

projected

Automate

Block disallowed capabilities, off-policy tools, and over-budget runs automatically.

projected

Approval-policy coverage

target 100%

38%

3 of 8 agents have a tool-approval policy

Missing on: Cursor, Codex CLI, support-copilot, data-pipeline-agent, Zed Agent

Cost of flipping to Enforce now

if Enforce were on today

agents would be blocked · 2 active runs halted

Ungoverned + running-as-root + --yolo agents: Codex CLI, marketing-gpt, Zed Agent, support-copilot

stage through Assist first — don't break 2 runs cold

Dry run — which agents an enforcing policy would have intervened on

computed from live telemetry · 6 would-intervene · 0 actually blocked

Today we only observe. Each row names the specific agents a policy in Enforce mode would have gated — so you know exactly who to fix first.

Ungoverned agents

Acting without any registered policy binding.

Codex CLImarketing-gptZed Agent

would: require registration before run

Running as root

A compromised prompt would inherit full host privilege.

support-copilotmarketing-gpt

would: drop to low-privilege account

--yolo / sandbox bypassed

Approvals and sandbox disabled — any action, no gate.

marketing-gpt

would: force approval + sandbox

Unbounded consumption

Burned tokens with no per-agent ceiling (data-pipeline: 9.2M).

data-pipeline-agent

would: cap spend per agent

Tool-call diversity — who most needs an allow-list

distinct MCP servers per agent

More distinct tools = wider capability surface = more value from scoping. Start the allow-list where the surface is broadest.

Claude Code

2 tools

support-copilot

2 tools

marketing-gptungov

1 tool

Cursor

1 tool

data-pipeline-agent

1 tool

Claude Desktop

1 tool

Codex CLIungov

0 tools

Zed Agentungov

0 tools

Policies — capability & action first

Tool / MCP allow-list

projected

Scope which tools and MCP servers each agent may call. Anything off-list is denied — the core of capability control.

scope per agent

Human-in-the-loop approvals

projected

Gate high-impact actions — writes, deploys, external calls — behind an explicit human approval before they run.

gate high-impact actions

Per-agent spend ceiling

projected

Set a token / cost ceiling per agent and alert or halt when it is reached. Stops unbounded consumption.

cap per agent

Egress allow-list

detection live

Minor, supporting control: restrict which network destinations an agent may reach. Detection is live; blocking is not yet built.

detection live · blocking projected

Kill switch

roadmap

Immediately revoke an agent's credentials and halt its runs across the fleet — a single action to stop a misbehaving actor. Not yet built.

Fields: agents.governed · agents.factors · agents.mcp_servers · agents.runs · findings (LLM10 Unbounded Consumption) — from app/data/c16-fleet.ts (qcontrol /api shape). Enforcement actions are projected; audit is live.