We Audited Our Own Server with Claude Mythos 5.1
Originally published on Transgenia. This is the syndicated version on dev.to. On 7 November 2026, Anthropic approved Transgenia for Defense Access in its Cyber Verification Program. Two days later we asked Claude Mythos
Originally published on Transgenia. This is the syndicated version on dev.to.
On 7 November 2026, Anthropic approved Transgenia for Defense Access in its Cyber Verification Program. Two days later we asked Claude Mythos 5.1, the Anthropic model offered only to verified organizations, to review our own production server. In 26 minutes we had a report with 13 findings and a fix plan. Later, at two moments, a safety classifier stopped its responses. This is the full story: what we did, what we found, where the model stopped and what it can actually do.
Short answer. Claude Mythos 5.1 is useful for a company's defensive cybersecurity: inventorying what runs on a server, reviewing configuration, checking versions against public vulnerability databases and proposing a plan, always on systems you own and with authorization. Transgenia, an organization verified by Anthropic with Defense Access since 7 November 2026, used it as a proof of concept on its own production server: it found 2 high severity findings, 7 medium and 4 low, and applied one fix with human approval. Its safety classifiers stopped two responses. What you cannot do with this model is wider than what you can, and it pays to know that before you start.

1. The whole case, from access to lessons learned.
What is Claude Mythos 5.1 and who can use it?
According to Anthropic's documentation, Claude Mythos 5.1 is the same model as Claude Fable 5.1, available only to organizations verified through Anthropic's verification programs, such as the Cyber Verification Program. It was released on 1 September 2026 and works with a context window of one million tokens. Transgenia is one of those verified organizations.
The safeguards are not optional. Anthropic documents that its models include safety classifiers that can decline a request, and that the cybersecurity category covers anything that could enable harm, such as malware or exploit development. The same documentation warns that benign cybersecurity work can also trigger it. Anthropic sets those safeguards per model and per category, and its verification program requires every test to be authorized in advance by someone with authority over the systems.
What does it mean that Transgenia is a verified organization?
On 7 November 2026, Anthropic notified Transgenia of its approval for Defense Access in the Cyber Verification Program, effective immediately. According to that notice, Defense Access is for teams that defend systems they own or maintain: vulnerability triage and verification, malware analysis and reverse engineering, detection engineering and incident response. Authorized penetration testing and red teaming belong to another tier of the program, which we do not have today.
It is worth saying what it does not mean. It is not a certification or an endorsement of our services by Anthropic. It is a verification that lets us use its most capable models, under its safeguards, for defense. This audit was our first proof of concept with that access.

2. Transgenia, a verified organization: what its access covers.
What did we set out to do, and what did we leave out?
The question was specific: does any native application on our production server, PHP and Python in particular, have a significant vulnerability? The scope was written down before we started. Our own infrastructure only, identification only, and no change without a person's approval. Intrusive testing, brute force, exploitation and any data download were left out.

3. What was in scope and what was left out.
How did we work?
Identify before touching. The model worked in Claude Code with read access to the server and followed six steps. To check versions it used two public sources: Packagist security advisories for PHP dependencies and the OSV database for Python ones. The evidence was stored without passwords or process arguments. Where a configuration file held secrets, we recorded that they existed, not their value.

4. Identify before touching: six read-only steps.
The review covered the PHP applications, the Python services, the containers and the network layer with its firewall. Each finding was classified by severity and kept with the evidence behind it.

5. What we reviewed on the production server.
What did we find?
Thirteen findings: 2 of high severity, 7 of medium severity and 4 of low severity.

6. Thirteen findings, by severity.
We do not publish the details of findings that are still open. Describing an unfixed weakness precisely hands it to whoever is looking for it. We can share the patterns worth looking for on any server, because variants of them showed up on ours.

7. Five patterns worth looking for on any server.
A useful report also says what not to touch. The model recorded what was done well: our own website form code, the hardened PHP configuration, key-only SSH access and the rules that deny access to sensitive files.
How did we move from detection to fixing?
With a simple rule: no change without approval, backup and verification. A person on the team reviewed the report and approved two fixes.

8. No change without approval, backup and verification.

9. Timeline of 9 November 2026 (UTC).
The fix that was applied switched off a debug mode that showed internal information to any visitor of an application. The configuration was backed up, switched to production mode and verified from outside so that the public page no longer showed it. This reduces exposure, but it does not close the finding: the application needs an update, which remains in the plan. The second approved fix was never applied.

10. The fix reduces exposure; it does not close the finding.
Why did the model stop?
Twice, a safety classifier stopped the model's response. Claude Code reported it without ambiguity: the response was stopped by a safety classifier, not by an error; the rest was withheld and pending commands did not run. Anthropic's documentation describes the same thing: a refusal can arrive mid-response, and whatever was already generated is treated as incomplete.

11. What happens when the classifier declines.
We do not know the classifier's exact criteria and we will not speculate about them. What we did observe is when it happened. The first time, when moving from identification to fixing production. The second, when widening the review to accounts, access keys and backups.
How we responded matters as much as what happened. We did not rephrase the request to get around the refusal, and we did not try to reproduce what was withheld. We treated it as a sign that this part of the work needs another path: a person on the team doing it with their usual tools, or waiting until the scope and the access program allow it.
What can be done, and what cannot?
With this model, the list of what should not be done is longer than the list of what can. We think that is right. A tool that can find weaknesses in minutes has to work within limits that do not depend on the good faith of whoever uses it.

13. The list of what is not done is longer, and that is fine.
Does the verifier need verifying?
Yes. Two tools in the session itself failed, and the model wrote it down in its report. An external probe run by a web agent could not tell a real block from an outbound proxy failure, so it was discarded and replaced by a connection test from external nodes. The automated dependency audit failed on the frozen environments, and it was replaced by a direct query to a public vulnerability database. As a result, every finding has evidence anyone on the team can reproduce.

