Is Claude Code Safe? Security, Permissions and Risks

Every time I recommend Claude Code to another developer, two questions come up before anything else — not “how does it work” or “what does it cost,” but two questions about trust. Does Anthropic see my code? And can I actually trust what it writes? Both concerns are legitimate. Here are honest answers to both.

New to Claude Code? Start with What is Claude Code? — this post assumes you know the basics.

Concern 1: Data Privacy

Claude Code runs tools locally, but model requests can include your prompts, instructions, file content and tool results. That can include content the agent reads while working, not just text you pasted yourself. MCP integrations create another data boundary: their servers receive the requests and arguments sent to them. Treat the accessible project and integrations as part of your review, rather than assuming local execution means local-only processing.

Training policy depends on how you access the product. Anthropic says commercial accounts, including Team, Enterprise and API customers, are not used to train generative models unless the customer opts in. Consumer Free, Pro and Max accounts use a separate model-improvement setting. Check your account setting and applicable agreement; do not infer the policy solely from the fact that you are using Claude Code. See the current data-usage policy.

That said, the session boundary is the thing to be deliberate about. If you paste a database connection string into the chat, or ask Claude Code to read a file containing API keys, that content is in the session and is transmitted. The same discipline you apply to committing secrets to git applies here: keep them out of context entirely.

Do not rely on .claudeignore as a security control. The documented configuration uses permissions in .claude/settings.json. For example, these deny rules restrict the Read tool for named project paths; merge them into existing settings rather than replacing the file:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./credentials/**)"
    ]
  }
}

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./credentials/**)"
    ]
  }
}

Read-tool rules are not a blanket filesystem boundary: shell commands and external MCP services need their own controls. Keep production credentials out of the development environment where possible, use least-privilege accounts and review permissions alongside sandbox filesystem and network restrictions. Git ignore patterns prevent neither local access nor transmission. Do not paste secrets into the conversation.

If you work in a regulated industry — financial services, healthcare, anything with strict data residency requirements — apply the same scrutiny you would apply to any third-party cloud tooling. Read the Anthropic privacy policy. Understand what a session includes. Make an informed decision, not an anxious one.

For teams, review shared permissions, sandbox settings and MCP server definitions before accepting them into a project template. Test with harmless fixture files, not live credentials. An ignore file or a natural-language instruction is not evidence that every access path is blocked. If an integration fails, use the MCP connection troubleshooting guide without widening permissions as a workaround.

Concern 2: Code Quality and Security

Claude Code can write insecure code. I want to be direct about this: it is not a security scanner, it does not know your specific threat model, and it does not replace code review. If you treat its output as production-ready without checking it, you will eventually merge something you should not have.

The mental model that works for me: treat Claude Code like a capable junior developer. The code is usually good. Sometimes it is very good. Occasionally there is something you would catch in review — a missing input validation, an overly permissive database query, an unhandled error case. The review catches those. You would not merge a junior developer’s PR without reading it. Same principle here.

The specific failure modes to watch for are the usual suspects: SQL injection in dynamically-constructed queries, missing authentication checks on new API endpoints, secrets hardcoded into test fixtures, overly broad CORS configuration. These are not unique to AI-generated code — they are the same mistakes developers make under time pressure. The difference is that Claude Code works fast, so if you skip review entirely you will accumulate them fast too.

Two optional skills discussed in this series can support a review workflow. They are instructions you install, not built-in security guarantees:

• The requesting-code-review skill asks for a review against the plan and coding standards; inspect the resulting findings rather than assuming it catches every issue
• The verification-before-completion skill asks for test evidence before completion claims; independently check that the relevant commands actually ran and passed

Both of these are covered in detail in the 7 Claude Code Skills post.

Related: Secure AI Coding in Practice: A DevSecOps Checklist for 2026 — a practical checklist for teams integrating AI coding tools into security-conscious workflows.

The Honest Verdict

I run production code through Claude Code every day. My approach is not paranoid and it is not reckless: I am careful about what I put in context, I review what it produces, and I use review skills for anything that matters. That is not much overhead compared to what I get in return.

The framing I keep coming back to: the risks here are not fundamentally different from risks you already accept. You push code to GitHub — a third party holds your source. You run npm install — you trust packages written by strangers. You use a cloud CI system — your test environment runs on someone else’s infrastructure. Claude Code adds one more boundary to think about. You manage it the same way you manage the others: with deliberate hygiene, not anxiety.

For most developers working on most projects, the concerns are manageable with basic hygiene. Reviewed permissions and isolation, a code review habit, and an understanding of where prompts and tool results go. That is genuinely not much to ask for the productivity gain on the other side.

The risks are real. They are also the same category of risk you accepted when you started pushing code to GitHub, using a cloud CI system, or running npm install. Manageable with care, not a reason to opt out.

Once you have worked through those concerns and landed somewhere you are comfortable with, something shifts in how you work. That shift is what the next post is about.