What this is
I use Claude Mythos 5.1, Anthropic's gated security model, to attack software the way a skilled adversary would: it plans the strategy, I run it against your system in a sandbox, and every attempt is logged as evidence. Then I fix what breaks. My workspace has Defense Access under Anthropic's Cyber Verification Program, so this is defensive, authorised testing only: your system, your written permission, a copy or test environment.
Most "AI security scans" give you a long list of guesses. This gives you attacks that were actually tried, the ones that worked, the evidence, and the fix.
Real project: red-teaming a continuous authentication system
A security startup built a system that keeps checking, from phone motion sensors, that the person using a session is still its owner, and blocks protected actions when it is not. I built the test harness and ran the adversarial campaign against it.
- Two environments, identical except the protection. The protected build and an unprotected control, both measured, so the comparison means something.
- 48-hour adaptive campaign. Model-planned attack strategies, millions of generated signal variations, real protected-action attempts, all with exact counts and hash-chained evidence.
- Result. Fabricated sensor signals, a different person taking the phone, protocol attacks and enrolment poisoning: zero breaches. The only attacks that passed needed the owner's own captured signal (replay), a limit we had flagged in advance, reported separately and honestly rather than hidden in a single percentage.
- Live demo on real cloud actions. A $1 Stripe test payment, deleting a Cloud Run service and signing a release with Cloud KMS: blocked 15 of 15 times with governance on, executed 25 times with it off, each with a Stripe payment ID or KMS signature as proof.
- Mythos 5.1 as the attack planner. The first campaign used Claude Opus 4.8, because Mythos was not yet available to us. It is now: Mythos 5.1 plans the next round of strategies, for example feature-preserving perturbations aimed at the continuity check, recorded with request IDs as proof of the model used.
Client not named; numbers shown are from the delivered evidence. Related: Continuous authentication from phone sensors.
12 things I can do for you with Mythos 5.1
Web app and API security audit
Problem: you shipped fast and do not know what an attacker could do.
What you get: broken access control, IDOR, injection, auth and session flaws, exposed secrets, each confirmed with a working proof, plus the fix as a pull request and a retest.
Pre-launch check for AI-built apps
Problem: apps written with Cursor, Lovable or Bolt often ship with open database rules, keys in the frontend and missing auth checks.
What you get: a launch-blocker list in plain English and the fixes, in days.
LLM app and AI agent red-teaming
Problem: your chatbot or agent can be talked into leaking data, calling the wrong tool or spending money.
What you get: prompt injection, tool abuse, data exfiltration and jailbreak tests, with guardrails and evals added so it stays fixed.
Adversarial testing of auth, biometrics and fraud checks
Problem: you claim your system stops impostors, but have no evidence.
What you get: the campaign above for your product: protected versus control, exact counts, an evidence report you can show investors or customers.
Payments and business-logic abuse
Problem: Stripe webhooks, coupons, refunds and payouts are where real money leaks.
What you get: replayed and forged webhooks, race conditions on credits and refunds, price tampering, each tested and closed.
Mobile app security review
Problem: React Native, iOS and Android apps leak keys and trust the client too much.
What you get: bundle and storage review, API calls the app makes and what the server accepts without it, certificate and token handling.
Cloud configuration review (AWS, GCP)
Problem: one public bucket or over-wide IAM role undoes everything else.
What you get: IAM, storage, network and secrets review with least-privilege fixes applied as code.
Dependency and supply-chain audit
Problem: vulnerable packages and unpinned builds.
What you get: which known issues are actually reachable in your code, upgrades done and tested, and a build that pins what it installs.
Security review on every pull request
Problem: one audit is a snapshot; new code brings new holes.
What you get: a CI step that reviews each pull request for security issues and comments with the fix, tuned to keep false alarms low.
Threat model and security documents
Problem: an enterprise customer or investor asks for your security posture.
What you get: a threat model, data-flow diagram and a findings-and-fixes report written for non-engineers, useful as input to SOC 2 or ISO work.
Incident triage and log analysis
Problem: something odd happened and you need to know what, fast.
What you get: logs and code read together to reconstruct what happened, what was exposed, and the patch.
Secure-by-design build
Problem: you are about to build something sensitive: payments, health data, AI agents with real permissions.
What you get: I build it with the attacks above run against it before launch, not after.
How a project runs
- Scope call: which app, repo or system, and what "breached" means for you.
- Written permission and a test environment: a staging copy, or I build one from your repo.
- Campaign: Mythos 5.1 plans the attacks, I run and verify them. You see the log as it happens.
- Report and fixes: confirmed findings by severity, evidence for each, fixes as pull requests, then a retest.
Packages
| Audit | Audit + fix | Adversarial campaign | |
|---|---|---|---|
| Scope | One app or API | One app or API | Your auth, fraud or AI system, protected vs control |
| You get | Verified findings report | Report, fixes as pull requests, retest | 48-hour campaign, evidence report, fixes |
| Time | 3 to 5 days | 1 to 2 weeks | about 2 weeks |
| From | $400 | $1,200 | $2,500 |