Built with Claude Code
Every approval was a decision.
The agent asks before it acts, which is the safeguard. It also means the safeguard is you, at the end of a long session, pressing yes.
Anthropic’s own documentation, quoted and linked. They state where the responsibility sits plainly enough that this page mostly just repeats them.
Claude Code is a trademark of its owner. This page quotes public documentation to explain a scope of work. There is no partnership, endorsement or affiliation in either direction.
What stays yours
The documentation says it first.
Anthropic does not hedge on this, and neither will I. The permission model is real protection, and it hands the judgement back to you at every prompt.
Reviewing what you approve
Under a heading called User responsibility: “Claude Code only has the permissions you grant it. You’re responsible for reviewing proposed code and commands for safety before approval.” That is the whole arrangement.
What you allowlisted to stop the prompting
The docs describe the reason the list grows: “Prompt fatigue mitigation: Support for allowlisting frequently used safe commands per-user, per-codebase, or per-organization.” Every entry was added at a moment when the prompt was in your way, and applies at every moment after.
Edits that stop asking
Accept Edits mode “auto-approves file edits and a fixed set of filesystem Bash commands”. It is a deliberate trade and a useful one. It also means a run of changes reached your working tree without a single decision point.
Knowing the safeguards are not absolute
Anthropic prints the caveat rather than burying it: “While these protections significantly reduce risk, no system is completely immune to all attacks.” A vendor writing that about its own product is worth taking at face value.
Check it tonight
Re-read what you agreed to.
Anthropic recommends the first of these itself. The rest follow from the same idea: a decision made once keeps applying.
Run /permissions and read the list aloud
Anthropic’s own advice is to “regularly audit your permission settings”. Read each rule and ask what it would allow on a bad day, not what you added it for.
Check what reached the repository, not what is in it
A secret deleted in a later commit is still readable in the one that added it. That history travels with the repository if it is ever made public.
Find the session you stopped reading
Look for the longest run of accepted edits in one sitting. Attention drops before the session does, and the last third is where an unread change is most likely to be.
Test the guard rather than the screen
Send one request your app makes while signed in, without the session. If it answers, the protection you remember approving was drawn in the interface.
A permission you cannot justify today was granted by a version of you who was in a hurry. Then point the agent at itself, using the free prompt.
What a read adds
You approved it, so you have already read it.
That is the trap. Approving a diff and understanding a diff feel identical in the moment and are not the same act. An outside read has no memory of the conversation that made each change seem reasonable.
Getting one is what the audit is. What it covers, and where it stops, is published.
€350 + VAT · 48 hours
An independent pass over your app.
Your repository and your live app, every finding with the evidence, what it costs you and a prompt you can paste back into Claude Code.
€430.50 including VAT.
Start here
Have someone else read it.
Five questions to start, no call. If your app is smaller than this audit is built for, you hear that instead of an invoice.