Securing Claude Code: Permissions, Access Controls, and Approval Boundaries

A developer asks Claude Code to update a customer management feature. The agent finds a failing migration, suggests a terminal command to repair the database, and is ready to run it. The command might be harmless against a disposable local database. Against a shared environment, it could affect real customer records.

That distinction is where AI coding security begins. The question is not whether an agent can write a safe implementation. It is what the agent is allowed to read, change, execute, and connect to while it works.

For teams using Claude Code on enterprise applications, permissions should be treated as part of the engineering environment—not as a warning a developer is expected to notice at the last moment.

How can teams secure Claude Code for enterprise development?

Teams can secure Claude Code by limiting its access to the code, data, tools, and systems required for development. Use scoped permission rules and supported sandboxing, isolate production credentials and customer data, and require independently enforced approvals for high-impact actions.

Project instructions help an agent follow engineering conventions, but they do not replace operating-system permissions, identity controls, network restrictions, code review, or protected deployment pipelines. A secure workflow combines these controls and tests them against real developer tasks.

1. Separate coding authority from operational authority

An AI coding agent can be valuable with access to source code, a local test database, and approved build tools. It rarely needs credentials for production infrastructure to implement a feature.

Consider a CRM project. Claude Code might need to update a lead assignment service, add tests, and run a migration on a development database. None of that requires direct access to the production CRM database, deployment secrets, or live customer exports.

One useful policy is to distinguish development actions from operational actions. Let the agent work within a restricted development workspace. Keep production deployments, high-impact database operations, and changes to privileged access behind separately enforced approvals.

These are suggested organizational controls, not Claude Code defaults. An explicit rule in a repository does not, by itself, remove privileges already granted to an operating-system account or cloud identity.

Practical example: for a CRM database change, allow Claude Code to generate a migration and run it against disposable test data. Require human review before merging a destructive migration, and ensure the production deployment pipeline uses credentials unavailable to the agent.

2. Understand what Claude Code permission settings actually control

Claude Code provides permission modes and fine-grained allow, ask, and deny rules. Teams can use shared project settings, while organizations can apply higher-priority managed settings. Anthropic documents how these settings differ and how precedence works.

For example, a team may allow its familiar test command while requiring review of other shell commands. That reduces repetitive approvals without granting broad shell access. Keep patterns narrow; an overly broad shell rule can approve more than its author intended.

There is another distinction worth making: instructions are not enforcement. A sentence in CLAUDE.md saying “do not access production” is useful context, but it does not replace identity permissions, network isolation, or a hard production access boundary.

For the current behavior and exact supported syntax, consult Anthropic's Claude Code permissions documentation and settings precedence guide. Permission behavior can vary by operating environment and mode, so a proposed policy should be tested before team-wide rollout.

3. Use sandboxing, but know where its boundary ends

Sandboxing limits what a command can access on the host. In supported environments, Claude Code's shell sandbox can restrict filesystem locations and network connections. This is useful when an agent needs to run tests, build assets, or inspect code without gaining unrestricted reach across the developer's machine.

But sandboxing is not a universal security wrapper. Anthropic's documentation states that its shell sandbox covers shell commands; Claude's file tools, integrations, and hooks have separate behavior. Native Windows also differs from running Claude Code within WSL2.

That means a secure setup requires multiple layers: restricted operating-system credentials, a minimal workspace, network boundaries, carefully configured integrations, and explicit approval for sensitive operations.

See the official sandbox documentation for supported environments and limitations.

Claude Code permissions, sandboxing, and external security controls compared

These controls operate at different layers. Teams should use them together rather than assuming one setting protects every operation.

The exact protections depend on the Claude Code version, configuration, operating environment, and external systems. Test the intended boundaries with representative tasks before adopting them as policy.

4. Keep secrets and customer data out of the development context

Developers often have more access than a coding task requires: local cloud credentials, environment files, database connection strings, support exports, or customer records used for debugging. An agent operating with the developer's privileges may encounter sensitive information through files or tools.

The safer design starts before a Claude Code session:

• Use synthetic or properly de-identified test data rather than production customer exports.
• Provide separate development identities with only the privileges required for the task.
• Store credentials in approved secret-management systems; avoid including secrets in prompts, committed files, or logs.
• Review shell tools, MCP servers, and external integrations before enabling them for a project.
• Rotate exposed credentials and investigate access if sensitive values appear in an agent transcript or generated artifact.

For an ATS, this is especially important: candidate profiles can contain contact details, employment histories, and other personal information. Testing a parsing or matching feature should not require placing an entire production candidate database in an agent-accessible workspace.

5. Treat repository content and external results as untrusted input

Not every instruction an AI agent encounters comes from the person using it. A source file comment, package README, issue description, retrieved webpage, or tool response can contain text that tries to redirect the agent. This is commonly called prompt injection.

For example, an agent reading a dependency's documentation might encounter a disguised instruction to run a remote installer or disclose environment variables. That text is part of the material being inspected; it should not be promoted into an authorized instruction.

Limit the external sources and tools available during a task, review unexpected commands, and do not assume that content found inside the repository is trustworthy merely because it is local. Anthropic's security guidance discusses prompt-injection protections and user responsibilities.

6. Make approval boundaries specific enough to use

“Ask before doing anything risky” sounds sensible, but it is too vague to guide a busy engineering team. Approval requirements work better when they refer to recognizable events: changing a role-permission matrix, deleting data, adding a new external service, rotating credentials, or promoting a release.

Consider these three practical decisions:

1. A new API endpoint: Claude Code can draft and test it in development. The merge request must demonstrate authorization and input validation.
2. A database migration: Claude Code can prepare the migration and run it against a disposable test database. Destructive changes require a reviewer to assess backup, rollback, and data-loss implications.
3. A production deployment: Claude Code can assemble release notes or a deployment plan. The deployment identity and release gate should require authorized approval outside the agent session.

The objective is not to interrupt developers for ordinary edits. It is to make exceptional authority visible and deliberate.

7. A starting security policy for engineering teams

Teams do not need an elaborate governance program to begin. Start with a documented baseline that security and engineering leaders can enforce and audit:

Review the policy periodically as the team's tooling and Claude Code capabilities change. The best configuration is not the most restrictive one on paper; it is the one developers can follow consistently, with meaningful barriers where mistakes would matter most.

Security should be designed into the workflow

Claude Code can help engineering teams move faster, but speed does not justify giving a coding agent the same authority as a production administrator. A useful default is simple: provide enough access to complete development work, and no more.

Permissions determine which actions need approval. Sandboxing limits some of the places commands can reach. Identity, network, secret-management, code-review, and deployment controls provide the other boundaries. None replaces the others.

In our earlier article, Beyond Prompting: A Structured Development Workflow for Claude Code, we examined how to organize AI-assisted development. Security is the next part of making that workflow practical for teams.

Security-sensitive changes also need independent verification. Our guide to enforcing quality gates for AI-generated code with GitLab CI/CD explains how automated checks and human review can strengthen that process.