Claude Code Security: Permissions, Sandbox and Secrets for Teams

Claude Code Security: Permissions, Sandbox and Secrets for Teams

To use Claude Code safely in a company, combine three layers: explicit permissions (what the agent can read, run and change), isolation (where it runs and what it can reach on the network and the disk) and credential protection (the agent should never see production secrets). Start restrictive, record what was approved, and widen access only on evidence from real use.

Claude Code reads code, runs commands and edits files. That is what makes it useful, and it is also why it demands discipline. This guide covers the decisions a technical lead or operations owner should make before opening it up to the team.

Key takeaways

• Treat Claude Code as a collaborator with terminal access: give it the least access that still lets it do the job, and review what it asks to run.
• Use permission rules at three levels (allow, ask, deny) and keep the company configuration in a versioned, managed file, not on each person's machine.
• Run the agent in an isolated environment (a sandbox, a container or a disposable development machine) with no access to production.
• Keep secrets out of the agent's reach: blocked environment files, short-lived credentials and minimal scope.
• Be wary of external content (web pages, issues, documents, MCP servers): it can carry malicious instructions.

What is the real risk of using Claude Code in a company?

The risk is not that the model turns malicious. It is in three common situations: the agent runs a destructive command by mistake, the agent reads a secret and repeats it in a log or a commit, or the agent follows an instruction hidden in content it read. The last two are well-known failure modes in applications built on language models, described in the OWASP Top 10 for LLM applications.

So the useful question is not whether Claude Code is safe, but what it can do if it makes a mistake or is tricked. If the answer is deleting the project folder on a disposable machine, the risk is manageable. If the answer is changing the production database with an administrator credential, the design is wrong, whatever the tool.

There is also a personal data dimension. If the repository or the test files contain customer data, working with the agent becomes data processing. In Brazil, the data protection authority (ANPD) is the official reference, and your legal team or data protection officer should have a say in what can enter the agent's context. Teams that run channels such as WhatsApp face the same question, covered in LGPD compliance for AI on WhatsApp: legal basis, consent and records.

How to configure permissions: deny, ask, allow

Claude Code works with permission rules that can be defined in configuration files at different levels: personal, project and organization-managed. The logic that works for companies is simple: anything dangerous is denied, anything ambiguous requires confirmation, and only what is routine and reversible is allowed without asking. Always confirm the exact syntax and names in Anthropic's official documentation for the version your team uses, because these details change.

A practical way to classify actions:

• Allow without asking: reading project files, running tests, linters and formatters, read-only version control commands (status, diff, log).
• Always ask: installing dependencies, writing outside the project folder, network calls, commits and branch creation, any command that changes configuration.
• Always deny: reading environment and key files, recursive delete commands, force pushes, access to the user's credential folders, commands that call production systems.

Three precautions make a difference:

• Keep the company configuration in a managed policy file, so nobody can loosen the rules locally without it being visible. The project file, versioned in the repository, is for rules specific to that codebase.
• Avoid the mode that skips all confirmations outside an isolated, disposable environment. It can be reasonable inside a container with no network and no secrets, but never on a machine that can reach anything important.
• Review the allowed rules periodically. Permission rules tend to grow out of convenience (approved once, left forever) and nobody prunes them.

This least-privilege logic is not specific to AI. The OWASP authorization guidance describes principles such as deny by default and least privilege, which work as a yardstick for reviewing your configuration. To decide which actions need human approval in broader workflows, see the AI agent approval policy template.

Sandbox and isolation: where should the agent run?

Permissions define what the agent can ask for. Isolation limits the damage when a permission is granted by mistake or when the agent is induced to do something it should not. The two layers complement each other, and the second does not depend on anyone clicking correctly on every confirmation.

Claude Code offers isolation features for command execution that restrict access to files and the network. Check the official documentation for which platforms and options exist in your version. A company can also build isolation on its own. The most common options, from simplest to strongest:

• A dedicated working folder, with a copy of the repository and no access to the rest of the disk.
• A development container with only the code mounted and none of the user's credentials.
• A virtual machine or disposable cloud environment, created per task and destroyed afterward.
• A network restricted to an allowlist of destinations, so the agent cannot send data to unknown addresses.

The deciding factor is what exists on the machine where the agent runs. A personal laptop with SSH keys, logged-in cloud sessions and customer files calls for strong isolation. A fresh container with a test repository and no credentials can tolerate looser rules.

It also helps to separate environments by purpose: one for exploring and writing code, another (with a human in control) for anything that touches real integrations. The agent should not have a network path to production from the environment where it experiments.

How to protect secrets and credentials

The costliest mistake is usually the most mundane: a broadly permissioned key stored in an environment file at the project root, which the agent reads to understand the configuration. From there, the secret can show up in a response, a log, a commit or a shared context.

A minimum secrets policy for Claude Code use:

