Claude Code security guide: permissions and app reviews

By Thunkle · Platform references checked 19 September 2026

A Claude Code security review has two jobs: limit what the agent can do while it works, and verify the application it produces. Permission prompts address the first job. They do not prove that a generated billing route, invitation flow or database rule is correct.

This guide is for founders and teams shipping code with Claude Code, not a claim that Claude Code or every generated application is vulnerable. For an application approaching launch, our Claude Code audit reviews the agreed code and running behaviour together.

Make developer review a separate release step

Claude Code can help write and analyze a change, but a release still needs someone to challenge its assumptions against your product's rules. A senior developer should review privileged paths and test realistic misuse cases, rather than treating an agent's explanation or passing generated tests as the entire assurance process. Keep this review distinct from configuring the agent's own permissions.

Our paid Claude Code audit gives the finished application a developer-led audit against an agreed scope. Expect evidence-backed findings and prioritized remediation guidance, not a security certificate for everything the agent might build next. Agreed fixes include a free re-review; implementation is separately scoped.

Review the working environment before the task

Anthropic documents permission modes, directory boundaries, sandbox controls and prompt-injection safeguards. Their behaviour depends on the selected mode and configuration. Check the controls actually active in your installation rather than assuming a teammate's settings apply to you. Claude Code security documentation.

Our practical starting point is a development checkout with synthetic fixtures, test-mode integrations and no production administrator credentials. A task to edit a component should not require permission to change production data. If a task needs broader access, identify the exact system and operation first.

Treat repository instructions, hooks, MCP servers and package scripts as things to review, not merely helpful context. A project file can tell an agent how the team works, but text saying “never deploy” is not a substitute for controlling deployment credentials and permissions. Do not approve unfamiliar commands solely because they appear in a setup guide or issue description.

Ask for an authorization model, not just working screens

Before a substantial feature, write a few business rules the implementation must preserve. For a synthetic subscription product:

• A member can view their organization's invoices but not another organization's.
• Only the owner can change billing details.
• A payment event must be verified before it changes subscription status.
• Retrying the same accepted event must not apply the purchase twice.

These are review requirements, not evidence of a client incident. Give the agent the rules, then inspect where the implementation enforces them. Authentication, organization membership and authority to perform an action are separate questions.

Read the entire change, including what the tests stopped checking

An agent can modify the route, its database helper and its tests in one task. A green suite may mean the feature is correct, or that the assertions now accept the wrong behaviour. Review deleted tests, relaxed validation, expanded permissions and dependency changes alongside the visible feature.

Watch for a development fallback that grants access when a session or provider is unavailable. Decide whether that fallback belongs in the shipped product. Follow privileged database calls to their caller checks: moving code to the server does not itself restrict which customer may invoke it.

If the patch is too large to explain, split review by trust boundary: browser to server, server to database, and server to payment or email provider. Keep a record of which release and configuration you examined.

Run a negative test that the happy path cannot replace

In an authorized staging environment, create two ordinary accounts in different organizations and one owner account. Confirm each ordinary account can read its own invoice. Then verify that it cannot retrieve the other organization's invoice or update owner-only billing details. Inspect the saved state after the forbidden write.

Keep the successful request as a control. A missing fixture or expired session must not count as isolation. Our two-account experiment explains this distinction. Do not use real customer invoices, send production emails or exercise live payment actions as casual tests.

Keep useful automation and add independent acceptance criteria

Use Claude Code's review capabilities, dependency checks and security tooling. Automated review can identify missing checks and cross-account flaws; there is no need to pretend only a human can find them. The additional value of a scoped audit is checking the intended product rules, validating findings and recording coverage and limitations.

Does restricting Claude Code secure the deployed app?

No. Agent restrictions govern development actions. The deployed app still needs its own authorization, secret handling and operational controls.

What should an audit deliver?

Prioritized findings with reproduction evidence, affected paths and practical fixes, plus explicit untested areas. Fix implementation can be scoped separately and agreed fixes receive a free re-review. No audit can guarantee that every vulnerability has been found.

Get a security audit quote. Share the app URL, roles, important workflows and deadline; do not send secrets or customer exports. We agree access and test scope before work begins.