[FEATURE] Feature request: policy-driven permission mode for Pro/Max (safety gap)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Subject: Permission-mode tier gating on Pro/Max creates a safety regression and regulatory exposure

This is product feedback, not a bug or a support request. I'm a Max-tier individual customer using Claude
Code for real work at roughly $200 a month, and I want to raise a problem with how permission modes are
segmented between Pro/Max and Enterprise that I don't think the current tier design is pricing in correctly.

Individual Pro/Max users effectively have three permission states: default (prompt on every tool use),
acceptEdits (auto-approve edits only), and bypassPermissions / --dangerously-skip-permissions (run
everything without checking). The middle ground, meaning configurable auto-approve with policy-driven
defaults and granular allow/deny controls, exists in the Enterprise configuration surface but is not exposed
to paying individual customers.

This forces high-usage power users to pick between constant interruption that breaks flow on every tool
call, or bypass mode, which is explicitly the least safe state the tool supports and which Anthropic's own
warnings flag as dangerous. There is no middle state available for individual paying users, despite the
middle state being exactly what an experienced power user wants.

This is a safety regression, not just a feature gap. Anthropic's public brand is safety-focused AI. Gating
the intermediate safety configurations pushes individual high-frustration users toward the bypass mode you
yourselves warn against. The tier split inverts the expected safety ordering: Enterprise customers get safer
defaults while individual paying customers are pushed toward the most permissive and least-audited mode.

This is not hypothetical. One individual power user running --dangerously-skip-permissions because the
alternative was untenable, and then leaking credentials, corrupting work, or triggering unintended external
side effects, is a predictable outcome of the current design. It is exactly the category of incident that
becomes a blog post, a Hacker News thread, or a press article, and the story writes itself: Anthropic gated
the safe mode behind enterprise pricing, so users flipped the dangerous switch.

On the regulatory side, the political environment around AI is not distant or abstract. The EU AI Act is in
force. California has passed and is passing AI-specific consumer protection legislation. FTC is scrutinizing
AI consumer practices. The pattern of safety-adjacent features gated behind enterprise tiers while
individual consumers receive a worse and riskier product maps directly onto the arguments currently driving
AI legislation: arguments about models trained on broad public and creative output being captured behind
paywalls that disproportionately benefit corporate customers.

Anthropic operates under an implicit political license that depends on being seen as a company that treats
individual users seriously rather than as a revenue afterthought next to the enterprise motion. That license
is a real asset. It erodes in small increments product teams do not always measure, and the permission-mode
tier split is one of those increments. It is a small, visible data point that works against the brand
position the company is trying to defend.

Pricing segmentation between consumer and enterprise tiers is standard SaaS practice and I am not arguing
against it in general. The specific issue is that safety-adjacent configuration should not be on the
enterprise-only side of the line, even when other features legitimately are. Pricing segmentation is normal.
Safety segmentation creates direct brand and regulatory risk that ordinary feature gating does not.

What I am actually asking for: configurable allow and deny lists for tool use on Pro and Max tiers; a
policy-driven intermediate permission mode between acceptEdits and bypassPermissions, effectively a settings
file that specifies which tool calls auto-run, which require approval, and which are forbidden, without
requiring an enterprise contract; and explicit acknowledgement that safety-adjacent configuration is not a
standard feature-gating candidate, even when other enterprise capabilities legitimately are.

Please do not treat this as a support ticket or route it to sales. The specific product ask is secondary.
The primary point is that the current design creates a measurable safety and regulatory exposure that the
individual feature decision does not reflect, and the fix is small compared to the downside it prevents.

Dan
Max-tier customer

Proposed Solution

What I am actually asking for: configurable allow and deny lists for tool use on Pro and Max tiers; a
policy-driven intermediate permission mode between acceptEdits and bypassPermissions, effectively a settings
file that specifies which tool calls auto-run, which require approval, and which are forbidden, without
requiring an enterprise contract; and explicit acknowledgement that safety-adjacent configuration is not a
standard feature-gating candidate, even when other enterprise capabilities legitimately are.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Developer tools/SDK

Use Case Example

I am working on a project to 4 projects concurrently
I do not want to hit approve every 30 seconds to a minute and have to hop between windows to do it.
The only option available is to disable permissions.

Additional Context

_No response_