Fable 5 Is Available Again, So We Ran an OWASP Top 10 Assessment on PentaTrail's Code
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, it had been suspended under export controls, and in July 2026, the month it returned, we ran an OWASP Top 10 self-audit against PentaTrail's codebase.
This is the record: ten lenses split across six agents, then every finding settled against live data before it counted.
We split ten lenses across six agents that never saw each other's conclusions
The OWASP Top 10 groups the weaknesses most common in web apps into ten shapes, and we assigned those shapes agent by agent. Narrowing the lens and fixing each agent's role beats asking one agent to "look at everything": precision goes up and misses go down.
Figure 1: How the ten lenses were divided among six agents (full lens names are in Table 2 of the appendix)
Deep dive: the rules every agent was given
All six got the same rules: cite a real location (file and line) for every finding, never write from imagination, and never fix one instance of a pattern and stop — sweep them all. Because 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.
Instead of probing from outside, we handed over the current source with the latest fixes in it
Black-box probing only reaches the entry points you publish, whereas here the agents read the UI, the APIs, the database definitions and the scanners as source.
Figure 2: Probing from outside and reading the source reach different depths
Deep dive: six in parallel, collected as they finish
The six ran in the background at once and we collected results as each finished, then laid them over each other. Reading code alone, though, cannot tell you how a permission is set in production right now, or whether a key is still live. So at this stage every finding is still a hypothesis, and the next check is required.
An AI saying "this is dangerous" is a hypothesis until live data settles it
Counting self-reported "confirmed" at face value usually inflates the number. We look at the state as it is right now, not at the change history.
Figure 3: Findings are put against live data and split into kept and dropped
Deep dive: some findings really did drop out
What we went and looked at was the permission settings, the function bodies, and whether a key was genuinely revoked. Several findings that looked dangerous 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.
Critical and High came back at zero across all ten lenses
Twenty-one findings were confirmed: 5 Medium and 16 Low.
Figure 4: Severity split of the 21 confirmed findings (per-lens counts are in Table 1 of the appendix)
All 21 that remained were an extra layer on defenses already in place
None of them were fatal flaws anyone could exploit; they move defaults toward the stricter side. Misconfiguration (A05) drew the most at 6, and every finding was fixed the same day.
Figure 5: Every one of the 21 thickened a defense that was already standing
Deep dive: what the remaining findings were
Handling secrets under a stricter operational rule; moving header and permission defaults toward the tighter side; raising confidence in the provenance of ingested data and executables; masking records and not leaving extra information in production; pinning the server's outbound path more strictly; bringing a few dependencies up to newer versions. Access control (A01) and authentication (A07) came back at zero even after checks against the live database.
The same audit extends to the outside surface, where there is no source
Our own code is readable as source, while the attack surface others can see is not. What matters isn't that no holes appear; it's whether we can keep finding them by mechanism.
Figure 6: With source inside and no source outside, what the AI reads changes
- Posts on our development work (dev category)
- Superhuman AI Needs Source Code
- Discovery Alone Won't Protect You: Confirming "Can It Actually Be Exploited?" with AI Deep Scan
- See PentaTrail / CTEM
Running the same AI continuously over your company's outside attack surface is free to try for 14 days.
Appendix: results by lens, and the split across six agents
Table 1: findings per OWASP Top 10 lens
| 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 |
Table 2: the split across six agents, and what each one looked for
| Agent | Lenses | What it looked for |
|---|---|---|
| 1 | A01 Broken Access Control / A07 Auth Failures | Can you see someone else's data, or impersonate them? |
| 2 | A02 Cryptographic Failures / A08 Integrity Failures | Misplaced secrets, tampering, supply-chain trust |
| 3 | A03 Injection | Injection into SQL, the page, or a command |
| 4 | A04 Insecure Design / A09 Logging & Monitoring | Logic holes, states you can't notice or trace |
| 5 | A05 Security Misconfiguration / A06 Outdated Components | Loose headers or permissions, known flaws left in dependencies |
| 6 | A10 SSRF | Tricking the server into reaching inside |
The counts are the numbers confirmed against the codebase as it stood then. Lens order and names follow the 2021 edition of the OWASP Top 10.
Visualize your attack surface with PentaTrail CTEM/ASM
From discovery to vulnerability validation and remediation — all powered by the CTEM framework.
Get Started
