Claude Code security checklist for website teams

Securing Claude Code on a website project comes down to five layers: the account and data terms you use, the permission rules in the project, what Claude can reach on your machine, what outside tools and content you connect, and the review gates that stop an unreviewed change from going live. Each layer has a few settings that matter. Get them right once, commit them to the repository, and every session on that project starts from the same safe baseline.

This checklist is for owners, marketing managers and small web teams setting Claude Code up on a business site, as of October 2026. It names Anthropic's actual controls and what they do and don't cover. It isn't a full security program, and it doesn't replace a developer's review of code that handles payments or personal data. For the bigger picture of why these controls matter, read our overview of whether Claude Code is safe for production websites.

1. Accounts and data terms

2. Install and machine

• Install from Anthropic's official sources. The native installer runs from claude.ai, and package-manager options are listed on Anthropic's setup page. Copy install commands from Anthropic's setup docs, not from forums.
• Keep it updated. Native installs update in the background. Homebrew, WinGet and Linux package-manager installs need manual updates by default. Run claude --version to check.
• Know what's on the machine. Anthropic notes that a command you approve "can still write anywhere your user account can," and shell commands can read credential files such as SSH keys (the keys that log you into servers) unless you block them. A laptop with a saved production server login is a riskier place to run it.
• Trust folders deliberately. Claude Code asks you to accept a folder before loading its configuration. Accept only projects you know, because a repository's settings can include hooks, scripts that run automatically and "execute shell commands with your full user permissions."

3. Project permission rules

Put these in the project's .claude/settings.json and commit it, so everyone who clones the repository gets the same rules. Anthropic's permission docs explain that rules "are enforced by Claude Code, not by the model."

A minimal version:

{
"permissions": {
"deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"],
"ask": ["Bash(git push *)", "Bash(gh pr create *)"]
}
}

Know the gaps. Ask rules match the command as written, so git -C . push isn't caught. Read deny rules don't cover a command such as grep -r that reads files without naming them. And a .claudeignore file "has no effect": move its entries into deny rules. Run /permissions to see the active rules, and Anthropic recommends auditing them regularly. Copy-ready versions are on our Claude Code templates page.

4. Permission modes

• Use Manual or Plan for unfamiliar code and sensitive changes. Manual asks before edits and commands; Plan proposes without editing source files.
• Use auto mode with ask rules, on a copy. Since v2.1.283, auto mode is the starting mode for terminal and VS Code sessions. A classifier, a separate AI model that checks each action, blocks actions such as force pushes, production deploys and sending sensitive data to outside endpoints, but Anthropic says it "does not guarantee safety," and it allows pushes to any branch by default.
• Never use bypass mode on a real project. Anthropic says it "offers no protection against prompt injection (hostile instructions hidden in content Claude reads) or unintended actions" and is for "isolated containers and VMs only."
• Lock bypass out. Setting permissions.disableBypassPermissionsMode to "disable" blocks it. Admins usually set it in managed settings, and Anthropic notes a user can set it for themselves too.

Every mode is compared in our guide to Claude Code permission modes.

5. The sandbox

Permission rules are checked by Claude Code. The Bash sandbox is enforced by the operating system around the shell commands Claude runs.

• Turn it on with /sandbox or the sandbox.enabled setting. It runs on macOS, Linux and WSL2; on native Windows, commands run unsandboxed.
• Know the defaults. Writes are limited to the working directory and temp folders. Network access starts with no allowed domains. But reads cover "most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials," so add those to the sandbox's read denials.
• Know the limit. "The sandbox covers shell commands only. Claude's file tools, MCP servers, and hooks run outside it." Use it alongside deny rules, not instead of them.

Details are on Anthropic's sandboxing page.

6. Secrets

• Never paste passwords, API keys or tokens into a prompt or into CLAUDE.md. CLAUDE.md is usually committed to git, and prompts are stored in transcripts.
• Keep environment files out of git with a .gitignore entry, and out of Claude's reach with deny rules.
• Turn on GitHub's secret protections. Push protection "blocks pushes that contain secrets before they reach your repository." Secret scanning runs free on public repositories; private organization repositories need GitHub Secret Protection. Note that anyone with write access can bypass push protection by giving a reason.
• If a secret is exposed, rotate it. GitHub's guidance is to "rotate the affected credential immediately." Removing it from the next commit doesn't remove it from history.
• Use separate, limited keys for staging, so a leaked staging key can't touch live customers or payments.

Our guide to keeping secrets away from Claude Code goes further.

7. Outside content, MCP servers, plugins and hooks

Prompt injection is hostile text in a web page, file or tool result that tries to steer Claude toward actions you never asked for. Website work reads plenty of outside content, so this layer matters.

Anthropic is direct about limits: "no system is completely immune to all attacks." Our guides to prompt injection on websites and MCP servers for website teams cover this layer in depth.

8. Review and deploy gates

• Every change is on a branch and reviewed as a diff by a person.
• /security-review runs on changes to forms, logins, uploads and anything that takes user input, and a developer reads the findings.
• GitHub branch protection on main requires an approved pull request, with the rules applied to administrators too.
• Nobody, human or Claude, deploys an unreviewed change. Our pre-deploy checklist covers the final gate.

9. Organization controls for Team and Enterprise

• Managed settings are enforced org-wide, and user and project settings can't override them. Server-managed settings are available on Team and Enterprise.
• Remove risky modes centrally: permissions.disableAutoMode and permissions.disableBypassPermissionsMode, each set to "disable."
• Set spend limits on usage credits at the organization, group or member level, so a runaway session can't run up costs.
• SSO is on Team and Enterprise. SCIM (automatic adding and removing of user accounts from your identity system), the Compliance API and zero data retention (for qualified accounts, arranged with Anthropic) are Enterprise options, according to Anthropic's pricing page.

Conclusion

A secure Claude Code setup for a website isn't one switch. It's a short list done once and committed: commercial terms or a checked training setting, deny rules for secrets, ask rules for pushes, the sandbox on, vetted MCP servers and plugins, no secrets in prompts, and a person approving every deploy. Revisit it when your team, tools or plan change, and audit permissions regularly. If you'd like help putting these controls in place and training your team on them, our Claude Code consulting covers permissions, hooks, MCP setup and review processes. More guides are in our Claude Code Guide.

Frequently asked questions