• Block reading of environment files, private keys and credential folders with deny rules. Do not rely only on asking the agent not to read them.
• Use example files (with no real values) to document variables. The agent understands the structure without seeing the secret.
• Give the development environment its own credentials, with minimal scope and access to test data only. Never reuse production keys.
• Prefer short-lived, revocable credentials. If a key leaks, the impact should be small and the replacement quick.
• Turn on secret scanning in the repository and the pipeline, to catch what slips through before it reaches the history.
• When an integration uses OAuth, follow the flow documented by the provider, with minimal scopes. Google's OAuth 2.0 documentation is a clear example of requesting only the scopes you need.
• Keep a written rotation procedure: who replaces the key, where, and how you confirm the old one stopped working.

If a secret was ever shown to the agent, treat it as compromised and rotate it. Do not bet that nobody will look at the conversation history.

Prompt injection and external tools: what changes?

When Claude Code reads a web page, an issue, an attached document or a tool's response, that text enters the context and can contain instructions. A seemingly harmless comment in a file can ask the agent to send data out or run a command. This pattern is prompt injection, and the OWASP prevention guidance lists layered defenses.

In practice, for teams:

• Treat all external content as untrusted, even when it comes from a company repository that accepts third-party contributions.
• Pair untrusted input with very few possible actions. If the agent reads public issues, it should have no network permission and no access to secrets in that same session.
• Manually approve any command that sends data out (curl, uploads, pushes to an unknown remote repository).
• Install only MCP servers and extensions from sources the company has evaluated, using an approved list. Each server widens what the agent can do and what it can read.
• Review the parameters and scopes of each connected tool. A tool that reads tickets but can also close tickets has more power than it needs.

The same reasoning applies to agents exposed to customer messages, such as WhatsApp agents. The OpenClaw Gateway security checklist shows how to think about evidence before exposing an agent to external input.

A staged rollout plan

A simple sequence for opening up use with control, without trying to solve everything at once:

• Stage one, map: list who will use it, in which repositories, on which machines and with which credentials available. Also note whether the repositories contain personal data.
• Stage two, limit: define the managed policy file with the deny, ask and allow rules. Block environment files. Choose the default isolated environment.
• Stage three, prepare credentials: create development keys with minimal scope, turn on secret scanning and document rotation.
• Stage four, pilot: pick a low-risk repository and a small group. Define in advance what counts as success and what is a reason to stop. To structure the measurement, use the guide on how to measure an AI automation pilot.
• Stage five, hand over and decide: deliver the configuration, the runbook and the owners. With the pilot records in hand, decide whether to expand, adjust or stop.

This sequence follows the method we use in AI projects: map the current process, limit data and actions, pilot a real workflow with records and an agreed metric, and only then hand over and decide. For the organizational side of adoption (roles, training, code review), see the Claude Code adoption guide for teams.

Illustrative scenario: two setups for the same task

Imagine, as an example, a logistics company with an internal tracking system and a developer who asks Claude Code to fix a bug in a carrier integration module.

In the first setup, the agent runs on the developer's laptop, which has an active cloud session, SSH keys and an environment file with the carrier's production credential. Every confirmation has been switched off to go faster. If the agent reads a malicious comment in a dependency, it has a path to real data and real actions.

In the second setup, the agent runs in a container with only the repository, none of the user's keys and a restricted network. The real environment file is blocked by rule, only an example file exists, and the test credential reaches nothing but a staging environment. Install and network commands ask for confirmation. The task is the same and the productivity is similar, but the worst case changes from an incident involving operational data to restarting a container.

This contrast is the reason to start with isolation and secrets, before any fine-tuning of permissions.

Frequently asked questions

Is it safe to use Claude Code with company source code? It depends on what the company defines as acceptable for data and intellectual property, and on the terms of the plan you hold. Read Anthropic's official documentation and terms on data handling, involve legal and security, and limit the pilot repositories to ones that have already been reviewed.

Can I rely only on the confirmations Claude Code asks for? No. Confirmations depend on human attention, and the fatigue of approving dozens of requests leads to automatic clicking. Use confirmations as one layer, and add deny rules, isolation and minimal-scope credentials, which work even when someone approves without reading.

What should I do if a secret was exposed in the agent's session? Consider the credential compromised and rotate it immediately, without waiting for an investigation. Then check the key's usage logs, remove the value from any file or history where it appeared, and fix the rule that allowed the read so it does not happen again.

Do I need a different policy for people who are not developers? Yes, and generally a stricter one. People in operations or marketing who use the agent for automations and spreadsheets should work in dedicated folders, without access to credentials, and with human approval for any action that changes systems or sends messages to customers.

Sources

• OWASP: Top 10 for LLM Applications
• OWASP: LLM Prompt Injection Prevention Cheat Sheet
• OWASP: Authorization Cheat Sheet
• ANPD: Autoridade Nacional de Proteção de Dados