One founder. One laptop. Structural crypto recognition at enterprise scale, on a thumb drive — in thirty seconds

Find the crypto your developers didn't label.

Event Horizon · Structural Recognition for C/C++ Cryptographic Code

Forked libraries. Renamed implementations. Helper files nobody marked as crypto. Event Horizon reads the structure underneath the labels — without filenames, import chains, metadata, or AI inference.

Deterministic. No AI in the loop. No cloud.
Same input gives same output, every time, forever. Hand-written software running on your infrastructure. That's the difference between a measurement instrument and an exploration tool.
How C-DNA recognition works

Cryptographic code has a C-DNA, independent of what it's called.

Beneath the variable names and comments, every cryptographic implementation carries an intrinsic structural identity. We call it the C-DNA — the signature that recurs across implementations of the same algorithm whether the file is called aes_round.c, transform_block_v2.c, or utils.c. Event Horizon reads the C-DNA directly. The labels are cosmetic; the C-DNA is the actual identity.

Your C/C++ source code
Any size. On your infrastructure. No upload.
Event Horizon
Structural recognition · seconds to minutes · on-prem · deterministic · no AI in the loop
CBOM tooling
SandboxAQ, IBM Quantum Safe Explorer, Keyfactor, PQCA CBOMkit — CycloneDX output, procurement-ready inventory
AI vulnerability scanner
Mythos, Daybreak, MDASH, CodeMender — pointed at only the crypto files Event Horizon identifies
Audit & review
Human cryptographers — prioritised by the four-bucket triage
PQC migration programme
NCCoE / NIST roadmap — the foundational inventory step

Traditional inventory tools rely on labels, metadata, and import chains. Event Horizon derives inventory structurally — from the shape of the code itself. That's the distinction that makes every downstream layer accurate.

How you run it

From locked box to galaxy map in three steps.

Scan pipeline

No cloud account. No dependencies to vet. No source code uploaded anywhere. Event Horizon installs and runs entirely on your infrastructure — or on a USB stick we post you.

1 · Install or plug in

A single signed installer for your machine, or a pre-provisioned USB stick posted to you. No cloud account, no Python to install, no third-party libraries to vet. One self-contained tool.

2 · Activate with your key

One activation code, bound to your machine. The scanner runs only where you're licensed — a lost or stolen USB stick is inert on any other hardware. Yours, not theirs, made literal.

3 · Point it at a folder

A window opens in your browser — running entirely on your machine, nothing leaves it. Pick a folder, press Scan. Moments later you have your four-bucket map, an action queue telling you which files to read first, and a tamper-evident evidence bundle ready for your auditor.

Every scan produces a tamper-evident evidence bundle — machine-readable JSON, a SARIF feed for your security dashboard, a CycloneDX cryptographic bill-of-materials for procurement and EU CRA submission, and a hash-sealed manifest recording that the scan ran on your machine, under your licence, with every artefact hashed so any later change is detectable. (Cryptographic signing of the manifest ships in a future update.) Hand it to a regulator as-is.

The situation you're in

You have crypto your developers didn't label as crypto.

Forked libraries where the upstream lineage is lost. Hand-rolled implementations nobody documented. Vendor variants where the labels were stripped at some point. Crypto-adjacent code that carries the structural signature of cryptography but lives in a file called utils.c.

Your keyword scanner can't see any of it — there's nothing to grep for. Your AI scanner can find bugs in it, eventually — but only if it knows which files to scope first. That's the gap.

You probably have a spreadsheet somewhere with vendor names and algorithm labels. What you almost certainly don't have — file by file, with auditable evidence — is which specific files structurally implement which algorithm. Which constant-time variant was actually shipped. Which vendor upgrade silently changed an implementation. Which file labelled "ML-KEM" is actually doing what you think it's doing.

That gap has been uncomfortable for years. As of April 2026, it became dangerous.
What changed since April

AI just demonstrated that crypto bugs survive human review for twenty-seven years.

Disclosure timeline

Four data points from the last five months. Each one is verifiable and public. Read them in order.

01 — APRIL 2026

Anthropic released Mythos.

An AI model that autonomously found 17-year-old bugs in FreeBSD NFS. 27-year-old bugs in OpenBSD TCP. 16-year-old bugs in FFmpeg H.264. Code we'd all been deploying for decades, audited countless times, trusted by an entire industry. AI found bugs in it in weeks. By May 2026, Anthropic was briefing the global financial-system watchdog about the systemic risk.

02 — MAY–JUNE 2026

The disclosure curve went vertical.

Palo Alto scanned their own code with frontier AI and found 75 bugs across 26 CVEs in a single engagement: 15× their normal find-rate. Their CTO went on stage and named the window publicly. Then June set the record: ~1,546 high- and critical-severity CVEs disclosed in one month, 3.5× the highest monthly total ever recorded before Mythos. That clock is real.

03 — 28 JULY 2026

AI broke a post-quantum algorithm before it shipped.

Anthropic pointed Mythos at cryptographic mathematics itself. It found a hidden lattice symmetry in HAWK, a post-quantum signature candidate, halving its effective key strength — and the designers withdrew the algorithm from standardisation. It also delivered a 200–800× speed-up against reduced-round AES. Cost: roughly sixty hours and $100K of compute. The AI-exploit clock and the PQC clock are now the same clock.

