Claude Code security: permissions, hooks and the gaps around them

Claude Code has a serious native security model. It asks for permission before sensitive operations, supports managed settings and hooks, can run inside development containers and gives administrators ways to control configuration.

Those controls are valuable. They also have a defined scope: Claude Code governs Claude Code. It does not automatically apply the same policy to Codex, Cursor, CI, a human terminal or a hosted agent that changes the same repository.

Use Claude Code’s controls for its own execution surfaces. Add an independent layer when the same repository also moves through other agents, editors and CI.

What Claude Code’s native controls do

Permission rules

Permission rules decide which tools Claude Code may use and when the user must approve them. Teams can allow common development operations while denying specific tools or command patterns. Managed settings help administrators make important restrictions harder to override.

Sandboxing and isolation

Isolation limits the environment available to the agent. Anthropic recommends development containers for stronger separation in sensitive work. A container can reduce exposure to the host filesystem and credentials when its mounts, network and privileges are configured carefully.

Hooks

Hooks let teams run deterministic logic at lifecycle points such as before a tool call. They are useful for validation, logging and enforcement around supported operations. A hook is code, so it needs review, secure distribution and testing of failure behaviour.

Configuration controls

Claude Code uses project and user configuration. Persistent instructions shape agent behaviour across sessions. Teams should review changes to those files because a repository can alter the context in which the agent works.

Security review

Claude Code Review uses multiple agents to examine pull requests and verify candidate findings. Anthropic states that the review reports findings but does not approve or block the pull request. That makes it an investigator and reviewer rather than the organization’s final merge policy.

A sensible Claude Code baseline

1. Keep permission prompts enabled for sensitive tools.
2. Use project-specific allow rules instead of broad global approval.
3. Use managed settings for restrictions that should not be user-overridable.
4. Run high-risk repositories in a well-configured development container.
5. Limit network access and credentials to what the task requires.
6. Review project instructions, hooks, plugins and MCP server changes.
7. Keep code review and CI controls outside the interactive session.

This baseline preserves Claude Code’s intended protection instead of treating third-party security as a replacement.

Why teams still bypass permissions

Interactive approval has a usability cost. A long task may need the same build tool, test runner and package manager many times. If every safe operation interrupts the user, broad approval becomes the practical response.

The right lesson is not that users are careless. It is that tool authority and operation policy are separate decisions.

A developer can allow shell access for normal work while a separate guard continues to block a production database drop or recursive deletion on a protected path.

Where the Claude Code boundary ends

Surface	Claude Code control	Additional boundary
Claude tool calls	Permissions, sandbox and hooks	Organization policy on supported interception paths
Repository after the session	Review inside Claude workflows	Continuous cross-provider scanning and CI
Dependencies	Model reasoning and configured hooks	Registry provenance, malware and lockfile policy
Other coding agents	Outside Claude Code	Shared workspace and provider-independent controls
Remote APIs	Network permission around Claude	Scoped credentials, gateway policy and service-side enforcement
Production systems	Limited by the credentials it receives	IAM, deployment protection and database policy

This is not a criticism of Claude Code. Every product has a boundary. Good security architecture makes the boundary explicit then connects it to the next control.

What an independent layer should add

One policy across providers

The same repository may be changed by Claude Code in the morning, Cursor after lunch and CI overnight. Code and supply-chain policy should not depend on which tool produced the change.

Continuous deterministic checks

Fast local checks can run on every saved change without another model call. The same revision, rules and policy should produce the same decision. This matters for regression prevention, audit evidence and merge gates.

Supply-chain and agent configuration monitoring

Inspect packages, lockfiles, MCP configuration, skills and persistent instruction files. These artifacts can alter agent behaviour or introduce executable code without appearing as an application vulnerability.

Runtime policy on supported paths

A pre-execution hook can evaluate defined catastrophic operations before they run. The product must state whether the hook is merely configured or has live proof from the current host.

Durable evidence

Bind a security result to the repository revision, ruleset and policy. Record the initiating tool and sanitized reason when an action is blocked. This gives a team evidence that survives the end of the Claude session.

How Claude Security and deterministic scanning fit together

Claude’s deeper security products use frontier reasoning to map architecture, explore a repository and validate subtle findings. That is strong for novel vulnerabilities and business logic. It is also more expensive and less reproducible than a deterministic check.

The efficient workflow is:

1. Run deterministic checks continuously.
2. Package relevant files, call paths and evidence for ambiguous or high-impact cases.
3. Let Claude investigate the semantic problem.
4. Have a human or independent verifier challenge the result.
5. Validate the patch with tests, rescanning and policy.
6. Turn confirmed findings into durable regression controls where possible.

Claude supplies depth. The control plane supplies consistency, coverage and enforcement.

What to show developers in the UI

A security dashboard should not say “protected” without qualification. For each Claude Code integration, show:

• Which hook or adapter is installed
• Which actions it can observe
• Which actions it can block
• The policy revision in force
• The time of the most recent live proof
• Which remote or native operations remain outside coverage

That level of honesty helps developers use Claude Code with more authority, not less, because they can see exactly where the safety boundary is real.