Claude Code permissions and safety for product teams

Who actually decides what an agent may do?

Somebody already did, and on most teams it was whoever clicked "yes, and don't ask again" first. Those approvals are saved to the repository's local settings and apply to everyone's future sessions in that repository, which means the team's safety posture is currently the accumulated impatience of its fastest typist.

That is fixable in half an hour, and the reason to do it as a product manager rather than delegating it entirely is that most of the calls are product calls rather than technical ones. Builders Camp's AI Product Management bootcamp frames it exactly that way: how much rope to give the model is a product choice covering what it sees, what it may use, when a human must approve, and what happens when it fails, and most failures trace back to missing guardrails rather than to a weak model.

What do the rules actually look like?

A rule is a tool name with an optional specifier in parentheses, and there are three lists.

List	Effect
allow	Runs without a prompt
ask	Prompts every time, even if an allow rule also matches
deny	Never runs, and cannot be overridden anywhere else

Rules are evaluated deny, then ask, then allow, and the first match in that order wins. Specificity does not change the order, which is the single most useful thing to know: a broad deny such as Bash(aws *) blocks a call that also matches a narrow allow such as Bash(aws s3 ls). An allow rule cannot carve an exception out of a deny rule, and the same holds across settings scopes, so a user-level deny blocks a project-level allow.

A bare tool name in the deny list behaves differently from a scoped one. Bash removes the tool from Claude's context entirely, so the model never sees it. Bash(rm *) leaves the tool available and blocks matching calls when they are attempted.

What should a product team deny outright?

Start here, because deny is the list that cannot be undone by somebody else's convenience later. Four categories cover most of what a product repository needs.

Secrets and credentials first: a Read deny on ./.env and on any secrets directory. A Read deny also blocks the Edit and Write tools on the same path, so one rule covers reading and overwriting. Then anything that touches production: deployment commands, database clients pointed at live data, and the cloud CLI. Then anything that publishes: the commands that send mail, post to a customer channel, or open something to the outside world. And finally the destructive shell verbs that have no undo.

Everything else belongs in ask rather than deny. A team that denies too much ends up with someone running in a mode that skips prompts entirely, which is a worse outcome than the risk they were avoiding.

Which things are safe to allow without a prompt?

The read-heavy, reversible ones. Running the test suite, reading the repository, checking git status and diffs, fetching your own public documentation: these interrupt constantly and almost never merit a decision. Moving them to allow is what buys back the attention you need for the prompts that do matter.

The prompts worth keeping are the ones where a human is the control rather than the bottleneck, which is the distinction Builders Camp's AI Agents bootcamp builds its safety module around: approvals, constraints and monitoring for high-stakes actions, designed so the human stays an effective supervisor instead of a rubber stamp. The glossary entry on human in the loop covers where that line usually sits.

Where do teams get this wrong?

• Assuming a leading slash means the filesystem root. In a path rule, /path is anchored to the settings source, not the root. An absolute path needs two slashes, and getting this wrong writes a rule that silently matches nothing.
• Trusting an allow rule to cover a wrapped command. Claude Code strips a fixed set of wrappers such as timeout and nice, but not environment runners. A rule allowing a runner matches whatever comes after it, which is considerably more than the author intended.
• Believing a deny rule is a sandbox. Read and Edit deny rules cover Claude's file tools and the file commands it recognises in the shell, not a script that opens files by itself. Operating-system level enforcement is a separate feature.

The compound-command behaviour is the pleasant surprise in the other direction. Claude Code understands shell operators, so an allow rule for one command does not approve that command chained to another with &&, and each subcommand has to match a rule independently.

How do you agree on this before something breaks?

Book thirty minutes with one engineer and a whiteboard, and produce three columns: runs without asking, asks every time, never runs. Argue about the middle column, because that is where the disagreement actually lives and where writing it down changes behaviour. Commit the result to .claude/settings.json so it arrives with the repository instead of living in someone's laptop.

Then decide two things most teams skip. Who owns the file, by name, so a change has a reviewer rather than a silent commit. And when it gets read again: quarterly is enough, and tie it to something already in the calendar. A permissions file nobody has reopened in a year is a record of a conversation, not a control.

There is a nuance worth naming at that meeting. Project-level allow rules only take effect once someone accepts the workspace trust dialog for that folder, and deny and ask rules are not affected, because they only restrict. The practical consequence is that a repository you cloned from outside your organisation cannot grant itself permissions on your machine until you say so, and before running a non-interactive session in a repository you did not write, Claude Code offers flags that read no project settings at all.

What permissions will never cover

They cover what Claude Code runs. They do not cover whether what it produced was any good. A perfectly configured permission set will happily allow an agent to write a confidently wrong spec, and nothing in the deny list will notice. That judgement layer is separate, and the glossary entries on AI guardrails and quality gates cover the two halves of it.

Builders Camp teaches this across three bootcamps. Building with Claude Code covers the governance layer directly, including the rule about which external capabilities agents may use and at what access level, with a bias toward read-only until write access is granted deliberately. AI Product Management runs 2 weeks with 4 live sessions and treats agent environment design, evaluation and responsible-AI patterns as product work. AI Agents runs 2 weeks with 3 live sessions and 9 microlessons on tools, guardrails and human approvals for agents that take real actions.

The prompt you keep is the product decision

The useful output of that thirty-minute meeting is not the JSON file. It is the short list of moments where your team has decided a human must look, written plainly enough that a new joiner understands the reasoning rather than just the rule. Teams that get this right tend to end up with fewer prompts than they started with and more confidence in the ones that remain, which is the opposite of what everyone expects a safety exercise to produce.

See the Building with Claude Code bootcamp for the governance module, AI Product Management for the product side of agent risk, or the AI Agents bootcamp for approvals and monitoring on agents that act. For the wider principle, see responsible AI.