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 looks for them by structure, not by name — a thousand files in under a minute, on your own machine.

Ask for a live run →
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 what still carries its name, and very little once the names are gone. On our development set of 262 cryptographic files, an open-source keyword detector found 188 with their names in place and 17 with the names removed. An AI scanner could eventually find the rest — 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 function, written the way many AES implementations are written. 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 a label-based method has to match
Keyword scan
algorithm and API names
nothing to match
Library-call inventory
calls into known crypto libraries
nothing to match
API call graph
reachability from crypto API entry points
nothing to match
No algorithm name, no library call, no API entry point.
so a method that reads labels has nothing to report here
Event Horizon
Flagged — the shape of a factored block-cipher round
1 flagshape evidence for review, not identification
With the labels gone, label-based methods have nothing to match.

We measured it on 159 cryptographic implementation files from libraries Event Horizon was never tuned on, with every name, comment, string and include path removed. Matching algorithm and API names recognised 5 % of them. Matching standard constants, a published technique that also survives renaming, recognised 23 %. Event Horizon recognised 19 %. None of these is close to complete, and the limits section below says what we miss.

The same function, as four methods see it. The three label-based methods were not run on this example: each row shows what that method is built to match. The Event Horizon row is what its shipped detectors return on the code as shown.

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 source-code tools on the market find cryptography by its names, so they see what declares itself and little of what doesn't. 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 runs in minutes on your own machine and starts with one form.

What Event Horizon does

Point it at a folder. Minutes later, you have a map.

Not a list of bugs. A map of the cryptography it recognises — 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 — the rounds, the mixing, the arithmetic — and renaming does not change it, 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. We measure it with the names removed.

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

The claim, tested
Strip the file bare. Most answers don't change.

We took 159 cryptographic files from libraries Event Horizon was never tuned on and removed every name, comment, string and include path — everything a human or a keyword scanner would read.

Of the files it recognised as written, 30 of 34 were still recognised, 29 of them by exactly the same detectors. Matching names found 86 % of the files as written and 5 % once they were stripped.

That is the property we sell: what it recognises does not depend on the labels.

Scan pipeline
STEP ONE

Install it

A standalone program for a machine you choose, or a Python package. No cloud account. Nothing uploaded.

STEP TWO

Unlock it

One activation code, tied to your machine. Copied to other hardware, it won't run. 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.

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

Its structure matches a known reference. That is a match of shape, not a check that the code is the algorithm it resembles, or correct. Your normal review applies.

Not recognised

Mute

No detector fired. Most of any codebase lands here — menus, file handling, networking, screen drawing — and so does cryptography written in a family or style we have no detector for. Quiet is not the same as clean.

0%
Read this now
0.01%
Worth a glance
4.2%
Nothing odd
95.8%
Not recognised

Measured across 21,423 files in 29 open-source libraries in September 2026. The two review piles are rare by design.

Pointing a reviewer or an AI scanner at the files that fired, rather than at the whole estate, is what makes the downstream spend affordable.

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. Their inventories are only as complete as their discovery; we add the source files that carry no crypto names.
Migration platforms SandboxAQ, IBM Quantum Safe, PQShield Upstream of them. We are what makes their mandated first step correct.
Keyword & rule-based scanners Open-source keyword and rule-based detectors They match what the source says it is, and on labelled code that finds more than we do. With the labels stripped, name matching found 5 % of crypto files in unseen libraries; we found 19 %.
Structural recognition Event Horizon Recognises cryptographic structure with the labels removed, and publishes what it misses.
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. Twenty-three matched a known reference. One post-quantum routine sat on a family boundary. Nothing in the read-this-now bucket.
OpenSSL
201 files. Ten matched. All four NIST P-curve implementations and the post-quantum signature transform fire the same structural detector — a shape they share that isn't visible from the symbol tables.
NSS (Firefox's crypto)
235 files. Six matched, including Firefox's post-quantum implementation. Nothing flagged.
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 video routine carries a cryptography-like structure. Not a bug — but worth understanding why a codec fires a crypto detector at all.
FFmpeg (crypto utilities)
15 files. Four matched — including the AES implementation we missed on the first pass. We wrote the gap down, built a detector for it, and it is caught now.

Same input, same output. Every time.

We keep the full JSON for all seven scans and will share it on request. The figures above were last re-measured on 2 September 2026.

Across all seven — 787 files — the read-this-now bucket came back empty. One file was worth a glance. Those piles are rare by design, and these scans are the control, not the sales pitch. They also show what was missed: of the files named for a cryptographic primitive, 6 of 40 fired in wolfSSL, 4 of 47 in OpenSSL and 1 of 22 in NSS.

The reason to run this on your own estate is not that public libraries are full of surprises. It is that yours contains forks whose lineage was lost, hand-rolled routines nobody documented, and vendor variants that never went through any of that review — and unlike wolfSSL, nobody has ever looked.

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

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 recognises a minority of cryptographic code today. On 159 implementation files from libraries it was never tuned on, it recognised 21 % as written and 19 % with every label removed, while 3 % of non-cryptographic files fired. There are no detectors yet for RSA and Diffie–Hellman arithmetic, elliptic-curve arithmetic or authenticated encryption, and each detector recognises the coding styles it was built from. Everything we miss lands in the not-recognised pile.
  • A flag is evidence for review, not identification. Line layout can still change a result in the shipped detectors, a known limit.
  • It does not find bugs. It tells you where the cryptography it recognises 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.
  • If we have no detector for a crypto family, its files go quiet. They land in the not-recognised 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.

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.

How it starts

Thirty minutes, on code you choose.

I run Event Horizon live for you, on C or C++ code you pick. A public library is fine, so nothing confidential moves.

The next step

If it proves useful, a short pilot at your site.

Priority goes to defence, aerospace, embedded systems and regulated infrastructure. You work with me throughout; there is one of me.

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 Us. On your machine. 30 minutes to see it run The live run is free

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.

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

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, running on your own machine.

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: you deal directly with the person who built it.

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 · Virgin · Harris Communications · Nuffield Health · Fortune 500
  • Empirical workSeven real codebases scanned. Results reproducible bit-for-bit.
  • BasedDerby, Derbyshire, UK
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.

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 code and the thirty-year lineage existed first.

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

Then the timing question: thirty minutes to see it run on your own code, 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?

Everything runs on your infrastructure and nothing depends on our servers, so the reports you have produced remain valid evidence whatever happens to us.

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 first conversation takes thirty minutes.

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