What is Claude actually allowed to do? Security and control in your company

When I introduce Claude Code to companies, the first "wow" is almost always followed by the same question: "And what if Claude does something it shouldn't?"

Fair question. The good news: Claude Code comes with several layers of security that you can configure deliberately.

🔐 Permission rules

In settings.json you define what's allowed, what needs confirmation and what's off limits. Deny rules take precedence. For example: run tests anytime, but never read .env files and no git push without asking.

🧱 Sandbox

With /sandbox, shell commands run in an isolated environment with restricted file and network access. Claude can work more freely inside it without any command breaking out.

🏢 Managed settings

For teams, there are centrally managed settings that individual developers can't override. That's how you enforce rules like "nobody reads secrets" once, for everyone.

🧩 Allow extensions deliberately

Plugins, MCP servers and the new mods (part 2) extend what Claude can do. Mods run with the same access as Claude Code itself, so only install them from trusted sources. Admins can control which plugin marketplaces are allowed.

👀 Keep a human in the loop

No setting replaces review. At our company, code from Claude takes the same path as any other code: branch, pull request, review.

My rule of thumb:

• For a project: check the rules into the repository so everyone shares the same guardrails.
• For a company: managed settings plus a short, clear list of approved extensions.

Security isn't a brake here. With clear guardrails, you can give Claude more freedom, not less.