Claude Code needs permission receipts, not blanket trust

Most teams talk about Claude Code permissions before the run.

That part matters. Define the files, commands, MCP servers, external systems, and approval gates before the agent starts touching real work.

But the harder question comes after the run: what did the agent actually use?

If Claude Code had access to the repo, shell, MCP servers, docs, tickets, CI logs, and deployment helpers, I do not want a vague summary saying it “checked the relevant files” or “updated the tests.” I want a permission receipt.

A permission receipt is boring on purpose. It records what the agent was allowed to do, what it attempted, what succeeded, what failed, what was blocked, and what still needs human approval before merge.

the after-action record is where trust becomes inspectable

Pre-run permissions tell the agent where the fence is. They do not prove the agent stayed inside it.

That distinction matters once a coding assistant moves beyond local toy changes. A serious Claude Code session may read source files, edit tests, inspect CI output, search documentation, call an MCP server, open an issue, or draft a deployment note. The final diff can look small while the authority used to produce it was broad.

A permission receipt gives the reviewer something to check before looking at the patch:

permission_receipt:
  task: "fix failed payment reconciliation import"
  approved_scope:
    files:
      - "src/reconciliation/**"
      - "tests/reconciliation/**"
    tools:
      - "read files"
      - "edit files"
      - "run focused tests"
    external_systems:
      - "jira read-only"
      - "stripe sandbox read-only"
  tools_used:
    - tool: "read files"
      purpose: "inspect importer and existing tests"
    - tool: "edit files"
      purpose: "patch idempotency guard"
    - tool: "test runner"
      purpose: "run reconciliation tests"
  blocked_or_denied:
    - action: "read production Stripe logs"
      reason: "outside approved sandbox scope"
  human_approval_required:
    - "run full integration suite before merge"
    - "confirm reconciliation behaviour with finance owner"
  rollback:
    - "revert reconciliation importer patch"
    - "disable PAYMENT_RECONCILIATION_AGENT_FIX flag"

This is not ceremony. It gives the reviewer a control surface.

The reviewer can see whether the agent stayed inside the file boundary. They can see whether MCP access stayed read-only. They can spot a denied action that needs a real decision. They can reject the work if the agent used broad tools to solve a narrow task.

review the receipt before the diff

I would review the permission receipt before the code diff for any agent run that touches shared repositories, customer-adjacent code, payment flows, deployment scripts, internal tools, or data access.

The first check is scope.

Did the task need a whole repository, or did it need two folders? Did the agent read an auth module while fixing reporting copy? Did it inspect CI logs because the failure was relevant, or because broad access was available and nobody narrowed it?

The second check is tool use.

MCP makes this more important, not less. Once the agent can reach tickets, docs, logs, cloud resources, build systems, or internal services, “read-only” is not enough by itself. Which server did it use? Which identity did it use? What data class did it touch? Did it try to write? Was anything denied?

The third check is human approval.

Some actions should stop the run rather than appear quietly in the final summary. Reading sandbox test data may be fine. Reading production customer data may need explicit approval. Editing tests may be fine. Editing deployment config may need a separate reviewer. The receipt should make those crossings visible.

the receipt should change how you prompt Claude Code

If you want better receipts, make them part of the task contract.

A lightweight prompt can do the job:

Work only in src/reconciliation and tests/reconciliation.
Do not edit auth, migrations, deployment config, or shared payment abstractions.
If the fix needs one of those areas, stop and explain why.
Run the focused tests and report anything skipped.
Return a review packet with changed files, commands, risks, approvals still needed, and rollback.
Include a permission receipt listing tools used, external systems touched, denied actions, and out-of-scope attempts.

That prompt does not make Claude Code slow. It makes the work easier to review.

It also gives the agent a better operating frame. The agent has to think in boundaries: allowed files, allowed commands, allowed systems, blocked actions, evidence, and rollback. In my experience, that pressure usually improves the run. The output is less magical and more useful.

buyers care about the run record

This is also a sales and adoption problem, not only an engineering problem.

A technical lead buying an AI coding workflow is not buying a clever demo. They are buying a run they can defend when the work reaches a pull request, an audit question, an incident review, or a risk committee.

A security owner asks the same question from another angle: if the agent can act through tools, where is the proof that its authority was bounded, logged, approved, and reversible?

That is why Claude Code delivery and enterprise agent security keep meeting in the same place. The engineering loop needs task contracts, scoped edits, tests, review packets, and rollback. The security loop needs identity, MCP boundaries, policy gates, logs, approval records, and revocation.

A permission receipt sits between those two loops. It turns “trust the agent” into “inspect the run.”

where the books fit

I wrote Claude Code: Building Production Agents That Actually Scale for the engineering side of this problem: task contracts, permission budgets, scoped changes, 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 needs both, 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: do not merge serious agent work until the run leaves a receipt.