Reduce attack surface with Claude before you chase individual CVEs

Anthropic buckets projects by who can reach them: Public serves any user who can hit the service, Gated expects authentication before useful functionality, and Private serves the operator's own environment. That framing decides what "unnecessary" means. In their run, gated projects produced the most surprising early-reachability findings.

First pass, with a fresh context: look for code that is reachable in the shipped default configuration but is not used by any intended default functionality. For each finding Claude "designs and implements a gate and ensures that this causes no change in the program's default behavior" by running the project's own test suite plus a black-box regression suite against the baseline, and requiring identical results. Gates that would change a non-default configuration are set aside for a human.

Second pass, again with an empty context except a short note from the prior pass: look for security-sensitive or complex code that runs before authentication, without victim interaction, or before a protocol state-machine entry point, in any configuration. Anthropic's OpenSSH case study is the concrete example: ML-DSA-44 parsing was reachable by an unauthenticated client even when the algorithm was not enabled; the maintainers later moved the allow-list check before parsing.

Third pass: combinations of options that look reasonable alone but, together, silently turn a security control off, leave behaviour undefined, or leave a listener reachable after the admin thinks it is disabled. Anthropic found 162 such combinations across the 25 projects; in 94 of them a control was silently switched off. Claude proposes rejecting the combination at config load, or documenting and guarding it.

In every pass, Anthropic has Claude "create an inventory of the entry points from the code and confirms each finding with a dynamic trace of the program." A static guess is not enough. Keep only findings you can reproduce that way, then review the patch yourself.

Joel Parker Henderson applied the same tactic to Vix IDE with this prompt: "Goal: rework to reduce the attack surface. Process: move features into feature-flag Rust crates. Output: build a minimal version. Questions: Ask me anything." Claude (Fable/Opus/Sonnet) split the codebase into separate crates and Cargo features so a security-oriented user can pick capabilities, and so an auditor can look at one capability at a time. He points at the commit messages in the repo rather than pasting them here.