After Claude Mythos: Where Defensive Security Actually Falls Short | Part 2
Honest Answers to the Questions Your Security Team Should Be Asking Right Now
Part 1 of this series covered what Claude Mythos Preview actually did — the specific vulnerabilities, the emergent capabilities, and the system card findings that matter for practitioners. If you have not read it, start there.
This is Part 2. It is not a list of things to worry about. It is an honest assessment of where most security programmes have genuine gaps right now, and what closing them actually requires. Part 3 covers the same ground for board members and the C-suite.
Where the Gaps Are
Legacy Code Is No Longer “Low Risk by Default”
Security teams have long operated an implicit triage logic: newer, internet-facing systems carry the highest risk; older, internal systems that “have never been breached” carry lower priority. The FreeBSD NFS and OpenBSD findings dismantle that logic directly. Both systems had not just been reviewed — they had been continuously, expertly reviewed for between 17 and 27 years. The vulnerabilities survived.
In our experience, the systems most organisations are least confident assessing are the ones with the longest operational histories: custom middleware written for a previous technology generation, bespoke integrations that sit between modern and legacy stacks, and internal APIs that were scoped out of the last five penetration tests because “they’re not customer-facing.” Those are the systems that now need re-examining, with fresh eyes and current methodology.
Your Penetration Test Scope Was Designed for a Different Threat
A standard penetration test has defined boundaries: agreed scope, agreed duration, agreed depth. Human testers work within those constraints and surface what they can reach in the time available. That model was calibrated for human-speed adversaries working within the limits of available tooling.
Mythos operates without those constraints. It runs continuously, reasons about code at a depth that most human testers cannot sustain across an engagement, and has demonstrated that it can find vulnerability classes that decades of expert human review missed. The practical gap is not that penetration testing is worthless — it is that the scope, frequency, and depth most organisations currently commission is not calibrated to the capability level of the threat they now face. That is a resourcing and programme design question, not a technical one.
Incident Response Is Built for Human-Paced Attacks
Most incident response programmes define success using metrics developed for human-operated attacks: mean time to detect, mean time to respond, dwell time. In November 2025, a state-sponsored AI campaign against 30 organisations executed 80–90% of its operation with human decision points at only 4 to 6 junctures. The attack compressed a multi-stage operation into a timeframe that conventional detection pipelines were not designed to intercept.
If your MTTD is measured in hours and your MTTR in days, those are not competitive metrics against an adversary operating at machine speed. Reviewing your incident response capability against AI-paced scenarios is not a theoretical exercise — the documented precedent now exists.
Social Engineering Has Changed and Most Awareness Programmes Have Not
Deepfake attacks on financial institutions increased 243% year-on-year. AI-generated content now accounts for over 80% of social engineering activity by volume. The training most employees received — look for typos, check the sender domain, be suspicious of urgency — was calibrated for a different threat. The tells that awareness programmes trained people to spot are no longer reliably present.
Updating social engineering defences is not a matter of adding a module to an annual training programme. It requires testing people against realistic AI-generated scenarios, establishing verification protocols for high-value requests that do not depend on voice or appearance recognition, and building organisational habits that hold under pressure.
Your AI Deployment Is Untested Attack Surface
If your organisation has deployed LLMs, copilots, AI-powered chatbots, or automated agents — and most have, whether formally sanctioned or not — each one represents attack surface that standard penetration testing methodology does not cover. The OWASP Top 10 for LLM Applications catalogues the key vulnerability classes: prompt injection, insecure output handling, training data poisoning, model denial of service, excessive agency. Most organisations have not assessed these surfaces systematically. Many do not yet have the internal capability to do so.
What Good Looks Like in Practice
- Map your AI attack surface before someone else does. Every AI system in your environment — sanctioned or shadow — needs to be in your asset inventory. You cannot assess what you have not found.
- Commission AI-aware penetration testing. If your current testing provider cannot demonstrate methodology for AI-enabled attack vectors and LLM application assessment, that is a gap worth addressing before your next engagement.
- Run a tabletop against an AI-speed adversary. Use the November 2025 campaign as a template. Ask honestly: at which point does your detection and response capability break down when the attack does not pause for weekends?
- Audit your legacy exposure. Identify systems that have not had a deep security review in the past five years. Prioritise network-exposed systems and anything with access to sensitive data. Age and internal positioning are no longer adequate risk mitigants.
- Start mapping to OWASP LLM Top 10 and MITRE ATLAS now. The NIST Cyber AI Profile is still in development; waiting for it to be finalised before acting is a choice with a cost.
- Apply Zero Trust principles to AI agents. Following Microsoft’s March 2026 reference architecture, AI agents should be treated as autonomous actors: verified identity, continuous behavioural monitoring, strict least-privilege access, hard network segmentation. Not trusted insiders.
At Corsaire, we are building AI-aware assessment methodology into our core service delivery — not as a separate AI product, but as a capability that applies across penetration testing, red team, and assurance engagements. If you want a direct conversation about where your programme stands, we would rather have that now than after an incident. Reach us at corsaire.com. Part 3 covers the same questions in terms that work for board members, risk committees, and the executives who commission security programmes.
ABOUT CORSAIRE
Corsaire is the specialist security testing and assurance division of A&O IT Group Plc, operating from the UK and UAE. We provide independent penetration testing, red team exercises, AI/LLM security assessments, and security consultancy services. Contact us at corsaire.com.
Disclaimer: The technical analysis in this article is based on publicly available information as of April 2026. Corsaire has not had direct access to Claude Mythos Preview. This article is for informational purposes and does not constitute security advice for any specific environment.
Addressing Security Gaps in the AI Age
Discover how Claude Mythos challenges traditional security assumptions. This blog highlights critical gaps in legacy systems, AI attack surfaces, and incident response, offering actionable steps for modern security teams.
+44 (0)1753 76 8800
