Maxifai.

You cannot protect the cryptography you cannot find. Most companies cannot find all of theirs.

Find the crypto nobody labelled as crypto.

Forked libraries. Renamed files. Encryption sitting in something called utils.c. Point Event Horizon at a folder and it finds them — in about thirty seconds, on your own machine.

Get a Sprint slot →
No AI. No cloud. Same answer every time.
Event Horizon is hand-written software that runs on your hardware. Run it twice, you get the identical result — today, and in five years. That is the difference between a measuring instrument and a guessing machine.
The problem

You have cryptography in your code that nobody labelled as cryptography.

Not because anyone was careless. Because that is what happens to code over twenty years.

A library got forked, and the trail back to the original was lost.

Someone hand-wrote an encryption routine in 2011 for a perfectly good reason, and never wrote that reason down.

A supplier shipped their own variant with the labels stripped out.

And somewhere in there is a file called utils.c that is quietly doing real cryptographic work.

You cannot search for something that has no name.

Your keyword scanner finds none of it, because there is no keyword to find. An AI scanner could eventually find it — but only if you can tell it which files to look at first.

You almost certainly have a spreadsheet somewhere with supplier names and algorithm names on it. What you almost certainly do not have is the answer to a much simpler question:

Which actual files, in our actual code, do the actual encrypting?

Why labels fail
A name tells you nothing about what a file does.

A file called aes.c might contain a correct implementation, a modified variant, or almost nothing at all.

A helper file with a dull name might contain the real thing.

Traditional inventory tools read the nameplate. They work from filenames, import lists, metadata and declared dependencies. Every one of those is a label somebody typed, and labels drift, get copied, and get stripped.

Not our claim — theirs
The official fallback is, literally, hope.

CISA's own strategy for automated cryptographic discovery states it is not certain current tools can detect algorithms embedded in software packages or in custom code — and that for third-party products, agencies may simply have to ask the vendor and track the answer manually.

For deeply embedded systems, industry guidance puts achievable inventory coverage at 60–80% even with full vendor cooperation, with vendor documentation as the primary discovery mechanism and scanning used only to verify.

So the most sensitive estates in the world are being inventoried by questionnaire.

There are five ways the industry currently finds cryptography in an estate. A keyword scan. A certificate. A handshake. A running process. Another tool's telemetry.

Every single one of them requires the cryptography to declare itself. What doesn't declare itself isn't found. It's assumed.

Here is one file. It is real, ordinary code — and it is AES. Every label that would say so has been removed.

One file · util_transform.c
static void transform_block_v2(uint8_t *s, const uint8_t *k) { for (int r = 0; r < 14; r++) { sub_step(s); shift_step(s); mix_step(s); xor_step(s, k + r * 16); } }
It is AES. Every label that would say so has been removed.
What the market's tools return
Wind River crypto-detector
keyword scan
0 findings
IBM Quantum Safe Explorer
known-library calls
0 findings
SCANOSS Crypto Finder
call graph from API entry points
0 findings
“No cryptographic artefacts found.”
which the customer reads as: there is none here
Event Horizon
Classified — block-cipher round structure, AES family
1 findingfrom shape alone
This is not a performance gap. It is a category error.

A keyword scanner does not sometimes miss hand-rolled cryptography. It misses all of it, every time, by construction — because there is nothing for it to match against.

The same file, put to four instruments. Not a thought experiment: this is what each method is documented to look for, and what it therefore returns.

Why the dark third is the dangerous third

Unlabelled cryptography is, by definition, the cryptography that never went through standardised review.

It is simultaneously the hardest to find and the most likely to be wrong — and it is the part the entire migration programme is currently guessing at.

That gap has been awkward for years. You could live with it. Everybody did.

This year it stopped being awkward and became dangerous.

What changed this year

Code nobody could break for twenty-seven years just got broken in a week.

Four things happened between April and August. All four are public. Read them in order.

Disclosure timeline
01 — April 2026

The machines learned to find the bugs.

Anthropic released an AI called Mythos and pointed it at software the whole industry has trusted for decades. It found flaws that had been sitting there for seventeen years. Twenty-seven, in one case. Human beings had reviewed that code many, many times.

02 — May–June 2026

Then the floodgates opened.

One major security company pointed the same class of tool at its own products and found seventy-five flaws in a single engagement — fifteen times its normal rate. Their chief technologist went on stage and said out loud how long he thinks the industry has. By June, the number of serious flaws disclosed in one month was three and a half times the previous record.