04 — JULY–AUGUST 2026

The crypto libraries themselves went on the list.

wolfSSL ships in five billion devices. It took CVE-2026-5194 (CVSS 9.3): missing digest checks in ECDSA signature verification, forged certificates accepted as genuine. libgcrypt took a memory-safety bug in its post-quantum ML-DSA implementation. OpenSSL, NSS and Botan joined Anthropic's public disclosure dashboard: 2,300 vulnerabilities across 392 open-source projects as of 26 August. 177 CVEs, 285 GitHub advisories, and counting.

Four tools did this: Anthropic's Mythos, OpenAI's Daybreak, Microsoft's MDASH, Google's CodeMender. Mythos runs through the Glasswing programme, and since June's 18-day export suspension it is restored only to approved US organisations. All four are hosted, all four are probabilistic, and none produces an evidence artefact. Your source goes into someone else's pipeline, you pay frontier-AI compute per scan, and what comes back is a confidence score. Not a deterministic, reproducible artefact you can hand a regulator and re-run yourself.

You can't defend what you can't structurally identify. The question stopped being "is our crypto broken?" It became "do we even know what crypto we have?"

The other clock

Most banks have a PQC plan. Almost none have the means.

Two clocks

The AI-exploit window is the short clock. Behind it is a longer one — and this one has regulator force behind it.

NIST published FIPS 203 / 204 / 205 in August 2024 — the first three post-quantum cryptographic standards. NSA's CNSA 2.0 timeline targets 2030 for begin-shift on national-security systems and 2035 for full phase-out of classical algorithms. DORA went live in the EU on 17 January 2025. FCA SYSC 15A and ENISA point the same direction: regulated entities must document and manage their cryptographic inventory. That was the direction of travel in 2025. In 2026, it acquired dates.

Since then, the expectation has hardened into dated mandates. UK: NCSC's migration roadmap requires cryptographic discovery and inventory complete by 2028, with high-priority migration done by 2031. That 2028 baseline is what sector regulators will assess NIS-designated operators against. EU: the NIS Cooperation Group's Coordinated Implementation Roadmap has member states beginning cryptographic inventories by the end of 2026, in CBOM format. US: Executive Order 14412 (22 June 2026) is the first federal directive to name the Cryptographic Bill of Materials as a defined artefact. CISA and NIST are to publish its minimum elements by March 2027, with federal high-value systems on post-quantum key establishment by 2030.

The deliverable this instrument produces now has a name in regulation — and the nearest deadline is measured in months, not years.

This isn't a "we might want to" timeline. It's board-level, regulator-mandated, multi-year. Banks, telcos, defence contractors, critical-infrastructure operators — all under the same migration programme.

Most have plans. Almost none have the means.

The bottleneck is inventory. Almost every organisation that starts a PQC migration discovers 3–5× more cryptographic assets than they planned for. A large payments institution typically faces 120,000+ discrete migration tasks. NCCoE — NIST's applied cryptography programme — names inventory as the foundational first step of any PQC migration programme.

PQC migrations all start with the same prerequisite: an accurate inventory of the crypto already in your code. The reason organisations discover 3–5× more than they planned for is that keyword-based inventory tools miss the forks, the hand-rolls, and the mislabelled implementations. Traditional inventory systems rely on labels, metadata, import lineage, or declared dependencies. Event Horizon derives inventory structurally — from the shape of the code itself. That distinction is what makes downstream CBOM output (SandboxAQ AQtive Guard, IBM Quantum Safe Explorer, Keyfactor, CryptoNext COMPASS, PQCA CBOMkit, others) actually accurate.

Whichever AI scanner you run

Whichever AI scanner you run, scope it rationally.

Anthropic's Mythos and OpenAI's Daybreak are both production — though Mythos is currently restored only to approved US organisations after June's 18-day export suspension, with UK and EU access still gated; Microsoft's MDASH (announced at Build 2026) is bundling into Defender and GitHub; Google's CodeMender is in limited release. Whichever you choose, the same arithmetic applies: scanning 18,000 files at $25–$125 per million tokens is not how the economics work. Anthropic's own published cryptanalysis result puts numbers on it: roughly $100K of compute for sixty hours of Mythos work against a single algorithm. Even partners with large token pools don't run these across whole estates. And the one that needs no choosing — MDASH, switched on inside your Microsoft estate — still does triage, not the auditable evidence a regulator needs, with your source running through someone else's pipeline.

The scope decision — which files actually warrant a frontier-AI scan — is not a budget question. It's a recognition question: which 1–3% of your codebase is structurally crypto, by shape, regardless of label.

Event Horizon answers that question in seconds to minutes, deterministically, on-prem, for £0 in compute cost. Then whichever AI scanner you pick has a tractable scope to work against. And no third party deciding whether you're allowed to know.

When attackers can weaponise commodity AI, the differentiator isn't a flashier scanner — it's the unglamorous fundamentals: knowing exactly what's in your estate. That's the consensus across NCSC, NIST and the Cloud Security Alliance. Event Horizon is the deterministic instrument for the most fundamental fact of all — where your cryptography actually is.
Your options before the window closes

