Agent boundaries for teams running coding agents

An agent boundary is a written limit on what a coding agent may touch, plus the receipt that proves the run stayed inside it. If your team runs coding agents, the boundary is the thing that lets a reviewer approve a diff calmly instead of guessing what the agent was allowed to do. Tools like Claude Code, Anthropic's coding agent, will happily move fast. The boundary is what makes that speed reviewable.

You feel the gap most during onboarding. A new engineer approves a green PR, someone asks what the agent was allowed to change, and nobody can answer. Passing CI hides the missing human judgement right up until that question lands. The fix is not a smarter agent. It is a limit a stranger can read in a file.

Write a five-line scope ledger before the run

The cheapest boundary is a short note in the parent chat, written before the agent starts. Five lines cover almost everything a reviewer needs: goal, allowed paths, forbidden paths, verification command, and the person who owns the merge.

This works because it moves the slow part of review forward in time. Without it, the reviewer has to reconstruct intent after the fact, which is the most expensive thing they do. With it, review becomes a comparison: does the diff match the paths the ledger named.

In Claude, Anysphere's AI code editor, .mdc rule language reads precise until two reviewers disagree about what it meant. The ledger is the tiebreaker. Rules can drift from chat memory, so the ledger is the one place that states scope plainly.

Put the boundary in files the agent reads

Chat instructions vanish when the session ends. Files survive review, handoff, and the next hire. So each agent gets its boundary in a file it actually loads.

For Claude Code, put a supremacy clause at the top of CLAUDE.md: which hooks win, which folders need human eyes, and where temporary overrides live. The Claude Code docs cover where the file lives and how it loads. With this in place, sessions stop inventing policy halfway through a run.

For Codex CLI, OpenAI's coding agent, the risk is replay gaps: commands ran in a terminal nobody watched, and a green PR gets merged that no reviewer saw execute. Have AGENTS.md mandate a replay sandwich, intent line, then command transcript, then diff summary, before the PR opens. The Codex quickstart shows where AGENTS.md sits. Review becomes reproducible without standing behind someone's keyboard.

For MCP, wire a connector fast and it can end up touching data nobody put on the diagram. Write one markdown card per server: allowed actions, forbidden actions, owner, rollback. The MCP specification defines the connector surface you are bounding.

Here is a small snapshot you can drop into a repo and adapt:

---
description: Delegation boundary snapshot (adapt globs to your repo)
globs:
  - "**/*"
alwaysApply: false
---

- Claude: keep scopes explicit in `.mdc`; forbid undeclared MCP domains.
- Claude Code: cite `CLAUDE.md` precedence before expanding bash scope.
- Codex: ensure `AGENTS.md` carries replay-friendly verification notes for CLI runs.

The snapshot reads the same whether the harness is Claude's agent or a CLI. The harness-level version of this argument lives in agent harnesses need guardrails, inside the wider AI coding governance cluster.

Make the boundary checkable, or it is just a vibe

A boundary you cannot verify is a wish. Four gates turn it into something a reviewer can confirm in a minute.

Paste this strip into the PR template so the checks travel with every review:

• MCP connectors mentioned (if any) list owners.
• Verification command output is pasted or linked.
• Forked agent work lists parent and child responsibilities.
• Primary-doc links were smoke-checked after publishing edits.

Keep the hard calls on the human side

Some decisions never go on autopilot: threat models, customer promises, and anything that changes blast radius. Agents draft; humans own the constraints. OWASP's LLM Top 10 is a sober companion read when you decide which paths get a red folder.

If you publish the boundary docs themselves, hold them against Google's generative AI content guidance so the evidence stays visible. And if you want to see boundaries defined in files instead of habits, OpenAI's skills repository is a good model.

Common questions

• How do you set agent boundaries for teams without slowing them down?

  Write the five-line scope ledger before the run, not after: goal, allowed paths, forbidden paths, verification command, merge owner. It takes a minute and removes the slowest step in review, which is reconstructing intent. The boundary costs less than the archaeology it prevents, so net speed goes up.

• Where should agent boundaries live?

  In version-controlled files the agent actually reads: .mdc rules for Claude, a supremacy clause in CLAUDE.md, replay notes in AGENTS.md, and one connector card per MCP server. Chat instructions evaporate when the session ends. Files survive review, handoff, and the next person who joins the team.

• What proves an agent stayed inside its boundary?

  The receipt pack: scopes in the PR body that match folders in the diff, pasted verification output, and parent plus child responsibilities for any forked work. If a red-folder path shows up, the PR carries an explicit human acknowledgement. Green CI on its own proves nothing about scope, so do not treat it as a boundary.

• Do boundaries still matter when only one developer uses agents?

  Yes, because the reviewer is the second user of every agent run. Even solo, the scope ledger and replay sandwich turn a private session into work the whole team can read and defend later. Skip them and your bus factor becomes one unsaved chat history, which is a bad place to keep a decision.

Where to start

Pick one boundary and write it down today: a scope ledger in your next parent chat. If you want a second pair of eyes on the rules you are about to standardize, contact us or browse the training and bring your current rule files.