14. The verifier needs verifying too.
Which safeguards do we recommend?
If your company is going to use frontier AI to review its security, these are the seven rules we follow and recommend:
- Written authorization and a defined scope. Which systems, who authorizes and what is left out.
- Read-only first. Identify before touching.
- Secrets redacted. No password or key in the evidence, not even in internal documents.
- Human approval for every change. The model proposes; a person decides.
- Backup and rollback before touching production. Every change with its way back.
- Respect classifier refusals. Do not rephrase to get around them.
- Responsible disclosure. Publish the method and the counts, never the details of what is still open.

15. Seven safeguards before using frontier AI for security.
Where Transgenia stands
Claude Mythos is neither the AI that breaks everything nor a toy. It is a powerful instrument that works under rules, and the rules are part of its value: a model that stops when the work gets close to risky ground is more trustworthy than one that never stops. This was our first proof of concept with Defense Access, and we appreciate the trust that the verification implies. We will keep using it within its scope: defending what we own or maintain. If we ever widen that scope, it will be within the tiers, approvals and oversight that Anthropic sets, and we will say so as clearly as this article does. It is not our only tool: we also have approved access to OpenAI Daybreak Blue for authorized internal cybersecurity work.
What does it mean for your company?
What we learned at home is what we apply in our cybersecurity service: authorized assessment, guided remediation, hardening and verification, with scope, permissions and deliverables in writing. As a verified organization with Defense Access, we can use Anthropic's most capable models to defend systems we own or maintain. If Transgenia maintains your company's systems, that work happens within that scope, with your written authorization and the same method: identify before touching, fix with approval and deliver evidence to decide. Penetration testing is not part of that tier.

16. The same sequence, as a service.
Sources
- Claude Mythos 5.1 (Claude Platform documentation, Anthropic, read on 10 November 2026).
- Refusals and fallback (Claude Platform documentation, Anthropic, read on 10 November 2026).
- Cyber Verification Program (Claude Help Center, Anthropic, read on 10 November 2026).
- Packagist security advisories API (Packagist, queried on 9 November 2026).
- OSV, open vulnerability database (queried on 9 November 2026).
- Anthropic's notice to Transgenia approving Defense Access in the Cyber Verification Program (7 November 2026): not public.
- Internal audit record (9 November 2026): not public; figures are quoted as written.
Frequently asked questions
What is Claude Mythos 5.1?
It is an Anthropic model, the same as Claude Fable 5.1, available only to organizations verified through Anthropic's verification programs, such as the Cyber Verification Program. It was released on 1 September 2026.
Is Transgenia an organization verified by Anthropic?
Yes. On 7 November 2026, Anthropic approved Transgenia for Defense Access in its Cyber Verification Program, which is for defending systems it owns or maintains. It is not a certification or an endorsement of its services.
Can any company use Claude Mythos?
No. Access has to be requested through the Anthropic program that covers the use case, and Anthropic decides on verification. Every test must be authorized in advance by someone with authority over the systems.
Why did the model stop two responses?
Because its safety classifiers declined them. Anthropic documents that benign cybersecurity work can also trigger them. We do not know the exact criteria; we respected the refusal and took another path.
Did you run a penetration test?
No. It was an identification-only audit of our own infrastructure, with no intrusive testing, no brute force, no exploitation and no data download.
Can you audit my company with Claude Mythos?
If Transgenia maintains your systems, we can use it to defend them, within Defense Access and with your written authorization. Penetration testing requires another tier of the program, which we do not have today. Our service includes authorized assessment, guided remediation, hardening and verification.
Do you publish the vulnerabilities you found?
We do not publish the details of findings that are still open. We share the method, the counts by severity and the patterns worth looking for on any server.
Next step
If a system worries you today, let's start with 15 minutes. We work out what you want to protect, who can authorize the review and what evidence you need to decide. Book 15 minutes or see our cybersecurity service.
About the author and Transgenia
EfraΓn CarreΓ³n Ortiz is Director General (Chief Executive Officer) of Centrum Transgenia, a Mexican technology boutique. He holds the official Claude Code badge (Claude Partner Badge) issued by Anthropic, verifiable on Credly.
Transgenia is an OpenAI Select Partner within the OpenAI Partner Network and a registered partner in Anthropic's Claude Partner Network. It is also an organization verified in Anthropic's Cyber Verification Program, with Defense Access. Team: VΓctor Estrada Bello, Chief PMO; Danild Johan Zambrana LΓ³pez, Chief Technology Officer; Jaime Lozano CastaΓ±eda, Chief Marketing Officer; EfraΓn CarreΓ³n Ortiz, Director General (Chief Executive Officer).
Let's talk: [email protected], WhatsApp +52 55 8034 0405, 15-minute call or the contact page.
Keep reading
- Cybersecurity for companies in Mexico: the service that applies this method.
- Cleaning malware is not closing the breach: another security case, on a compromised WordPress site.
- MCP infrastructure inventory: the first time we audited our own systems with Claude.
- Does your site say the same about your company on each page?: there, too, we audited ourselves first.
- meet.transgenia.org: how we stopped paying for Read AI: a service of our own, hardened before opening it.
- From 5 hours to 13 seconds: guardrails and respect when working with an autonomous agent.
- AI quotations in Odoo with human approval: the same rule, a person approves before acting.
- How we govern a team of twelve AI agents: the governance behind this work.
Hashtags: #ClaudeMythos #Cybersecurity #AISecurity #DefensiveAI #Anthropic #CyberVerificationProgram #ProjectGlasswing #ResponsibleAI
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.
