Fable 5 Is Available Again, So We Ran an OWASP Top 10 Assessment on PentaTrail's Code

PentaTrail Dev Team, Pentacon Research, Inc.··8 min read
Contents

Fable 5, Anthropic's top-tier model that reads source code to find vulnerabilities, is back.

As we wrote in Superhuman AI Needs Source Code, this Fable 5 / Mythos had been suspended under export controls. Now we can use it again.

So we ran an OWASP Top 10 self-audit against PentaTrail's codebase. This post is the actual record.

Method

We split the ten OWASP Top 10 lenses across six agents, ran them in parallel, and had them flag findings by Critical / High / Medium / Low. Asking one agent to "look at everything" is weaker than narrowing the lens and fixing each agent's role. Precision goes up and misses go down.

  • Static review: not black-box probing from the outside, but reading the latest source code directly (UI, APIs, database definitions, scanners), with the recent fixes already in.
  • Parallel, background execution: the six ran at once, and we collected results as each one finished and cross-checked them.
  • Severity classification: each finding was sorted into Critical / High / Medium / Low.

Every agent got the same rules: cite a real location (file and line) for each finding, don't write from imagination, and don't fix one instance of a pattern and stop; sweep them all. The six don't see each other's conclusions. They read the same code from independent angles. Adding and layering perspectives holds up against quiet misses better than making one inspector smarter.

How we split the ten lenses

The OWASP Top 10 groups the weaknesses most common in web apps into ten shapes.

  • Agent 1: Access Control (A01) + Authentication (A07): can you see someone else's data, or impersonate them?
  • Agent 2: Cryptography (A02) + Integrity (A08): misplaced secrets, tampering, supply-chain trust.
  • Agent 3: Injection (A03): into SQL, the page, or a command.
  • Agent 4: Insecure Design (A04) + Logging & Monitoring (A09): logic holes, states you can't notice or trace.
  • Agent 5: Misconfiguration (A05) + Outdated Components (A06): loose headers or permissions, known flaws left in dependencies.
  • Agent 6: SSRF (A10): tricking the server into reaching inside.

Don't stop at "found it": verify against real data

When an AI says "this is dangerous," that's only a hypothesis. Count self-reported "confirmed" at face value and it usually inflates.

What matters is looking at the state as it is right now, not the change history (the diffs): the permission settings, the function bodies, whether a key is really revoked. We settle these by fact, not by guess. Several findings that looked dangerous this time fell away once we queried the live database and found them already properly closed, or already revoked. Skip this step and the holes you thought you'd sealed stay open.

The result: Critical / High / Medium / Low

OWASP Top 10 Critical High Medium Low What it was (blurred)
A01 Broken Access Control 0 0 0 0 Tenant boundaries and permissions. No crossing even under live DB checks, zero findings
A02 Cryptographic Failures 0 0 0 2 Tightening how secrets are handled, operationally
A03 Injection 0 0 0 1 Wrapping the spots that handle external input one layer thicker, just in case
A04 Insecure Design 0 0 0 3 Resistance to unexpected use, and failing to the safe side
A05 Security Misconfiguration 0 0 2 4 Nudging header and permission defaults toward the stricter side
A06 Vulnerable/Outdated Components 0 0 1 1 Bringing a few dependencies up to newer versions
A07 Auth Failures 0 0 0 0 Passkey-centric auth is sound, zero findings
A08 Integrity Failures 0 0 1 1 Raising the confidence in the provenance of ingested data and executables
A09 Logging & Monitoring 0 0 0 2 Masking records and not leaving extra info in production
A10 SSRF 0 0 1 2 Enforcing that the server's outbound path is strictly pinned
Total 0 0 5 16

Critical and High were zero in every lens. What remained were 5 Medium and 16 Low, all of them additions that make the layered defense one notch thicker, not fatal flaws anyone could exploit. We fixed every finding the same day.

Not that no holes appear, but that we keep finding them

It's been getting a lot of attention, and the depth and substance of the findings bore that performance out. What matters isn't that no holes appear. It's whether we can keep finding them by mechanism. So we're going to build a way to run this audit on a regular schedule.

Other posts on our development work are collected in the dev category.

With the same AI, we continuously check not just our own code but the parts of your company's attack surface that are visible from outside. We turned that into a product: PentaTrail.

See PentaTrail / CTEM

Visualize your attack surface with PentaTrail CTEM/ASM

From discovery to vulnerability validation and remediation — all powered by the CTEM framework.

Get Started

See pricing/Compare and choose