DEV Community

Cover image for We Audited Our Own Server with Claude Mythos 5.1
Saurat Xiuhcoatl
Saurat Xiuhcoatl

Posted on Originally published at transgenia.org

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 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.

Case summary: Transgenia, an organization verified by Anthropic, ran a defensive audit of its own infrastructure with Claude Mythos 5.1; it found 2 high, 7 medium and 4 low severity findings, applied one fix, and the safety classifier stopped two responses; the result is what can be done, told in public.
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.

Anthropic's Cyber Verification Program has a Defense Access tier for systems an organization owns or maintains; Transgenia was approved on 7 November 2026 and so uses Claude Mythos 5.1, under safeguards set per model and per category; penetration testing and red teaming are another tier of the program, which Transgenia does not have.
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.

The scope of the test: yes to our own infrastructure and to identification only; no to third-party systems, no to intrusive testing or exploitation, and no to changes without human approval.
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.

Six read-only steps: inventory of what runs, firewall, web server and container configuration, versions checked against public vulnerability databases, review of our own code, exposure checked from external nodes, and a report with evidence and no secrets.
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.

On the production server we reviewed the PHP applications, the Python services, the containers and the network with its firewall; everything ended in findings classified by severity.
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.

13 findings in total: 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.

Five patterns worth looking for on any server: services published outside the firewall, debug modes left on in production, dependencies without security updates, secrets readable by local users, and firewall rules nobody remembers.
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.

From a finding with evidence to a proposed fix; if a person approves it, there is a backup, a minimal change, verification from inside and outside, and a record with its rollback; if not, it stays in the plan.
8. No change without approval, backup and verification.

Timeline of 9 November 2026 in UTC: at 00:04 the read-only audit starts; at 00:30 the report and plan are ready; a person approves two fixes; at 00:34 one is applied and verified; then the classifier stops the response and the second fix is never applied.
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.

The fix that was applied: a debug mode visible to the public; the configuration was backed up, switched to production mode and verified so that the public page no longer shows it; updating the application is still pending.
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.

A request goes through the safety classifier: if allowed, the full response arrives; if declined, the response stops, the rest is withheld and pending actions do not run.
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.

Read-only identification led to a report with a plan; moving on to fix production triggered the first stop; widening the review to accounts, access keys and backups triggered the second.
12. Where the model stopped.

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.

What we did: inventory and read configuration, check versions against public databases, review our own code, propose a prioritized plan and fix with approval. What is not done: attack third-party systems, exploit vulnerabilities, extract or show credentials, push back after a classifier refusal, change production without human approval and publish open findings.
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.

Two tools failed: an external probe run by a web agent could not tell a block from a proxy failure and was replaced by a connection test from external nodes; the dependency audit failed on the frozen environments and was replaced by a direct query to a public database; so every finding has reproducible evidence.
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:

  1. Written authorization and a defined scope. Which systems, who authorizes and what is left out.
  2. Read-only first. Identify before touching.
  3. Secrets redacted. No password or key in the evidence, not even in internal documents.
  4. Human approval for every change. The model proposes; a person decides.
  5. Backup and rollback before touching production. Every change with its way back.
  6. Respect classifier refusals. Do not rephrase to get around them.
  7. Responsible disclosure. Publish the method and the counts, never the details of what is still open.

Seven safeguards in order: written authorization and a defined scope, read-only first, secrets redacted in all evidence, human approval for every change, backup and rollback before touching production, respecting classifier refusals, and responsible disclosure without publishing 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.

Transgenia's cybersecurity service follows the same sequence: authorized assessment, guided remediation, hardening and verification, until there is evidence to decide.
16. The same sequence, as a service.

Sources

  1. Claude Mythos 5.1 (Claude Platform documentation, Anthropic, read on 10 November 2026).
  2. Refusals and fallback (Claude Platform documentation, Anthropic, read on 10 November 2026).
  3. Cyber Verification Program (Claude Help Center, Anthropic, read on 10 November 2026).
  4. Packagist security advisories API (Packagist, queried on 9 November 2026).
  5. OSV, open vulnerability database (queried on 9 November 2026).
  6. Anthropic's notice to Transgenia approving Defense Access in the Cyber Verification Program (7 November 2026): not public.
  7. 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: contacto@transgenia.org, WhatsApp +52 55 8034 0405, 15-minute call or the contact page.

Keep reading

Hashtags: #ClaudeMythos #Cybersecurity #AISecurity #DefensiveAI #Anthropic #CyberVerificationProgram #ProjectGlasswing #ResponsibleAI

Top comments (0)