03 — 28 July 2026

It broke the new encryption before we finished adopting it.

The same AI was turned on the mathematics of encryption itself. It found a hidden weakness in one of the new algorithms designed to survive quantum computers — and the people who designed it withdrew it. That took about sixty hours.

04 — July–August 2026

Then it came for the crypto libraries themselves.

One of them runs inside five billion devices. It took a critical flaw that let forged certificates through as genuine. Another had a memory bug in its brand-new post-quantum code. The public running total is now in the thousands, across hundreds of projects.

There are four of these tools now, from four of the biggest companies in the world. Every one of them runs on somebody else's computer. Every one of them hands back a probability, not a record. And the most capable one was switched off for eighteen days last June by government order.

The question stopped being “is our cryptography broken?”
It became “do we even know what cryptography we have?”

For the record — the four tools
  • Mythos (Anthropic) — found the FreeBSD, OpenBSD and FFmpeg flaws above; broke the HAWK post-quantum signature candidate on 28 July 2026 and delivered a 200–800× speed-up against reduced-round AES, at a cost of roughly sixty hours and $100K of compute. Distributed through the Glasswing programme; since June's 18-day export suspension, restored only to approved US organisations.
  • Daybreak (OpenAI) — public application form, cyber-trust vetting.
  • MDASH (Microsoft) — announced at Build 2026, bundling into Defender and GitHub.
  • CodeMender (Google) — limited release.

The June record: roughly 1,546 high- and critical-severity vulnerabilities disclosed in a single month, 3.5× the highest monthly total ever recorded before Mythos. The August library wave: wolfSSL took CVE-2026-5194 (CVSS 9.3, missing digest checks in signature verification); libgcrypt took a memory-safety bug in its ML-DSA implementation. Anthropic's public disclosure dashboard stood at 2,300 vulnerabilities across 392 open-source projects as of 26 August 2026.

The other clock

And now the deadline has a date on it.

The AI story is the frightening one. This is the one your board will actually be asked about.

The two clocks

Regulators spent years telling banks, telecoms, defence suppliers and infrastructure operators to get ready to replace their encryption before quantum computers arrive.

For years that was a direction of travel. Nobody had to do anything by Tuesday.

In 2026 it acquired dates.

Britain wants a complete inventory of your cryptography by 2028. Europe wants member states starting theirs by the end of 2026. America has put the inventory file itself into a presidential order, with the required contents due by March 2027.

Every one of those programmes begins with the same step. Not “buy new encryption.” Not “upgrade the servers.”

Make a list of the cryptography you already have.

And here is what everybody discovers the moment they start: there is three to five times more of it than the plan allowed for. That overrun is not bad planning. It is what happens when you build the list from labels — because the labels are the thing that's wrong.

Most organisations have a plan. Almost none have the means.

The dates, precisely
  • UK — the NCSC migration roadmap requires cryptographic discovery and inventory complete by 2028, high-priority migration by 2031. That 2028 baseline is what sector regulators will assess designated operators against.
  • EU — the NIS Cooperation Group's Coordinated Implementation Roadmap has member states beginning inventories by 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. Minimum elements due from CISA and NIST by March 2027; federal high-value systems on post-quantum key establishment by 2030.

Behind those: NIST's FIPS 203/204/205 standards (August 2024), NSA's CNSA 2.0 timeline (2030 begin-shift, 2035 full phase-out), DORA (live 17 January 2025), FCA SYSC 15A and ENISA.

The number everyone hits
3–5× more than planned

Almost every organisation that begins replacing its encryption discovers three to five times more cryptography in its estate than the plan allowed for.

A large payments institution typically ends up facing 120,000+ separate migration tasks.

Whose word this is

NCCoE — NIST's applied cryptography programme — names inventory as the foundational first step of any post-quantum migration. Not our claim. Theirs.

The clock is already running, and it cascades down the supply chain.

Executive Order 14412 — “Securing the Nation Against Advanced Cryptographic Attacks” — was signed on 22 June 2026, and legislation to codify it has been introduced. These are its dates.

