Claude Code stop conditions are agent security controls

The risky Claude Code run is not always the one that fails loudly.

The more dangerous version looks productive. It searches the repo, edits a few files, runs tests, and writes a clean summary. Somewhere in the middle, the task stopped being the task. The agent touched a shared helper. It widened the file boundary. It needed an MCP tool the reviewer did not expect. It made a test pass by narrowing the assertion. The final message still sounds calm.

That is why I like stop conditions.

A stop condition is a rule that tells the agent to stop working and return evidence instead of improvising. It sounds like prompt hygiene, but in production it is a security control. It decides when uncertainty becomes a human review event.

completion is the wrong target

Demos reward completion. A good demo ends with a patch, green tests, and a confident explanation.

Production work needs a different incentive. I do not want an agent to finish at any cost. I want it to stay inside the approved boundary, leave evidence, and stop when the work crosses into a decision a human should own.

For Claude Code, that boundary may be a folder, a command list, a set of tests, or a rule about deployment files. For an enterprise agent, it may be a tool policy, an identity, a data class, a RAG source, an MCP server, or an approval gate.

The shape is the same in both cases. The agent should not quietly turn a narrow task into a wider authority grant.

A prompt that says “fix this” leaves too much room for private judgment. A task contract with stop conditions changes the bargain. The agent is allowed to work inside the lane. If it needs to leave the lane, it has to stop and explain why.

the stop list I would use first

My default stop list is practical. It is not meant to cover every possible failure. It catches the moments where a useful coding run can become a governance problem.

Stop if:
- the target file or owner is unclear
- the fix requires a shared helper, auth path, billing path, security path, data migration, or deployment config
- an MCP server or external tool would expose data outside the task
- the agent cannot reproduce the failure
- tests pass only after weakening the assertion
- the diff becomes wider than the original task
- rollback is not obvious
- the evidence packet would be too thin for a reviewer to trust

That list is deliberately boring. Boring controls are easier to use when the team is tired, the incident channel is noisy, or a release is waiting.

The important part is to write the stop list before the run starts. If you add the rule after Claude Code has already improvised, you are reviewing damage. You are not controlling the work.

what the agent should return when it stops

A stop condition should not leave the reviewer with a vague refusal. The agent needs to return a small evidence note.

Stopped because:
- task boundary crossed: proposed change touches shared payment helper

Evidence:
- original task: fix invoice export rounding bug
- files inspected: src/invoice/exporter.ts, tests/invoice/exporter.test.ts
- risky file requested: src/payments/money.ts
- test status: focused invoice export test reproduces failure
- rollback note: exporter-only change is reversible; shared money helper change affects billing and reconciliation

Recommended next step:
- ask payment owner whether shared helper change is allowed
- if approved, create a separate task contract for the shared helper

That is enough for a human to make a decision. It names the boundary, shows what the agent saw, and avoids pretending the work is still a simple bug fix.

This is where Claude Code review packets and enterprise audit trails start to look like the same discipline. One is written for engineers reading a pull request. The other is written for security and governance teams who need proof that the agent’s authority was bounded, logged, and reversible.

MCP makes stop conditions more important

MCP changes the blast radius of an agent run.

A coding agent with file access can make a bad patch. A coding agent with file access, tickets, internal docs, logs, cloud helpers, and workflow tools can make a bad decision with much more context and much more authority.

That does not mean teams should avoid MCP. It means the stop rules need to include tool and data boundaries.

A Claude Code task might allow read-only access to a ticket and a focused test command. It should not automatically allow the agent to inspect production logs, query customer data, update a deployment workflow, or call every internal tool that happens to be reachable through an MCP server.

The stop rule is simple:

If the tool or data access is wider than the task, stop and ask.

That one line prevents a common failure mode. The agent does not get to decide that broader access is fine because it would be useful. Useful is not the same as approved.

stop conditions protect rollback

Rollback is where a lot of agent work gets exposed.

A patch can look small while being hard to unwind. Maybe the agent changed a shared abstraction. Maybe it updated a test fixture in a way that hides a production assumption. Maybe it added a migration, touched configuration, or changed behavior behind a feature flag without saying how to disable it.

A good stop condition forces rollback thinking early:

If you cannot explain how to undo the change before merge, stop and return a rollback note.

That is not a demand for perfection. It is a demand for reviewable risk.

In a financial services environment, this habit feels natural. You do not want clever changes that nobody can reverse under pressure. You want a run record that tells the next engineer what changed, why it changed, what passed, what still needs approval, and how to back out if the assumption was wrong.

Claude Code can help with that, but only if the prompt asks for it and the review process expects it.

a task contract with stop conditions

Here is a lightweight contract I would use for serious work in a shared repository:

Task: fix the invoice export rounding bug reproduced in tests/invoice/exporter.test.ts.

Allowed scope:
- read and edit src/invoice/exporter.ts
- read and edit tests/invoice/exporter.test.ts
- run the focused invoice export tests

Do not edit:
- auth
- billing orchestration
- payment shared helpers
- migrations
- deployment config

Stop and return a review note if:
- the fix requires files outside the allowed scope
- you cannot reproduce the failure
- you need MCP or external system access outside the ticket
- a test only passes after weakening the assertion
- rollback is unclear

Return:
- changed files
- commands run
- tests passed or skipped
- assumptions
- remaining risks
- rollback note

This does not make the agent slow. It makes the run inspectable.

The agent can still do useful work. It can still propose a wider fix. The difference is that the wider fix becomes a human decision instead of a hidden step inside a polished summary.

where the books fit

I wrote Claude Code: Building Production Agents That Actually Scale for the engineering side of this problem: task contracts, scoped edits, permission budgets, stop rules, review packets, evals, observability, cost controls, rollback, and human approval around real Claude Code work.

Kindle readers can get it on Amazon: Claude Code on Amazon Kindle.

Securing Enterprise AI Agents covers the authority side: agent identity, MCP blast radius, RAG controls, tool governance, approval gates, audit evidence, incident response, and revocation.

If your team owns both paths, the Enterprise AI Agents in Production bundle is the practical pair. One book helps the agent ship useful work a human can review. The other helps the organization decide what the agent is allowed to touch.

The habit is simple: a production agent should know when to stop before it learns how to finish.