You have a problem. The problem isn't waiting for you to make a plan.

Let's say you read this and decide to think about it later. What are your actual options before AI-driven exploits become operational baseline? Five paths. Walk through them honestly.

1

Wait it out.

Hope the window doesn't close. Hope AI-driven exploits stall on the way to production. Hope nobody at your shop reads the next CVE drop and asks why you don't have an inventory ready. Good luck.

2

Hire your way out.

Spin up an internal crypto-audit team. Hire senior cryptographers in a market where every bank, every defence contractor, and every telco is doing the same thing — this quarter. Pay £150K-£300K per engagement to consultants who deliver a static snapshot that's stale the morning after they close the laptop. You'll find the money. Somewhere. So will the next person.

3

Audit harder with the team you have.

Tell your existing security team to read 18,000 files. Tell them what to look for. Except… you don't know what they should be looking for. Not at file-level. Not specifically. Not in time. Nobody does. Not your team, not your vendors, not the auditor you'll bring in to verify their work.

4

Wait for an AI scanner you can run.

Access is widening — slowly, and unevenly: Mythos is restored to approved US organisations only, Daybreak has a public form, MDASH ships inside the Microsoft estate. If you are a UK or EU operator, the gate is literal. But access was never the real issue. Every one of them is hosted and probabilistic: your source goes into someone else's pipeline, and what comes back is a confidence score, not a reproducible artefact your auditor can re-run. They do triage. They don't produce the evidence deliverable. That gap doesn't close when the gate opens.

5

Predict the timeline and plan around it.

Look at the window. Decide what's likely. Build a measured response strategy. Wait for it to clear committee. Watch a calendar.

Except this isn't a problem you plan around. It's not waiting for your strategy to land. It's not negotiating with your board's timetable.

It's coming.

None of these paths are wrong. They're slow, expensive, blind, or unavailable. The path that's none of those things takes seconds to minutes and starts with one form.

The category we created

We discovered a different primitive the AI scanners themselves need.

Who you're talking to

A research arc applied to a new urgency.

Event Horizon isn't a security startup. It's a UK research arc applied to a new urgency. The methodology that underpins the scanner was developed long before AI vulnerability discovery existed as a category — at the intersection of cognitive linguistics, structure and meaning, and perceptual realism. The cryptographic application is the first commercial deployment. The PQC migration mandate made it the first.

The product you'd buy from a Silicon Valley startup is built by people who learned cryptography in college. Event Horizon is built by someone who learned cryptography after thirty years of learning how meaning, structure, and form interact across language, music, and visual art.

That's not just trivia. That's why it works.

You're talking to the founder directly. There's no sales-development team filtering you out. No account executive quoting from a script. No tier of support between you and the person who built the tool. That's the same advantage every early-stage British specialist business has offered customers since long before "founder-led" became a buzzword. It's why Rob's consulting clients — the UK Royal Air Force, QinetiQ, Rolls-Royce, Virgin, Harris Communications, Nuffield Health, Fortune 500 organisations — engaged him in the first place.

What that means for you in practice: when you sign up to the waitlist, Rob personally reads it and replies — typically within 48 hours, always within 48. Not an SDR. Not an automated sequence. Him.

The scanner runs on your infrastructure. The IP is held personally as inventor, not by a corporate entity. The engagement carries continuity clauses for acquisition or change-of-control scenarios. Continuity is in the architecture, not in the headcount.

What Event Horizon does

Point it at a folder. Thirty seconds later, you have a galaxy map.

Crypto galaxy map
Each point a file. The lit constellation: the cryptography — found by shape, not by name.

The output is an evidence-grade cryptographic inventory. Auditable, reproducible, exportable. The artefact a PQC migration depends on, a FIPS validation requires, a regulator asks for, and your downstream tooling — bug-finders, SAST, AI scanners — needs in order to scope. Inventory first. Everything else is downstream of the inventory.

No upload to the cloud. No AI model in the loop. No multi-week configuration. A standalone scanner, deterministic by design, that reads your C/C++ source structurally and tells you which files in your codebase are coherent crypto galaxies — and which family each one belongs to. Same input, same output, every time, forever.

1

Source

You point Event Horizon at a folder of C/C++ files. No network required.

2

C-DNA read

Each file's C-DNA — its Crypto-DNA structural signature — is read beneath variable names and comments. The C-DNA is what matters; the surface text is cosmetic.

3

Seven detectors fire

Independent structural detectors check every file. Multiple detectors can fire on a single file — that's the fingerprint.

4

Reference compare

Each fingerprint is matched against a labelled reference corpus. Distance-to-cluster determines classification.

5

Report

JSON, Markdown, and HTML dashboard, plus CycloneDX CBOM output for procurement pipelines. Drift comparison between scans is included — event-horizon drift earlier.json later.json reports what changed structurally over time.

The report doesn't tell you "there's a bug here." It tells you which files are crypto, which family each one matches, and which ones deserve human attention first. Your security team — or any frontier AI scanner (Mythos, Daybreak, MDASH) you point next — does the bug-hunting inside the files we've identified.

Six months of inventory work, done in seconds. Millions of lines of code, finally measurable.

What you actually get back

Four buckets. Every file in your codebase lands in one of them.

Four-bucket triage