DateWhat becomes due
Live now DORA across the EU · FCA SYSC 15A · NCSC and ENISA inventory guidanceRegulated entities must already document and manage a cryptographic inventory.
22 Oct 2026 Federal agency post-quantum migration plans due
End 2026 EU member states begin cryptographic inventoriesNIS Cooperation Group roadmap, in machine-readable CBOM format.
19 Dec 2026 Proposed federal procurement rule — covered contractors to meet the new standardsCascades straight down the supply chain to their suppliers.
19 Mar 2027 Minimum contents of a Cryptographic Bill of Materials publishedVendors must be able to declare what cryptography their product contains. This is the one that bites.
2028 UK: cryptographic discovery and inventory completeThe NCSC baseline sector regulators will assess designated operators against.
2030–2031 Federal key-establishment and digital-signature migration deadlinesCNSA 2.0 begin-shift for national security systems; full phase-out by 2035.

Why the March 2027 line is the one that matters. A Cryptographic Bill of Materials obliges a supplier to declare the cryptography inside its product.

You cannot declare what your tooling cannot see.

And the tooling on the market today can only see what already declares itself. From that date, this stops being a security problem and becomes a filing problem — for every supplier in the chain.

Your options

So what are you actually going to do about it?

There are five paths. Be honest about each one.

1

Wait and hope.

Hope the window doesn't close. Hope nobody asks you for the inventory before you have one. Hope the next disclosure isn't in your code.

2

Hire your way out.

Bring in cryptographers — in the exact quarter when every bank, telecom and defence contractor is trying to hire the same people.

Or pay a consultancy £150,000 to £300,000 for a report that is out of date the morning after they close the laptop.

3

Ask your own team to read everything.

Tell them to go through eighteen thousand files. Tell them what to look for.

Except you don't know what they should be looking for. Not file by file. Not specifically. Nobody does — not your team, not your suppliers, not the auditor you'll bring in to check their work.

4

Wait for one of the AI scanners.

Access is widening, slowly and unevenly. But access was never really the problem.

Every one of them runs on someone else's computer. Your source code goes into their pipeline, and what comes back is a confidence score — not a record your auditor can re-run. That gap doesn't close when the queue does.

5

Make a plan and work the plan.

Study the window. Model it. Build a measured response. Take it to committee. Watch the calendar.

The problem isn't waiting for your plan.

None of those five is stupid. They are just slow, expensive, blind, or not actually available to you.

The path that is none of those things takes about thirty seconds and starts with one form.

What Event Horizon does

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

Not a list of bugs. A map of where your cryptography actually is — found by shape, not by name.

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

Every piece of cryptographic code has a shape.

Underneath the variable names and the comments there is a structure that stays the same across every implementation of the same algorithm — whether the file is called aes_round.c, transform_block_v2.c, or utils.c.

We call that shape its C-DNA. It is the file's real identity. The name on the front is just a label somebody typed.

Event Horizon reads the shape and ignores the name.

That is the whole idea. Everything below is how it reaches you and what comes out.

The claim, tested
Strip the file bare. The answer doesn't change.

Take a cryptographic file and remove every name, every comment and every include — everything a human or a keyword scanner would read.

Event Horizon still classifies it correctly, because none of what it reads was in the labels to begin with.

No other tool in this market can say that sentence.

Scan pipeline
STEP ONE

Plug it in

One signed installer for your machine, or a pre-loaded USB stick we post to you. No cloud account. No libraries for your team to vet. One self-contained tool.

STEP TWO

Unlock it

One activation code, tied to your machine. If the stick is lost or copied, it is dead on any other hardware. Yours, not theirs — made literal.

STEP THREE

Point and scan

A window opens in your browser, running entirely on your own machine. Pick a folder. Press Scan. Nothing leaves the building.

What happens inside those thirty seconds

1

Source

You point it at a folder of C/C++ files. No network needed at any stage.

2

Shape read

Each file's structural signature — its C-DNA — is read beneath the variable names and comments.

3

Detectors fire

Independent structural detectors run over every file, each tuned to a different algorithm family. What comes back is a structural profile of the file.

4

Compare

That profile is compared against known references to decide which family the file belongs to — and how closely it matches.

5

Report

A readable report, a machine-readable inventory, and a feed for whichever security tooling you already run.

No model weights, no inference, no network at any stage. Five deterministic steps, running on your hardware, producing the same answer on every run.

What comes back

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

No wall of alerts. No severity scores to argue about. Just an order to read things in.

Four-bucket triage
Read this now

Unknown

Shaped like cryptography — but it doesn't match anything we recognise. Could be something novel. Could be something broken. Either way, a human should look at it first.

