Claude Code: What It Actually Secures

This analysis exists because Anthropic accidentally leaked Claude Code's source.

Leaks like this are rare. Most of the time, people argue about AI coding tools from the outside: benchmarks, demos, company claims, vibe. Here, we can look at the actual product and ask a more useful question: what did Anthropic spend engineering effort on, and what does it still mostly leave to the model?

Claude Code GitHub commits over time

That matters because Claude Code is no longer just autocomplete. Anthropic says 70-90% of code at Anthropic is now written with Claude Code assistance, and one external estimate reported by OfficeChai, citing SemiAnalysis, says Claude Code now accounts for about 4% of public GitHub commits as of February 2, 2026.^{1 2}

At that point, “is Claude secure?” is too vague to be useful.

The better question is: what part of a developer’s security job is Claude actually taking over, and what part is it not?

After reading the leaked source, my view is pretty simple.

Claude Code has real protections around what the agent itself is allowed to do. It is much weaker at automatically judging whether the software it produces is secure.

That difference shows up again and again in the codebase.

What security means here

Once a system can read your repo, run shell commands, edit files, choose packages, and open PRs, “security” stops meaning one thing.

For Claude Code, I think there are three separate questions:

1. Can it use its access safely? Can it avoid dangerous shell commands, risky file edits, and other local actions that could damage the machine or repo?

2. Can it avoid leaking sensitive data while it works? Can it avoid sending secrets, tokens, configs, or internal material where they should not go?

3. Can it make sound security decisions about the software it writes? Can it catch broken auth, injection paths, unsafe dependencies, unsafe migrations, or data-isolation mistakes?

From the leaked source, Claude looks strongest on the first question, somewhat helpful on the second, and much less convincing on the third.

That is an important split. A coding agent can be fairly careful with your laptop and still make weak decisions about the code it ships.

Here is the practical scorecard:

Where the engineering effort clearly went

The strongest security work in the repo is around controlling what Claude itself is allowed to do.

That shows up in the permission system, which explicitly treats some checks as "bypass-immune" and still requires approval even if another hook already said allow. That is a meaningful design choice. It suggests Anthropic was not just relying on the model to behave well. In some places, it assumed dangerous actions should stay gated even if another layer says they are fine.

The same pattern appears elsewhere. There is real effort around shell hardening, sensitive path protection, and sandboxing. One comment in the Bash tool makes the mindset especially clear:

That is the clearest through-line in the leaked source. Anthropic put real engineering into reducing the blast radius of the agent itself.

That is also where Claude Code looks strongest.

Where the system starts relying more on the model

The repo looked much thinner once I shifted from “can the agent safely operate on my machine?” to “does the system reliably stop insecure software from being produced?”

I did not find a general, always-on subsystem that checks every Claude-generated patch for things like:

• SQL injection
• XSS
• SSRF in the application itself
• broken auth or authorization
• cross-customer data leaks
• risky dependencies
• unsafe migrations

To be fair, the code does show that Claude is instructed to write secure code. In constants/prompts.ts, the main prompt includes:

That is better than nothing. But it is still a prompt.

A prompt is not a verifier. It is not a patch gate. It is not a mandatory security check that runs on every generated change.

There is a security-review workflow in commands/security-review.ts. But it appears to be an explicit command you ask Claude to run, not a built-in property of every patch. The workflow builds a review prompt from git status, git diff --name-only, git log, and the full diff; tells Claude to focus on high-confidence security issues; then uses one subtask to identify vulnerabilities, parallel subtasks to filter false positives, and a confidence threshold of 8 before keeping a finding.³

That is useful. It is also very different from “every patch is automatically checked by a security-aware subsystem before it matters.”

I think that is the biggest thing the leaked repo makes visible.

Claude Code seems to have substantial engineering around controlling what the agent can do. It seems to rely much more on prompts and optional workflows when the problem becomes security judgment about the resulting software.

That is a meaningful difference, and it affects how much trust the tool deserves.

Claude does some useful secret protection, but I would not overread it

The repo does include some real protections around secret handling.

For example, services/teamMemorySync/secretScanner.ts contains a client-side secret scanner for team memory uploads. The comments explicitly say it scans before secrets leave the user's machine.

There are also safeguards around HTTP hooks. In utils/hooks/execHttpHook.ts, environment-variable interpolation is restricted to an allowlist, unexpected variables get replaced with an empty string, and header values are stripped of CR, LF, and NUL bytes. The same path enforces an allowed-URL policy before network I/O, and utils/hooks/ssrfGuard.ts blocks requests to private, link-local, and metadata-style addresses like 169.254.169.254, while still allowing loopback for local development.

So this is not an area Anthropic ignored.

I just do not think the leaked source supports a stronger conclusion than that. These look like thoughtful protections around specific features, not a general guarantee that Claude will keep secrets out of logs, patches, prompts, tests, or generated code.

That is useful. It is also still something I would treat as backup, not as a replacement for secret scanning, review, and normal engineering discipline.

The recent incidents fit this picture pretty well

The recent incidents make more sense when you look at Claude Code through this lens.

The LiteLLM and Axios supply-chain attacks are reminders that fast development does not solve dependency trust. Claude can absolutely help you add dependencies faster. It does not replace maintainer trust, version pinning, provenance checks, or supply-chain response.^{4 5}

The Claude Code leak is a different but related reminder. Anthropic described the issue as a “release packaging issue caused by human error,” and later reporting said there was a manual deploy step that should have been better automated.^{6 7}

That does not contradict the security work in the repo. It actually fits it.

A tool can be careful about local agent behavior and still fail in a completely ordinary software-delivery way.

That is probably the broader point here: operational safety while coding is not the same thing as proving the whole system is safe to ship.

The real security boundary

The leaked source points to a fairly clear boundary.

Anthropic has put real engineering into controlling what Claude Code is allowed to do: permission gates, shell hardening, sensitive path protections, sandboxing, SSRF controls, and some scoped secret-handling safeguards. That work is concrete, and it shows up directly in the code.

But that is not the same as building a system that reliably decides whether the software Claude produces is secure.

That second problem looks much less implemented. In the places where I expected to find always-on security judgment for generated code, I usually found prompts, optional workflows, or narrower feature-level protections instead. There is useful security guidance in the system prompt. There is an explicit security review command. But that is different from having built-in machinery that continuously verifies auth logic, dependency trust, tenant isolation, migration safety, or other application-level security properties before a change matters.

I think that is the most useful way to read the repo.

Anthropic seems to have treated Claude Code first as an agent that needs its own blast radius controlled. That makes sense. It is the most immediate risk when you give a model access to a terminal, a filesystem, and a codebase.

What the leaked source does not support is the stronger interpretation people often slide into: that because Claude can write code and has some security instructions, it is therefore taking over security judgment in any robust way.

It is not.

For security teams, that is the important line to keep in mind. Claude Code may help generate code, review code, and even spot some classes of mistakes. But the leaked source does not suggest that Anthropic has solved the harder problem of turning secure software judgment into a default property of the system.

That job still sits with the human reviewer, the security team, and the surrounding engineering process.

So the practical takeaway is not that Claude Code is insecure. It is that its strongest protections are around how the agent operates, not around everything it produces.

That is a useful capability. It is also a narrower one than many people seem to assume.