When the scan finishes, you don't get a wall of CVE-style noise. You get a structured triage. Each file lands in exactly one bucket, ranked by how much human attention it deserves.

Unknown pattern

Do this now.

Crypto-shaped — but doesn't match any known galaxy in our reference catalogue. Could be a novel implementation, a buggy variant, or something worth a closer look. Top of the queue.

Boundary

Worth a glance.

The right family — but the fingerprint diverges from documented references. Often a deliberate optimisation. Sometimes something more interesting. Second-stage review.

Consistent

Already cleared.

Matches a known reference cleanly. Structurally consistent with the algorithm family it claims to be. No structural anomalies to chase — your standard family-specific review applies.

Mute

Empty space.

No detector fired. Not crypto-shaped. The 80-90% of any codebase that's parsers, networking, UI, file I/O — out of scope for crypto-conformance review.

~1%
Unknown (do this now)
~2%
Boundary (worth a glance)
~7%
Consistent (already cleared)
~90%
Mute (empty space)

On a typical 18,000-file enterprise codebase, you go from "review 18,000 files" to "focus on these 180 files." Fast.

What we recognise

Famous bugs all had a C-DNA. So do the unknowns in your code.

Family radar

Every published vulnerability class has a structural signature — a C-DNA — that recurs across implementations. We operate a catalogue of these. Three famous examples below; the full catalogue is part of the Sprint engagement.

Heartbleed
CVE-2014-0160
Buffer-overflow class in TLS-handshake processing. Affected OpenSSL and every major TLS implementation that adopted the affected code path.
Catalogue entry: R2-HEAP-OVF-PARSER
FreeBSD NFS
CVE-2026-4747
State-machine memory-safety class. Sat undiscovered for 17 years before AI-disclosed in 2026. The class signature had been recurring since 2009.
Catalogue entry: R2-UAF-STATE
wolfSSL ECDSA
CVE-2026-5194
Certificate-verification bypass class. Missing digest-size and OID checks in ECDSA signature verification — forged certificates accepted as genuine. CVSS 9.3, five billion devices. AI-disclosed August 2026, in a codebase we had already measured.
Catalogue entry: R2-CRYPTO-DIGEST-LEN-GATE

If a famous class of bug has a C-DNA we've catalogued, every undisclosed bug in that same class shares the same C-DNA. We tell you which files in your codebase carry it — before someone else does.

What we deliberately don't claim

What Event Horizon is — and is not.

Event Horizon is an evidence-grade cryptographic inventory instrument. It is not a bug-finder, not a certification, not a replacement for the tools you already run. The honesty rails below name what it does not do — so when we tell you what it does, you know to believe us.

Not a bug-finder

We produce the inventory of cryptographic primitives in your codebase, classified by family, with auditable evidence. The AI scanners (Mythos, Daybreak, MDASH), SAST tools, and your security team find bugs inside the files the inventory identifies. We measure the galaxy. They find what's wrong inside it.

Not a certification

CONSISTENT means "structurally matches a known reference" — not "bug-free", "side-channel-safe", or "approved by your regulator". Our output is a measurement, not a verdict.

Not a replacement

We don't replace code review, SAST tools (Coverity, CodeQL, Semgrep), fuzz testing, or formal verification. We sit upstream — telling each of those tools which files are worth their time.

What we've validated on real codebases

Seven public codebases. Five on Mythos’s public disclosure list. Reproducible bit-for-bit.

Deterministic versus probabilistic
"We have a 3-5 month window to outpace the adversary before AI-driven exploits become the new norm."
— Lee Klarich, CTO, Palo Alto Networks (May 2026)

We didn't build an instrument and hope. We measured seven public C/C++ codebases — five of them now on Anthropic's public disclosure list: wolfSSL, OpenSSL, NSS, FreeBSD and FFmpeg — and documented the results. Same input gives same output every time. Methodology paper available on request.

The AI scanners hunt black holes. Event Horizon maps where they form.

Yours, not theirs.