Worth a glance

Boundary

The right family, but it doesn't sit quite where the reference sits. Usually a deliberate optimisation. Occasionally something more interesting.

Nothing odd here

Consistent

Matches a known reference cleanly. Structurally it is what it claims to be. Your normal review applies — nothing extra to chase.

Not cryptography

Mute

No detector fired. This is the 80–90% of any codebase that is menus, file handling, networking and screen drawing. Out of scope.

~1%
Read this now
~2%
Worth a glance
~7%
Nothing odd
~90%
Not cryptography

On a typical eighteen-thousand-file codebase, you go from “review eighteen thousand files” to “start with these hundred and eighty.”

That is also the number that makes everything downstream affordable. An AI scan across eighteen thousand files is arithmetic nobody can afford at estate scale. Across a hundred and eighty, it is a rounding error.

We don't replace the tools you already run. We tell them where to look.

What the evidence pack actually contains

One scan, five output formats, designed to drop into whatever toolchain you already have:

  • JSON — the machine-readable master artefact for downstream automation.
  • Markdown — a human-readable summary for your security team.
  • HTML dashboard — offline-readable, single page, per-file drilldown.
  • SARIF — the standard static-analysis format, for GitHub, GitLab and Azure DevOps pipelines.
  • CycloneDX CBOM — the Cryptographic Bill of Materials named in EO 14412 and required by the EU roadmap. Feeds SandboxAQ AQtive Guard, IBM Quantum Safe Explorer, Keyfactor, PQCA CBOMkit and others — with structurally-derived entries rather than label-derived ones.

Every pack is hash-sealed: a 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.

There is also a drift command — event-horizon drift earlier.json later.json — which reports what changed structurally between two scans. Useful for quarter-on-quarter reporting under DORA, FCA SYSC 15A or NCSC audit cycles.

Your C/C++ source code
Any size. On your infrastructure. Nothing uploaded.
↓
Event Horizon
Reads structure · seconds to minutes · on your machine · same answer every time
↓
↓
↓
Your inventory tooling
SandboxAQ, IBM Quantum Safe Explorer, Keyfactor, PQCA CBOMkit — fed with entries derived from structure rather than from labels
Your AI scanner
Mythos, Daybreak, MDASH, CodeMender — pointed only at the files that are actually cryptography
Your reviewers
Human cryptographers, working down a list that is ordered rather than alphabetical
Your migration programme
The foundational inventory step, done properly rather than estimated

One run, four downstream consumers. Everything below the middle box works better when it is pointed at the right two hundred files.

CategoryWho is thereWhere we stand
AI vulnerability scanners The frontier AI labs Upstream of them. We tell them which files are worth the spend — a partner, not a rival.
Inventory platforms SandboxAQ, IBM, Keyfactor Upstream of them. They inventory what declares itself; we make that inventory complete.
Migration platforms SandboxAQ, IBM Quantum Safe, PQShield Upstream of them. We are what makes their mandated first step correct.
Keyword & rule-based scanners Wind River, SCANOSS, SonarQube, Semgrep They see what the source says it is. We see what it is.
Structural recognition Event Horizon. Nobody else. The category we created — and currently occupy alone.
Proof

We ran it on seven real codebases. Here is exactly what happened.

All seven are public, so anyone can check us. Five of them are now on the AI disclosure lists.

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 on a laptop and wrote down what came out — including the parts that didn't flatter us.

