Give agent exceptions a budget before they become policy

The first agent exception usually sounds reasonable.

Claude Code needs to inspect one folder outside the task contract. An MCP tool needs temporary read access to a ticket system. A support agent needs one extra workflow action because the normal route is too slow. Nobody wants to block useful work for the sake of a neat policy document.

Fair enough. Production work has exceptions.

The problem starts when exceptions become memory. Someone says, “That was fine last time.” The tool list grows. The repo boundary gets wider. A read permission becomes a write permission for one special case, then nobody removes it. Six weeks later the team is running a different control model from the one they think they approved.

If you use Claude Code or enterprise AI agents in real systems, treat exceptions as a budget. Spend it deliberately. Record it. Let it expire.

the normal grant should be boring

A normal agent grant should be dull enough that a tired reviewer can understand it in a minute.

For Claude Code, that means the task contract names the files, commands, tests, and things the agent must not touch. It also says what the review packet must include at the end. If the agent needs more room, it should stop and ask rather than quietly solve the task by widening the boundary.

For an enterprise agent, the same idea applies to tools and data. Which MCP server can it call? Which identity does it use? Is access read only? Can it update a system of record? Does the permission end after the run, after the ticket, or never?

The normal grant is the path you want people to use without debate. It should be narrow, repeatable, and easy to inspect.

exceptions need a price tag

An exception budget does not mean a monthly quota where teams try to spend every exception. It means every expansion of authority carries a small price tag:

exception_request:
  task: "investigate failed settlement import"
  requested_extra_access:
    - "read ci logs for payment import job"
    - "read-only access to settlement ticket attachments"
  reason: "failure appears in generated import file, not in local test fixtures"
  owner: "engineering lead on call"
  expiry: "end of this investigation"
  approval_required_before_write: true
  evidence_required:
    - "commands run"
    - "files read outside normal scope"
    - "tool calls"
    - "decision made after the exception"
    - "revocation confirmation"

That is not heavy process. It is a speed bump in the place where speed usually hides risk.

The useful question is not, “Do we trust the model?” The useful question is, “What extra authority did this task need, and who accepted that cost?”

Claude Code exceptions are easy to miss

Claude Code work can look clean in the final diff while the run used more authority than the reviewer noticed.

Maybe the patch touched two files, but the agent read half the repository. Maybe it inspected deployment config while fixing a local test. Maybe it used a broad shell command because the task contract allowed “run tests” without naming which tests. Maybe it pulled context through an MCP server that nobody expected to be part of this workflow.

Some of that may be fine. The point is to make it visible.

A good Claude Code review packet should separate the normal work from the exception work:

Normal grant used:
- edited src/billing/importer.ts
- edited tests/billing/importer.test.ts
- ran npm test -- importer

Exception requested:
- read ci log for failed settlement import job
- approved by payment lead at 10:12
- expired after investigation

Denied or skipped:
- did not read production payment data
- did not edit deployment config

Reviewer action:
- confirm ci log evidence matches test fixture
- approve or reject the patch

That gives the human reviewer a better starting point than a cheerful summary saying the agent “checked CI and updated the tests.”

enterprise agents drift through tool access

Enterprise agents drift differently. They often start with a safe question answering role, then gain tools because the answers are useful.

First the agent can read policy documents. Then it can read tickets. Then it can draft replies. Then it can update a workflow field. Then it can trigger a downstream process because waiting for a human feels silly in the happy path.

Each step can make sense on its own. The risk is that nobody treats the steps as a permission change.

For security and governance teams, an exception budget gives you a way to discuss that growth without killing the rollout. You can allow a temporary tool expansion while still asking the control questions:

Who approved the extra tool?
Which identity did the agent use?
Which data classes were reachable?
Could the agent write or only read?
What would an incident reviewer see later?
When did the extra access expire?
How do we prove it expired?

If those answers are missing, the exception is already becoming policy.

budget the exception, then learn from it

The best reason to track exceptions is not punishment. It is learning.

If Claude Code asks for the same extra repository scope every week, maybe the normal task contract is too narrow. If an enterprise agent keeps needing one MCP tool to finish a common workflow, maybe that tool deserves a proper policy wrapper, better logging, and a reviewed approval gate.

But if an exception appears once during an odd incident, do not let it harden into the default. Close it. Leave the receipt. Move on.

I like a simple weekly review:

Which exceptions were approved?
Which were denied?
Which ones repeated?
Which ones produced useful work?
Which ones created review discomfort?
Which normal grant should change?
Which temporary permission needs revocation proof?

This is where delivery discipline and security discipline should meet. Engineering wants the agent to move fast enough to be worth using. Security wants the authority to be bounded, logged, and reversible. An exception budget gives both sides the same record to argue from.

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, 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 keep the agent’s authority bounded, logged, and stoppable.

The habit is simple: if the agent needs an exception, make the exception expire before it becomes the new policy.