wolfSSL · wolfcrypt/src
237 files in 31s. 1 Unknown Pattern (post-quantum lattice file flagged as priority-one review). 2 Boundary. 23 Consistent. 213 Mute.
NSS · lib/freebl (Firefox crypto)
235 files. 6 Consistent (including Firefox's Kyber implementation). 229 Mute. Clean structural classification across the board.
OpenSSL · crypto/
201 files. 10 Consistent across AES, SHA, EC, ML-KEM, ML-DSA. Cross-algorithm structural pattern surfaced.
curl · lib/vtls
31 files. 0 fires. Correct discrimination — curl's TLS dispatch is composition code, not crypto bodies. Verified silent.
FFmpeg · libavutil/crypto
15 files. 3 Consistent (MD5, SHA, SHA-512). Honest gap on AES surfaced and addressed in next fork iteration.
FFmpeg · libavcodec/h264
49 files. 1 Boundary (intra-prediction with crypto-adjacent structure). 48 Mute. H.264 codec correctly classified non-crypto.
FreeBSD · sys/fs/nfs
19 files. 0 fires. Where Mythos found a 17-year-old RCE — we correctly stay silent because NFS isn't crypto. Different question, different layer.
Retrospective — August 2026, CVE-2026-5194. When wolfSSL took a CVSS 9.3 certificate-forgery CVE — an incomplete digest-size gate in ECDSA signature verification — we ran the instrument against both releases. On the vulnerable 5.9.0, Singularity's R2-CRYPTO-DIGEST-LEN-GATE class declines to clear ecc.c: digest boundary present, cryptographic handoff present, complete gate absent — flagged for human eyes on precisely the axis the CVE broke on. On the patched 5.9.1, the same class clears. Deterministic both ways, and the drift report catches the fix. A triage fact, not a bug-find — but it is exactly the triage this page promises.

What the triage actually surfaced

Five findings from the seven scans worth singling out — not bugs (we don't find bugs), but structural anomalies a human reviewer should look at.

  1. wolfSSL — one Unknown post-quantum lattice file. Crypto-shaped, but didn't match Kyber, Dilithium, Falcon, or NTRU reference templates. Novel implementation, buggy variant, or deliberate divergence — any answer is interesting. Priority-one review.
  2. wolfSSL — two Boundary fingerprints. Right family, divergent fingerprint. Usually a constant-time variant or hardware-specific optimisation. Occasionally something more interesting. Worth a second-stage glance.
  3. OpenSSL — cross-algorithm structural pattern. A structural feature recurring across AES, SHA, elliptic-curve, and ML-KEM / ML-DSA primitives. Not visible from symbol tables. Documented optimisation or accidental coupling — your maintenance team should know which.
  4. FFmpeg libavcodec/h264 — crypto-adjacent structure in non-crypto code. One H.264 intra-prediction file fired our detectors. Not a bug, not crypto. But the fact a video-codec routine fires crypto detectors at all is a signal worth understanding.
  5. FFmpeg libavutil/crypto — our own detector gap, named. We identified MD5, SHA, and SHA-512. We did not fire on the AES implementation in the same directory. We documented the gap and addressed it in the next fork iteration. The kind of "what we missed" entry that belongs in any honest measurement instrument.

Why this matters for your codebase. If publicly-audited libraries like wolfSSL and OpenSSL — decades old, scrutinised by thousands of eyes — surface this much structurally-interesting material, your private codebase (typically less-audited, often with bespoke implementations and forked dependencies) is plausibly carrying its own structural surprises. The question isn't whether structural surprises exist in your inventory. It's whether you have a defensible record of looking.

These are real numbers, on real codebases, on a real laptop. Not curated demos. Not edited highlights. Every result is reproducible by anyone who has the public code and the scanner.

One engine. Three applications.

We don't just map the edge. We map the whole thing.

Platform anatomy

Event Horizon is the product you run today. It's also the first of three applications of one structural-recognition engine — named, in order, for the anatomy of the thing they describe. From the boundary, to the shell where nothing escapes, to the core.

Event Horizon · Shipping

The boundary — where crypto reveals itself. Structural recognition of the cryptographic code in your estate, by its C-DNA rather than its labels. Four-bucket triage, tamper-evident evidence bundle, on your machine. This is the one you can run this week.

Photon Sphere · Shipping

The trapping shell — where nothing escapes. The mechanism that seals our software in umbra: each copy bound to its authorised machine, its licence, and the exact build you were issued. A lost or copied build is inert on any other hardware. It's why Event Horizon can be handed to you on a thumb drive and stay yours, not theirs.

Singularity · Preview

The core — where the fault-lines concentrate. Structural triage of crypto files against a catalogue of known vulnerability-class signatures, cross-checked against the codebases Anthropic's Mythos has publicly hit. Calibrated and in preview today; full held-out validation underway. The layer that comes after the inventory.

Two shipping, one in preview — all three the same engine, reading the structure underneath the labels. Event Horizon is where you start. It is not where this ends.

The economics, plainly

The same crypto-inventory question, priced four ways.

All the numbers below are public. Consulting rates, Mythos's published per-token pricing, standard regulator-audit project costs. Nothing is invented.

Approach Who delivers it Time Cost Available to
Manual crypto audit Big Four / boutique security consultancies 4-8 weeks £150K - £300K Anyone with budget
PQC migration discovery sub-project Specialist consultancy or vendor-led Quarters £500K+ as a line item Banks running PQC programmes
Mythos comprehensive scan Anthropic (Glasswing programme) 2+ weeks setup + scan est. £100K–£1M+ in token cost Glasswing programme (approved US organisations)
Daybreak comprehensive scan OpenAI (Trusted Access for Cyber tier) 1-2 weeks setup + scan $25–$125 per million tokens (per-scan equivalent: £80K–£500K+) Public web form + cyber-trust vetting
Event Horizon Sprint Event Horizon — us 7 days Free for founding cohort. Sprints thereafter from low five figures. Extended Engagements scoped to scale. Anyone

The first three rows are alternatives to not knowing your crypto inventory. Event Horizon is the prerequisite that makes the first three rationally scopable.

A Sprint fee that surfaces even one previously-unknown crypto file pays for itself many times over against the alternative cost of finding it manually. The decision isn't ambiguous. The hard part is making the time to have the 30-minute conversation that starts it.

The Sprint programme

Three founding slots. Then Extended Engagements.

Event Horizon runs as a 7-day Evaluation Sprint — bounded scope, founder-led, fixed deliverables. The first three engagements form the founding cohort — free, in exchange for a reference statement at the end. Once those are filled, the entry door becomes an Extended Engagement: deeper scope, longer cadence, scoped to your repository size and integration needs.

Founding Sprint — 3 slots

  • 7-day Sprint, founder-led throughout
  • Free of charge
  • Reference statement at end ("X ran Event Horizon during the founding cohort phase")
  • First-year discount on the production licence if you continue
  • Selection priority: defence, aerospace, embedded systems, regulated infrastructure
  • One free re-scan at 6 months as a thank-you

Extended Engagement — scoped

  • Deeper than a Sprint: CI/CD wiring, multi-repo coverage, longitudinal baseline
  • Founder-led, 10–14 days
  • Scoped to repository size and integration needs
  • Includes detector calibration against your specific codebase
  • Natural step before committing to annual production licensing
  • Available once the founding cohort is closed

Once the founding cohort closes, Sprint engagements start at low five figures, scoped against repository size and integration scope. Annual production licensing detail is in the FAQ below.

The Sprint cadence

  • Day 1 — 30-minute onboarding call. Scope agreed.
  • Day 2 — initial scan runs against your agreed code subset.
  • Day 3–4 — joint review session: Unknowns, Boundaries, detector behaviour, false-positive triage, candidate priority files.
  • Day 5 — evidence pack delivered: file inventory, drift baseline, prioritised shortlist, walkthrough recording.
  • Optional Week 2 — calibration, second pass, or expanded scope.
The walk-away clause. You can end the Sprint at any time with 48 hours' notice. That clause IS the answer to "this commits us to too much." It commits to nothing you can't get out of. The deal is asymmetric in your favour.

One form. One personal reply. One thirty-minute conversation.

You don't need to commit. You don't need to upload code. You don't need to sign an NDA today. The waitlist form takes 90 seconds. Rob personally replies — usually within 48 hours, always within 48. If Event Horizon doesn't fit your situation, he'll tell you that. If it does, we'll book a 30-minute discovery call.

Get a Sprint slot →

Don't fancy the form? Direct line: rob@[domain] — confirm with Rob before publish

The questions people ask before they sign up

Frequently asked — and honestly answered.

We already use Coverity / CodeQL / Semgrep / a bug-finding vendor. Why do we need you too? Why not just have them find the crypto bugs?

Existing tools find bugs. Event Horizon produces the cryptographic inventory those tools — and your auditors, your regulators, and your PQC migration programme — depend on having first.

Honest answer: you don't need us if you already know which files in your codebase are crypto and which family each one structurally matches. Almost no one does.

Your bug-finder is only useful when it's pointed at the right code. SAST tools (Coverity, CodeQL, Semgrep) find bugs and known-bad patterns. AI scanners (Mythos, Daybreak, MDASH) find vulnerabilities through model inference. Both are powerful when pointed at the right files. The problem: most codebases are 80-90% non-crypto — parsers, networking, UI, data structures. Running crypto-specific rulesets across all 18,000 files wastes scan budget on the 17,800 that aren't crypto. Either you scan everything (expensive and noisy) or you guess from filenames and import statements (unreliable). Event Horizon tells your existing tools which 200 files actually deserve crypto-specific attention.

The arithmetic is concrete. A comprehensive Mythos scan can run an estimated £100K–£1M+ in token cost at published per-token rates. Running it against 18,000 files versus 200 is meaningful money. Serious operators do the inventory step first. The downstream spend then becomes rational. Without the inventory, the downstream spend isn't a budget question — it's an arithmetic impossibility at estate scale.

The audit question isn't "did you find bugs." It's "do you know your crypto inventory." Your bug-finder produces a list of vulnerabilities it recognised. Your regulator wants a structured list of every cryptographic file in your codebase, classified by family, with auditable evidence. Different artefact, different question. Event Horizon produces the inventory; your bug-finder produces the bug list. You need both — but the inventory comes first, because it changes how the bug-finding is scoped, priced, and reviewed.

If your existing vendor tells you they "also produce a crypto inventory" — ask them how, and ask whether the output is audit-grade. If the answer involves filenames, import statements, or keyword matching, they're reading the nameplate, not opening the door. A file labelled aes.c might contain AES, or a buggy variant, or nothing crypto-shaped at all. A helper file might contain crypto without saying so. We read the building behind the name. Different question, different layer.

How do you validate this — and why don't you claim to find vulnerabilities?

Honest answer, because it's the question that separates serious instruments from confident guesses: validating vulnerability detection is one of the hardest unsolved problems in security. Clean, labelled ground truth barely exists — a vulnerability is only "confirmed" once someone has found, proven, and disclosed it, and "confirmed clean" is nearly impossible to establish (you can never prove a file has no flaws, only that none are known yet). This is why nobody — not the static-analysis vendors, not the frontier AI labs — can hand you a real false-positive rate for exploit-finding on production code. They report what they found, not what they missed.

So Event Horizon doesn't make the claim that can't be validated. It doesn't tell you a file is vulnerable, or safe — those are verdicts about an unknowable future. It deterministically recognises where your cryptography is, by structure, and which family it matches — a claim you can confirm by inspection. A cryptographer can open the file and check we were right. That is a fundamentally more honest, more verifiable claim than "this is exploitable," and it's the claim your downstream tools and auditors actually need first.

Think of it this way: a wall looks solid until you change resolution — at the atomic scale it's mostly gaps. Code is the same. Everything looks safe until it isn't. We don't pretend to certify safety at a resolution no instrument can reach. We give you a precise, reproducible map of the structure at the resolution we can read — and we scope the expensive downstream tools to the files that matter.

We'd rather tell you exactly what we measure — and hold our preview vulnerability-triage layer to a validation bar the field hasn't cleared yet — than sell you a number we can't defend. In a market full of unvalidated confidence, that's the difference.

What outputs does Event Horizon produce? Can it feed our existing CBOM pipeline?

One scan, five output formats — designed to slot into whatever toolchain you already run.

  • JSON — machine-readable, the canonical artefact for downstream automation
  • Markdown — human-readable summary report for security teams and reviewers
  • HTML dashboard — offline-readable, single-page customer report with per-file drilldown
  • SARIF — static-analysis-results format for CI/CD integration (GitHub, GitLab, Azure DevOps)
  • CycloneDX CBOMevent-horizon scan --cbom cyclonedx out.cbom.json. Conforms to the latest CycloneDX spec including the cryptographic-asset component type. Feeds your existing CBOM pipeline (SandboxAQ AQtive Guard, PQCA CBOMkit, Sectigo, Keyfactor) with structurally-derived inventory entries rather than label-based ones. The crypto your CBOM tool currently misses — the forks, the hand-rolls, the helper-file crypto — lands in the artefact correctly.

The procurement question: "Does your tool emit CycloneDX?" — yes, with cryptographic-asset components, catalogue-version metadata, and reproducibility provenance. Procurement-checklist compliant.

The strategic distinction: we don't replace your CBOM tool. We feed it accurately. Traditional CBOM systems rely on labels, metadata, import lineage, and declared dependencies; Event Horizon derives inventory structurally — from the shape of the code itself. The downstream CBOM tool renders procurement-ready output; we make that output reflect what's actually in your codebase, not what the labels claim.

Drift comparison between scans: event-horizon drift earlier.json later.json. Useful for quarter-on-quarter change reporting under DORA, FCA SYSC 15A, or NCSC audit cycles.

How fast is it actually, at scale? And how does that compare to AI scanners?

This is V1 — a first-round production system on Python, on a laptop. Hardly Ferrari speed. Compiled production builds and enterprise hardware will move things materially.

Scan time is deterministic and scales with codebase size — seconds to minutes for typical estates. Measured on a laptop (this V1 Python build, parallelisation enabled): small codebases of around a thousand files complete in well under a minute; larger estates scale from there into the minutes. We are benchmarking the largest tiers and publish measured numbers, never projections.

What matters more than the raw seconds is what those minutes replace:

  • Manual crypto audit of a million files: months of consultancy work, £500K–£2M, snapshot in time, not reproducible
  • Mythos comprehensive scan: £500K–£1M+ in token cost, two weeks of setup, gated to approved US organisations, probabilistic findings
  • Hand-rolled keyword scanner: quick to write, structurally blind to forked, renamed, vendor-modified, or hand-rolled crypto — misses exactly what we catch

Deterministic, on-prem, and £0 in token cost — against an AI scanner's two-week setup and five-to-seven-figure spend. We measure what we ship; we don't promise the optimisation roadmap as today's number.

How do you handle our proprietary code?

The scanner runs on your infrastructure. Your source code never leaves your environment. We don't have a cloud upload, an API endpoint, or any external dependency that touches your code at scan time.

Deployable formats: a Python package you pip install in a controlled environment, or a standalone executable you put on the machine of your choice. Air-gapped deployment is supported.

Is this AI? Should we be worried about the AI safety / black-box issue?

As we say up top: no AI in the loop, no neural networks, no model weights, no cloud API calls.

This is intentional. Audit-supporting measurement requires determinism that AI cannot provide. If you re-run an AI scanner twice, you can get different results. If you re-run Event Horizon twice, you get identical output. That's the difference between a measurement instrument and an exploration tool.

Is this just an AI-generated business? Did you prompt your way to a startup?

Fair question to ask in 2026. There's a category of polished-website-thin-product startups that didn't exist two years ago. Here's how Event Horizon is structurally different:

The methodology predates AI vulnerability discovery as a category. The research arc — cognitive linguistics, structure and meaning, perceptual realism — runs from the 1990s. UK and US patent provisionals were filed 27 August 2025 with documented priority date, independent of any model run. Academic collaborations are public and verifiable: Dr. John Grinder (linguist, UCLA) and Professor Allan Snyder (Sydney University, Centre for the Mind). Prior consulting clients (RAF, QinetiQ, Rolls-Royce, Virgin, Nuffield Health, Fortune 500) are referenceable on request.

The scanner itself is hand-written deterministic Python — no LLM weights, no cloud inference, no model API calls. AI tools assisted with some of the marketing copy on this website. The methodology, the patents, the scanner code, and the 30-year research lineage existed first.

The instrument itself is deterministic, hand-written, and reproducible — every output it produces is verifiable bit-for-bit by anyone with the public code. If you want to verify before engaging: ask for the provisional filing receipts and the academic-collaboration history. Both available on a 30-minute discovery call.

What if Event Horizon misses something?

We document what we miss as deliberately as what we identify. Our methodology paper publishes true-positive and false-positive rates for every detector on a labelled corpus, with bootstrap confidence intervals.

If your codebase has a crypto family we don't currently detect, the relevant files will land in MUTE. That's not a security verdict — it's the scanner saying "we didn't see crypto shape with the detectors we currently have." future releases expand coverage to additional families; new ones get calibrated against your codebase during the Sprint if relevant.

Why can't we just build this ourselves?

Legitimate path. Here's the honest comparison so you can decide:

The methodology is the moat, not the code. Structural-conformance scanning for cryptographic code requires combining cognitive linguistics, signal-processing-style structural analysis, and crypto-family taxonomy. It's a cross-disciplinary insight that took 30 years to develop and 18 months to reduce to a working scanner. Internal R&D for a comparable capability is realistically 12–24 months across several engineers, with no certainty of arriving at a usable result.

Patent protection makes a clean-room reimplementation difficult. UK and US provisionals (priority 27 August 2025) cover the core structural-recognition method.

And the build/buy math: a 7-day Sprint with us, versus an 18-month internal programme. By the time you ship something internal, the window Palo Alto's CTO named has closed, and you're explaining to your auditors why you didn't have an accurate structural identification of your crypto code ready when AI-driven exploits became operational baseline.

If you have the in-house capability to build this and the timeline to wait, you don't need us. Most teams have neither.

Won't our existing security vendor add this as a feature?

Probably not, for two reasons.

First, they're in a different category. SAST tools (Coverity, CodeQL, Semgrep) find bugs and known-bad patterns in code. AI scanners (Mythos, Daybreak, MDASH) find vulnerabilities through model inference. Event Horizon is upstream of both — it tells you which files structurally match known crypto families so you can point those tools at the right subset. Adding structural-conformance scanning isn't a feature increment; it's a different product.

Second, the patent protection (UK and US provisionals filed 27 August 2025) makes a direct reimplementation difficult. Vendors that want to add this will need to design around the IP, build a meaningfully different methodology, or licence from us.

What's more likely: your existing vendors will add their own AI bug-finders. Those will compete with Mythos, Daybreak and MDASH for bug-finding. They won't substitute for crypto-inventory triage. Different layer.

Are you a real business or a one-person side project? Why one person?

Event Horizon is a one-person UK business based in Sandhurst, Berkshire. That's not a disclaimer — it's a feature, and one with an expiry date.

During the Sprint phase, the person you talk to is the person who developed the methodology, filed the patents, and wrote the scanner. No sales-development team between you and the founder. No account executive quoting from a script. No support tier hiding the engineers. Direct expertise, fast iteration, and the same advantage every specialist British consultancy offers customers — one of the reasons Rob's prior clients (RAF, QinetiQ, Rolls-Royce, Virgin, Nuffield Health, Fortune 500) chose to work with him in the first place.

New categories almost always start with one head. The cross-disciplinary synthesis underpinning Event Horizon (cognitive linguistics + perceptual realism + crypto family taxonomy) is the kind of insight that happens in one place and gets scaled by a team afterwards. Teams scale the application of an insight; they rarely produce the insight itself.

The maths is currently on your side: founding cohort gets direct founder access and a reference exchange. After Series A, the team scales, pricing changes, and procurement enters the conversation. Right now is the most-favourable engagement window Event Horizon will ever offer.

What happens if Event Horizon gets acquired or shuts down?

Reasonable concern. Two protections in place.

First: the scanner itself is software running on your infrastructure. Even in a worst-case shutdown, the tool keeps running on the code you've already scanned. Reports already produced remain valid evidence.

Second: the patent protection is held by Rob personally as inventor, not by Event Horizon-the-company. If Event Horizon disappears, the IP and methodology still exist and could operate through any successor entity. For Sprint customers, the engagement agreement includes continuity clauses covering acquisition scenarios.

What's the production licensing model?

Scoped at end of Sprint or Extended Engagement, against the value those engagements demonstrated. Three tiers as a starting point: Team / division — low five figures annually. Enterprise (multi-team, multi-repo) — mid-five-figure to low-six-figure annually. Highly regulated (air-gapped, custom detector work) — scoped per conversation.

Pricing posture: anchored against audit-labour reduction and the cost of an internal security engineer (roughly £100K/year fully loaded in the UK), not against SAST seat licences — different category entirely.

While you're still here

The window Palo Alto's CTO named is closing.

No permission required.

Hosted AI is a dependency you don't control — it can be gated, repriced, or pulled by government directive overnight. In June 2026, exactly that happened — the two most capable frontier models were suspended for foreign nationals overnight by US directive. It took eighteen days and a government letter to switch them back on. Event Horizon runs on your machine; no vendor and no directive can revoke it. Yours, not theirs.

By the time AI-driven exploits become operational baseline, every codebase without an accurate structural identification of its crypto is exposed. The Sprint takes 7 days. The first conversation takes 30 minutes. The cost is a fraction of any alternative on the market.

The question isn't whether you need this. It's whether you find out you needed it before — or after — the next disclosure cycle.