Back in July, our AppSec lead walked into a platform sync with a proposal: use Anthropic's Claude Mythos to do a pass over every repo we own, looking for the kind of vulnerabilities that static analysis tools tend to miss - business logic flaws, auth checks that only cover the happy path, that one internal service that trusts anything coming from inside the VPC. Six weeks later we had results, a longer list of open questions than I expected, and a policy document that didn't exist before this started.
I want to write about the process rather than just the outcome, because I think the outcome is less interesting than the tradeoffs we had to work through to get there.
Why we looked at this at all
Our existing tooling - SAST, dependency scanning, a couple of commercial DAST products - is fine at what it's built for. Known CVE classes, common injection patterns, dependency graphs with a known-bad version somewhere in them. What it has never been good at is the stuff that requires actually understanding what a service is supposed to do and noticing when the code doesn't quite do that. A permissions check that's correct for the primary code path but silently skipped on an error-handling branch. A reconciliation job that trusts a timestamp from an upstream system it shouldn't trust. Things a careful human reviewer catches on a good day, and misses on a Friday afternoon.
The pitch for using a large model here isn't that it's smarter than a human reviewer. It's that it doesn't get tired, doesn't have Friday afternoons, and can hold an entire service's control flow in view at once in a way that's hard for a person skimming a diff to do.
What we actually did
We didn't point Claude Mythos at our production repos directly. That was the first and least controversial decision: everything ran against a scrubbed mirror, with secrets, connection strings, and any hardcoded internal hostnames stripped or replaced with placeholders before anything left our network boundary. Our compliance team was involved from day one, not looped in after the fact, which is a lesson we learned the hard way on an unrelated project a couple of years back.
The workflow itself was fairly plain. For each service, we fed in the repo, the relevant IaC, and a description of what the service does and what data it touches, and asked for a structured writeup of anything that looked like a genuine authorization, data-handling, or trust-boundary issue - not style nits, not linter-adjacent stuff we already catch elsewhere. Every finding got triaged by a human before it went anywhere near a ticket queue.
What it actually found
Across around 40 internal services, it surfaced eleven findings we considered worth fixing. Two were things I'd call genuinely good catches - one was a service that validated a JWT's signature correctly but never checked the audience claim, which meant a token minted for a completely different internal service would have been accepted. That's exactly the kind of thing that's invisible in a diff and only shows up if you're reasoning about the whole auth flow at once. The rest were more mundane: a couple of overly permissive IAM policies, a logging path that was writing a field it shouldn't have been, that sort of thing.
It also produced nine findings our team closed as not real issues after review - a couple of them were reasonable-sounding but wrong about how a downstream system actually behaved, which it had no way to know since that behavior wasn't in the code it was looking at.
Net positive, in our assessment. But the false-positive rate is exactly why every one of these went through a human before becoming a ticket, and I want to be honest that "eleven real findings, nine false ones" is a ratio you only get comfortable with once you've built the review step into the process, not before.
The concerns that came up, and where we landed
I don't think it's honest to write this post as an unqualified endorsement, so here's what actually gave us pause.
Scope of access. Even with scrubbing, feeding a coding assistant broad visibility into how your systems are structured is a bigger grant of trust than most of the tools we already run, most of which look at one file or one dependency graph at a time with no broader context. We limited this to a mirrored, non-production copy of the code precisely because we weren't comfortable extending that visibility to anything live.
Vendor and availability risk. Anthropic suspended access to the Mythos-tier models for a few weeks in June, shortly after they launched, to comply with export control requirements, before access was restored on July 1st. Nothing about that affected the security of our data, but it was a useful reminder that if a review process comes to depend on a specific vendor's model being available, you need a fallback for the weeks it isn't. We kept our existing scanners as the primary line, not the model.
Review fatigue. Eleven real findings and nine false ones across six weeks is a manageable review load. I'd be more cautious about scaling this up without also scaling the reviewer capacity, because the moment triage becomes a rubber stamp is the moment this stops being useful and starts being a compliance checkbox with a false sense of coverage behind it.
What it can't tell you. It has no visibility into runtime behavior, no knowledge of production incident history unless you explicitly give it that context, and it will confidently reason about downstream systems it has never actually seen operate. Every finding needs someone who knows the real system to sanity-check it against reality.
Where we landed
We kept it, scoped narrowly: quarterly passes over externally-facing services and anything touching client data, always against a scrubbed mirror, always reviewed by a human before anything becomes a ticket, and it supplements our existing scanners rather than replacing any of them. That's a fairly conservative use of the tool relative to what it's probably capable of, and that's deliberate. In a regulated environment, "probably capable of more" is not the same as "cleared for more," and the gap between those two things is where the real work of adopting a tool like this actually lives.
If you're a security team considering something similar, my honest advice is that the finding quality is genuinely useful, but the value is entirely contingent on the review process you build around it. Skip that part and you've just added a fast way to generate tickets nobody trusts.