wolfSSL
237 files in 31 seconds. One file flagged read-this-now — a post-quantum routine that matched nothing we know. Two worth a glance. 23 clean. 213 not cryptography.
OpenSSL
201 files. Ten clean across the main algorithm families. One structural pattern recurring across all of them that isn't visible from the symbol tables.
NSS (Firefox's crypto)
235 files. Six clean, including Firefox's post-quantum implementation. Clean classification across the board.
curl
31 files. Nothing fired — correctly. curl's security layer is plumbing, not cryptography. Verified silent.
FreeBSD network filesystem
19 files. Nothing fired. This is where the AI found a seventeen-year-old flaw — and we correctly stay quiet, because it isn't cryptography. Different question, different layer.
FFmpeg (video codec)
49 files. One flagged worth-a-glance: a video routine with a cryptography-like structure. Not a bug. But worth understanding why.
FFmpeg (crypto utilities)
15 files. Three identified. And one we missed — see below. We documented the gap and closed it in the next iteration.

Same input, same output. Every time. Anyone with the public code and the scanner gets our numbers.

The honest one — August 2026
A critical flaw appeared in wolfSSL. We did not find it.

wolfSSL patched it in August: its signature check accepted digests shorter than allowed, so a forged certificate could pass as genuine. The fix added the missing minimum-length check. We pointed our preview layer at both versions.

One measurement moved. On the unpatched code, its length-check reading is 0 — the check is there, but incomplete. On the patched code, the same reading is 1. The change lands on exactly the lines the fix touched, and repeats identically every run.

What that is, and isn't. That measurement flags around two-thirds of cryptography files as worth a look — in patched and unpatched code alike. So the flag on its own isn't the finding. The finding is that the number moved precisely where the bug was. One class, one library, examined after the fix was already public. That is candidate evidence, not proof.

Here is why any of that matters to you. If publicly-audited libraries like these — decades old, read by thousands of eyes — still surface this much structurally interesting material, then your own code, which is less audited and full of forks and bespoke work, is almost certainly carrying its own surprises.

The question isn't whether there is something surprising in your inventory. It's whether you have a defensible record of having looked.

Preview layer · not the shipping product

Famous flaws had a shape too.

Every published class of vulnerability leaves a recurring structural signature. We keep a catalogue of them. This is the layer after the inventory — and it is early. Read the limits below before you weigh it.

Family radar
Heartbleed
2014
A buffer-overflow class in the handshake that sets up a secure connection. It affected OpenSSL and every major implementation that adopted the same code path.
FreeBSD file sharing
2026, found by AI
A memory-safety class in a state machine. It sat undiscovered for seventeen years. The signature had been recurring in code since 2009.
wolfSSL certificates
2026, found by AI
A verification-bypass class: a missing check meant forged certificates were accepted as genuine. Rated 9.3 out of 10, in software running on five billion devices.

A catalogued class has a shape, and we can tell you which of your files match that shape.

That is a review list, not a bug list. Most files on it will turn out to be fine. The point is that it is short enough for a person to actually read, and that you get it without sending your code anywhere.

What we don't claim

Everything Event Horizon is not.

All of it in one place, rather than sprinkled through the page where it's easy to miss. If we're straight with you about the limits, you can believe us about the rest.

The limits, stated plainly

  • It does not find bugs. It tells you where your cryptography is and which family each piece belongs to. Finding flaws inside those files is the job of your security team, your existing analysis tools, or an AI scanner — pointed at the short list we produce.
  • “Nothing odd here” is not a clean bill of health. It means the file structurally matches a known reference. It does not mean bug-free, side-channel-safe, or approved by anyone. Our output is a measurement, not a verdict.
  • It does not replace anything you already run. Not code review, not your static analysis tools, not fuzzing, not formal verification. It sits upstream and tells each of them which files deserve their time.
  • This is version one. Python, measured on a laptop, parallelised but not optimised. A thousand files finish in well under a minute; larger estates run into the minutes. We publish measured numbers and never projections — compiled builds on real hardware will move this materially, and we won't quote you that until it exists.
  • The vulnerability-matching layer is in preview. On our own figures the measurement described above flags around two-thirds of cryptography files as worth a look — in healthy and unhealthy code alike. It has no ground-truth validation yet. That class is ratified when the validated release ships, and not before. That is why it is a preview and not a product.
  • The wolfSSL result above was a look-back, not a catch. One class, one library, examined after the fix was already public, not independently re-run. Candidate evidence, not proof.
  • If we have no detector for a crypto family, its files go quiet. They land in the not-cryptography pile. That is the scanner saying “we didn't see it with the detectors we have” — it is not a security verdict. Coverage expands with each release, and gets calibrated against your code during a Sprint.

There is a reason we won't claim to find vulnerabilities: nobody can honestly validate that claim. A flaw is only “confirmed” once someone has found and proven it, and “confirmed clean” is close to impossible — you can never show a file has no flaws, only that none are known yet.

So no vendor and no AI lab can give you a real false-positive rate for finding exploits in production code. They report what they found, not what they missed.

We make the one claim you can check: here is where your cryptography is. Open the file. See if we were right.

The offer

The first three are free.

Not a discount. Not a trial with a card on file. Free.

Founding cohort · 3 slots

Seven days. Run by me personally. No charge.

In exchange I ask for one thing at the end: a sentence I can quote saying you ran it. That's the whole deal.

You also get a first-year discount if you go on to licence it, one free re-scan at six months, and priority if you're in defence, aerospace, embedded systems or regulated infrastructure.

When those three are gone, the front door becomes a paid engagement starting in the low five figures. That isn't a scarcity trick — there is one of me, and a Sprint takes a week.

You can walk away at any point with 48 hours' notice. The deal is deliberately lopsided in your favour.

For context, here is the same question — where is our cryptography? — priced four ways. Every number below is public: published consulting rates, published per-token pricing, standard audit project costs. Nothing invented.

ApproachWho does itHow longWhat it costs
Manual crypto audit Big Four or boutique consultancy 4–8 weeks £150K – £300K
Discovery inside a migration programme Specialist consultancy or vendor-led Quarters £500K+ as a line item
Comprehensive AI scan Anthropic or OpenAI, hosted 1–2 weeks setup, then scan £80K – £1M+ in compute
Event Horizon Sprint Us. On your machine. 7 days Free for the founding three. Low five figures after.

The first three rows are what it costs to answer this question without us. They aren't competitors — the AI scan in row three needs our answer before it can be scoped at all.

If a Sprint surfaces one piece of cryptography you didn't know you had, it has paid for itself several times over against every other row in that table.

The hard part isn't the decision. It's finding thirty minutes to have the conversation that starts it.

Founding Sprint — 3 slots

  • Seven days, run by the founder throughout
  • Free of charge
  • A reference statement at the end — one sentence saying you ran it
  • First-year discount on the licence if you continue
  • Priority: defence, aerospace, embedded systems, regulated infrastructure
  • One free re-scan at six months

Extended Engagement — scoped

  • Deeper than a Sprint: pipeline wiring, multiple repositories, a longitudinal baseline
  • Founder-led, ten to fourteen days
  • Scoped to how much code there is and how much integration you want
  • Includes detector calibration against your own codebase
  • The natural step before committing to annual licensing
  • Available once the founding cohort closes

What the seven days look like

  • Day 1 — a 30-minute call. We agree what we're scanning.
  • Day 2 — the first scan runs against the code you've agreed.
  • Day 3–4 — we go through it together: what's unknown, what's borderline, what fired and shouldn't have.
  • Day 5 — you get the evidence pack: the file inventory, a baseline to measure future drift against, the prioritised shortlist, and a walkthrough recording.
  • Week 2 (optional) — calibration against your code, a second pass, or wider scope.
Who you're talking to

One person built this. That is the point, not the disclaimer.

One founder. One laptop. Structural cryptographic recognition at enterprise scale, handed to you on a thumb drive.

Event Horizon isn't a security startup. It's a thirty-year research arc that found an urgent use.

The method underneath 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. Cryptography is simply the first place it has been sold.

The product you'd buy from a Silicon Valley startup is built by people who learned cryptography at university. This one is built by someone who came to cryptography after thirty years of studying how meaning, structure and form behave across language, music and visual art.

That isn't trivia. That's why it works.

New categories almost always start with one head. Teams scale an insight; they rarely produce it. The maths is currently in your favour — the founding cohort gets direct access and a reference exchange. After a funding round, the team scales, the pricing changes, and procurement joins the conversation.

What that means in practice: when you fill in the form, Rob reads it and replies. Usually within 48 hours, always within 48. Not a sales rep, not an automated sequence. Him. If Event Horizon doesn't suit your situation, he'll say so.

Rob J. Ballentine — at a glance

  • Background30 years in cognitive linguistics, structure and meaning, and perceptual realism
  • Consulting clientsUK Royal Air Force · QinetiQ · Rolls-Royce · Virgin · Harris Communications · Nuffield Health · Fortune 500
  • PatentsUK & US provisionals filed 27 August 2025, held personally as inventor. Further filings in flight.
  • Empirical workSeven real codebases scanned. Results reproducible bit-for-bit.
  • BasedSandhurst, Berkshire, UK
One engine, three applications — where this goes next
Platform anatomy

Event Horizon (shipping) — the boundary, where cryptography reveals itself. The scanner you can run this week.

Photon Sphere (shipping) — the trapping shell. The mechanism that binds each copy of our software to its authorised machine, licence and build. It's why Event Horizon can be handed to you on a thumb drive and stay yours, not theirs.

Singularity (preview) — the core. Structural triage of crypto files against a catalogue of known vulnerability-class signatures. Calibrated and in preview today; full held-out validation still underway. See the limits section above — this is the early layer, and we say so.

All three are the same engine, reading the structure underneath the labels. Event Horizon is where you start. It is not where this ends.

Before you sign up

The questions people actually ask.

Answered straight, including the ones where the answer is “then you don't need us.”

We already pay for code-scanning tools. Why do we need you as well?

You don't — if you already know which files in your code are cryptography and which family each one belongs to. Almost nobody does.

Your existing tools find bugs. They're good at it. But they only help when they're pointed at the right code, and most codebases are 80–90% not-cryptography. Running crypto-specific checks across all eighteen thousand files wastes the budget on the seventeen thousand eight hundred that aren't relevant. The alternative — guessing from filenames — is exactly the thing that fails.

There's also a different question hiding in there. Your bug-finder answers “did you find bugs.” Your regulator asks “do you know your cryptographic inventory.” Different artefact, different layer. If your existing vendor says they produce an inventory too, ask them how. If the answer involves filenames or keyword matching, they're reading the nameplate rather than opening the door.

How do you handle our proprietary source code?

It never leaves your environment. There is no upload, no API endpoint, no external dependency that touches your code while it runs.

You get it as either a Python package you install in a controlled environment, or a standalone executable you drop on a machine of your choosing. Air-gapped deployment is supported.

Is this AI? Should we worry about the black-box problem?

No AI in the loop. No neural networks, no model weights, no cloud calls. That's deliberate.

Evidence that supports an audit has to be repeatable. Run an AI scanner twice and you can get two different answers. Run Event Horizon twice and you get identical output, byte for byte. That is the whole difference between an instrument and an exploration tool.

Is this just a website with an AI-generated business behind it?

A fair thing to ask in 2026. Here's how to check.

The method predates AI vulnerability discovery as a category — the research arc runs from the 1990s. UK and US patent provisionals were filed on 27 August 2025 with a documented priority date, independent of any model run.

The scanner itself is hand-written deterministic Python: no model weights, no inference, no API calls. AI tools helped write some of the copy on this website. The method, the patents, the code and the thirty-year lineage existed first. If you want to verify before engaging, ask for the filing receipts on the call.

Why can't we just build this ourselves?

Legitimate path, so here's the honest comparison.

The method is the difficult part, not the code. It combines cognitive linguistics, signal-processing-style structural analysis, and cryptographic family taxonomy — a cross-disciplinary insight that took thirty years to develop and eighteen months to reduce to a working scanner. Building something comparable in-house is realistically twelve to twenty-four months across several engineers, with no guarantee of arriving anywhere useful. The patent provisionals also make a clean-room reimplementation awkward.

Then the timing question: seven days with us, versus an eighteen-month internal programme that finishes after the window closed. If you have the in-house capability and the time to wait, you genuinely don't need us. Most teams have neither.

What happens if you get acquired, or you stop?

Two protections. First, the scanner runs on your infrastructure — even in a worst case it keeps working on the code you've already scanned, and the reports you've produced remain valid evidence.

Second, the patents are held by Rob personally as inventor, not by a company that could be wound up. If the business disappeared, the method and the IP would still exist and could operate through any successor. Sprint agreements include continuity clauses for acquisition and change-of-control.

What does it cost after the free cohort?

Sprints start in the low five figures, scoped against how much code there is and how much integration you want.

Ongoing licensing is scoped at the end of a Sprint, against what that Sprint actually demonstrated. As a starting point: a single team or division is low five figures a year; multi-team, multi-repository enterprise is mid-five to low-six figures; heavily regulated environments with air-gapped deployment and custom detector work are scoped per conversation.

We anchor that against the cost of the audit labour it removes and of a single in-house security engineer — roughly £100K a year fully loaded in the UK — not against per-seat tool licences, which are a different category entirely.

Last thing

Nobody can switch this one off.

Yours, not theirs.

Hosted AI is a dependency you don't control. It can be gated, repriced, or pulled by government order overnight — and last June, exactly that happened. Eighteen days and a government letter to switch it back on.

Event Horizon runs on your machine. No vendor and no directive can revoke it.

The Sprint takes seven days. The first conversation takes thirty minutes. For the founding three, it costs nothing.

The only question left is whether you find out what's in your code before the next disclosure cycle, or after it.

Don't fancy the form? Direct line: rob@maxifai.com