BREAK IT · the Liveware ingest gateway

What it isA door that checks the ID before it opens

Most systems take a request in, parse it, and only then decide whether to trust it. The parser runs on an attacker’s bytes before anyone knows who sent them, and that is where injection, deserialisation and malformed-input attacks live. break-it turns the order round:

1. Verify before parse. Each record arrives as a small signed packet. The gate checks its size, its magic number, its exact layout, the sender, the Ed25519 signature and the sender’s counter, in that order, on the raw bytes. Only then is it read. One failure and the record is refused, with the stage and the reason.
2. A living immune system. Every refusal is written to a hash-chained journal, classified into a family and fingerprinted. If it can never become valid, it becomes an exact antibody that drops the same bytes on sight; its shape teaches the family. Nodes pinned to each other share antibodies, and each re-runs them on its own gate before trusting one.
3. The rebound. A source the gate keeps refusing must attach proof-of-work before it is even looked at. The price rises with its own refusals (4,096 hashes a look past 100 refusals, 262,144 past 500); the gate checks the work in one hash and sends nothing back.
4. A referee. Behind the gate sits a deliberately naive app. A referee written separately from the gate watches every admitted message against an independent grammar and the ledger. If anything malicious ever reaches the app, the referee says so. That is the only way to win.

Start hereFour minutes, no install

1. Press ▶ play the feed in the live defence below. Real payment records from a public dataset are signed in your browser and sent through the real gate. Blue squares pass the gate and reach the core; the books line checks the app’s balances against the feed itself.
2. Launch an attack. Each red button builds one of the six known attack shapes from the latest genuine record. Watch it stop at the gate (pink), then send it again: it is dropped on sight by the antibody it just minted (purple), and its chip turns green.
3. Read the receipts. The pilot section shows every claim we sealed in git before measuring a real node, with what was measured and whether it held. The herd and the tarpit sections do the same for the living defence: a flaw that lands once and is then closed on every node, and a confirmed attacker made to wait. The failures stay on the page.
4. Put in your figures. The cost case takes your monthly volume and runs it against dated AWS list prices and your own electricity. Then try to break it: the console takes any bytes you like.

The gate · liveWatch it defend, in this tab

Everything below is the repository’s own gated code running in your browser: the same gate, immune system, sentinel, app and referee the tests, the mutation gate and the pilot ran. The feed is 180,000 real records; the attacks are the pilot’s six shapes. A breach shows only if the referee calls one.

The Liveware PilotSealed first, measured second, failures kept

One real node, as node run.mjs starts it, ran as the ingest gateway for a partner’s payment feed: the 180,000 records of a public dataset, with the six attack shapes injected mid-feed. Every claim below was committed to git before the measuring code existed; the measurement refuses to run if a claim has changed since its seal.

The run

Seals: . Receipt: receipts/pilot.json. Re-run it yourself: node pilot/measure.mjs (the whole pilot) or node pilot/check.mjs (what CI runs: the ledger and the books re-derived from the feed alone, and a real node re-run on the first 3,000 records).

How we got here, including what went wrong

One more thing we found after the run: six test processes left over from earlier, unrelated work on the same laptop had been running flat out for days and were competing with the node for the whole pilot. They have been stopped. The 194.6 records a second is what the node did with them running, so it is a floor, not a ceiling; the receipt stays exactly as measured.

The CFO’s receipt

The cost case is arithmetic, not a prediction, so it is not sealed. Its one measured input is the records a second one node sustained in this pilot. Run it with your figures in the next section.

The herd · living defenceA zero-day lands once. Then every node closes the hole itself

Every defence has a flaw nobody has found yet. When an attacker finds one in the gate, the same flaw is in every node, because every node runs the same code. Before this change, a breached node shared the attack with its peers, but a peer will not refuse bytes its own gate admits (no defence may ever turn on genuine traffic), so the same attack landed once on every node. Now the herd shares the proof instead.

1. It lands once. A packet the gate admits reaches the app. The referee checks every admitted message with its own grammar, written apart from the gate, and this one breaks it: a breach.
2. The proof travels. The node switches its referee’s grammar on as a stage of its door, writes the packet to its journal, and shares it with its peers, signed, at once.
3. Each peer checks it itself. A peer takes nobody’s word for it. It runs the packet through its own gate and its own grammar. Only if its gate accepts the packet’s form and its grammar rejects it, a zero-day proven on the peer itself, does it switch the grammar on too.
4. The hole closes for the whole family. From then on every node refuses at its door anything its grammar rejects: the same packet, and every variant of it.
5. Nothing genuine pays for it. A genuine record passes both checks, so it is admitted as before. A peer that shares a genuine record as if it were an attack proves nothing and patches nothing. The proof is kept in each node’s journal and checked again at every restart.

Measured, sealed first, on five real nodes

To measure what the herd does with a zero-day, we planted one: in the measuring process alone, a module hook loads the gate with its period limit off by one, so it accepts period 1200, a month past its limit. The shipped gate is untouched. The attack is the attack kit’s own out-of-range record, signed with the ingest key: the stolen-key case. Five nodes, as node run.mjs starts them, each pinning the other four, over loopback HTTP. The claims were committed before any measuring code existed.

Seal: . Receipt: receipts/herd.json. Re-run it yourself: node herd/measure.mjs (under a minute). CI runs node herd/measure.mjs --check on every push, and every claim must come out the same.

The tarpit · living defenceA confirmed attacker waits for nothing, and pays for the wait itself

The gate refuses every packet it cannot verify, at once and for almost nothing. A determined attacker, an automated one especially, simply sends again. The rebound already makes a source that keeps being refused pay proof-of-work before it is looked at. The tarpit is the next step, for a confirmed attacker only. Its refusals are no longer answered at once. The node holds the answer open, sends one space a second for twenty seconds, then sends the same refusal it would have sent. An attacker that waits spends its own time and connection on nothing. One that will not wait never learns why it was refused. Every refusal is still written down and turned into an antibody, as before.

1. Separation first. The tarpit decides after the gate has answered. A packet the gate admits is answered at once, from any address, so a genuine client never waits, even on the same address as an attacker. So are a proof-of-work challenge (anyone can pay it and get through), a replay or out-of-order counter (a genuine retry can cause one) and a behaviour refusal of a signed packet.
2. Only a confirmed attacker. A source is confirmed once the gate has refused it 500 times, the top rung of the rebound’s ladder. Below that, every refusal is answered at once.
3. Only a refusal no genuine key causes. A packet of the wrong size, form or grammar, from a sender the node does not know, with a signature that does not verify, or a known attack recognised on sight.
4. The waste. The answer is held for twenty seconds, one space a second, then the refusal is sent exactly as it would have been. JSON ignores leading spaces, so the answer still reads as the same refusal. Nothing else is sent: no redirect, no script, nothing aimed at the attacker’s systems. Everything happens on this node.
5. Bounded, and it fails to the ordinary answer. At most 64 answers are held at once. When the tarpit is full, a refusal goes out at once. A source that closes the connection ends its hold, and nothing is kept for it. It is off unless the operator switches it on.

Measured, sealed first, on a real node

One node as node run.mjs starts it, at the tarpit’s shipped settings, and a twin with the tarpit off where a claim compares, each in its own process. The attacker sends the attack kit’s own forgery from one address and pays the proof-of-work the node asks. Genuine records from the pilot’s feed come from another address, and from the attacker’s own. The claims were committed before any measuring code existed.

The two that failed, and why

loading…

What GitHub’s machine printed, run by run

CI re-runs the whole measurement on GitHub’s own machine on every push. p-4 and p-5 turn on how fast the attacker’s machine pays the proof-of-work, so CI prints its own verdict on those two without requiring it to match the receipt. Each line below is copied word for word from a run’s log into receipts/tarpit-ci.json (node tools/ci-tarpit.mjs <run>), because GitHub deletes logs after a while. Every recorded run is listed, the ones where p-5 failed as well as the ones where it held. loading receipts/tarpit-ci.json… The committed receipt keeps the laptop’s verdicts, because that is the run the claims were judged on.

Questions buyers ask

• Who counts as a confirmed attacker? A source is the network address a request comes from. A refusal is the gate turning away a packet it cannot verify: a forged or missing signature, an unknown sender, malformed bytes. An address the gate has turned away 500 times is confirmed. Genuine clients are not refused, so they never get there.
• How does the rebound fit? It is the step below. From 100 refusals an address must pay proof-of-work before each of its packets is even looked at; from 500 the tarpit also holds its refusals. The work slows how fast an attacker can arrive; the tarpit wastes the time of each attempt that does.
• How do I switch it on, and off? It is off by default. Start the node with the tarpit on (startNode({ tarpit: true }), or your own settings for the confirmation count, hold, drip and cap). A setting that is not a whole positive number keeps the default, so a typo can never widen it. Restart without it to switch it off; nothing else changes.
• What about customers behind the same address as an attacker (an office, a mobile network)? Their packets are verified and admitted at once; the tarpit only ever holds a refusal. Measured in p-2: 100 genuine records sent from the attacker’s own address were all admitted and none was held. They do pay the proof-of-work that address already owes, a small cost for a few packets.
• What about an attack spread over many addresses? The tarpit does not meet it: each address must be refused 500 times before it is held. A wide flood is met by the rate limit and the queue, and every refusal still becomes an antibody.
• What does it cost to run? Nothing to buy. While holding, the node keeps at most 64 connections open and sends each one space a second. What that does to genuine records is measured, not estimated: the median time with answers held and with none is in the table above for the laptop’s run, and in each CI run’s own line just above.
• What exactly does it send? Spaces, one a second, down the attacker’s own connection, then the refusal it would have sent anyway. It opens no connection to anyone, sends nothing anywhere else, and runs nothing on anyone’s machine.

Seal: . Receipt: receipts/tarpit.json. Re-run it yourself: node tarpit/measure.mjs (about ten minutes: most of it is the attacker waiting). CI runs node tarpit/measure.mjs --check and node tarpit/twins-7b.mjs --check on every push. Every claim must come out the same, except p-4 and p-5: they turn on how fast the attacker’s machine pays the proof-of-work, so CI re-runs them and prints its own verdict without requiring a match. That rule was added after the first run, and is said here.

Cost case · your figuresThe managed path against a node you own

The managed path in front of an ingest API is a web application firewall plus an API gateway, metered per million requests. Every price is a published list price, read from its primary page with the date below; every volume is yours. The case is computed by src/cost.mjs, which the mutation gate covers like the gate itself. break-it has no licence fee.

What the managed line leaves out, so it never overstates the saving against you: the compute behind the gateway that would have to check each signature, data transfer, logging and support plans. What the node line includes on purpose: the chip’s full 55 W every hour of the month, at the household price cap (the average UK business price was lower; see the sources below). The standing charge is paid whether a node runs or not, so it is left out.

Every price this case reads, with its source

How it worksOne record’s path, traced from the pilot

The numbers on the diagram come from the pilot’s receipt: what the real node did with the feed and the six injected attacks.

1. Limits first. The HTTP layer refuses a body without an exact Content-Length, a chunked body, anything over 336 bytes, and more than 300 requests a second from one address (bursts to 600). Nothing is parsed yet.
2. On sight. The packet’s SHA-256 is looked up in the exact-antibody library. A known attack is dropped here, after one hash, and the gate double-checks it would refuse it anyway, so an antibody can never block a genuine record.
3. The rebound. A source past 100 gate refusals must attach a proof-of-work token bound to this packet and this ten-second window. The gate checks it in one hash. The pilot’s feed never owed anything.
4. The gate. Size, magic number and version, the exact layout of the payload, a pinned sender, the Ed25519 signature over a domain prefix and the bytes, then the counter, which must be exactly the last one plus one. A REC record is 11 bytes: an account (1–99,999,999), a month (January 2000 to December 2099) and an amount (0–100,000,000), each checked as an integer on the bytes.
5. The sentinel. Verified traffic can still be wrong if a key is stolen. The sentinel watches each sender’s behaviour on Gary W. Floyd’s GEP ladder: a drain, a destruction run, posting over 10,000,000 in 64 records, or a mix that deviates from the sender’s own baseline is throttled, stepped up or blocked.
6. The ledger, then the app. The packet is written to a hash-chained ledger and fsync’d before the app sees it. On restart every packet is run through the gate again; one altered byte and the node refuses to start.
7. The referee. After every admitted message, the referee checks it with its own grammar and the ledger, and checks the app’s state is a replay of the ledger. This is the win oracle, and nothing else decides a break.
8. Every refusal teaches. The journal records the stage, the reason, the family and a fingerprint. Refusals that can never become valid mint exact antibodies; each is signed and sent to pinned peers, which re-run it on their own gates before adopting it.

BlueprintOrgan by organ

Each decision is a pure kernel with its own tests, and every kernel is under a mutation gate: the gate changes the code one operator at a time and the tests must catch every change. Survivors are only allowed with a written reason (witness.baseline.json). CI runs all of it on every push.

White-box red teamYou are invited to break it

The whole source is public, the attack kit is in the repository, and the battery of 79 attacks re-runs in CI and must reproduce its receipt byte for byte. Here is the console: paste or build any packet and send it through the same node this page runs.

For your businessWhat it does for each part of the company

break-it sits in front of a feed you take in, from a partner, a supplier or a fleet of devices, and lets nothing reach your systems that it cannot prove came from the sender you trust, in the order they sent it, in the exact shape you agreed. Every refusal is written down with its reason and teaches the gate; it runs on a machine you own.

Against what you pay for now

Security, data protection and audit

• UK GDPR by design. The records stay on your machine. There is no processor, no international transfer and no telemetry. The gate reads only the record’s own fields.
• Audit. Every admitted record is in a hash-chained ledger, fsync’d before the app acts; every refusal is in a hash-chained journal with its stage, its reason, its family and its fingerprint. Both are plain JSON lines.
• Keys. Each sender has its own Ed25519 key; the node holds only public keys. Rotating a key changes the key set, and antibodies bound to the old one stop firing for key-dependent stages.
• Fail-closed. Any error inside the gate refuses. A ledger the gate would refuse stops the node from starting.
• Explained. In the pilot every refusal, in the HTTP answer and in the journal, named its stage and gave its reason in words.
• Where the node sits. It listens on the machine’s own loopback address, so it has no port on your network. Whatever already brings the feed to you (your TLS endpoint, VPN or file drop) hands each record to the node on the same machine, and your network edge stays exactly as you run it today.
• What is read before the gate. Node’s own HTTP layer reads the request line and headers, capped at 8 KB, with a 2-second header and 3-second request timeout, a required Content-Length and no chunked bodies. The record itself is not read by anything until every gate stage has passed.
• Signed, not hidden. A signature proves who sent a record and that no byte changed; it does not hide the record. Confidentiality on the wire is the TLS you already run in front.

Roll-out

1. Week 1, your machine, your numbers. Run node pilot/measure.mjs on the hardware you would use. You get your own receipt: your rate, your egress meter, your books.
2. Weeks 2–3, shadow. Point a copy of one partner feed at a node through a signing adapter. Compare the node’s books with your system’s, record by record.
3. Week 4, gate. Put the node in front of that feed. Refusals go to the journal; your team reads reasons, not raw logs.
4. Then, the mesh. More nodes, pinned to each other, so an attack on one teaches all of them, and a flaw proven on one is closed on all (the herd’s patch is on unless a node is started with herdPatch: false). Switch the tarpit on when you want confirmed attackers held (tarpit: true). Then the next feed.

Ownership, support and exit

The software is MIT-licensed: no licence fee, the code is yours, and it keeps running without us. It is supplied by AI Native Solutions, where every deployment starts: contact them through that site. Support, service levels, warranty and liability are agreed per deployment, in each deployment’s agreement. Leaving costs nothing: the ledger and the journal are plain files.

Risks, answered straight

“One address is limited to 300 records a second.”

By design, with bursts to 600, so one source cannot crowd out the rest. A partner that sends faster sends from more addresses, or you run more nodes; the cost case adds nodes for your volume.

“How fast is one node?”

In the pilot, on one laptop, every record had its signature checked and was fsync’d to disk before the app saw it, at the rate the receipt shows. Disk sync is the ceiling; a server disk raises it.

“Our partners don’t sign records.”

They need a signing adapter at their end. That is what makes verify-before-parse possible: there is nothing to verify in an unsigned record.

“A partner’s key is stolen.”

The sentinel watches verified behaviour; in the battery a stolen feed key posting credit without end is blocked at record 5. Rotate the key and the node stops trusting the old one.

“What if the gate has a hole?”

The referee is written separately from the gate and checks every admitted message. A packet the gate admits and the referee’s own grammar rejects is a breach: that node switches the grammar on at its door, writes the packet to its journal, mints a signed rune and shares the packet with every pinned peer. Each peer checks the proof on its own gate and its own grammar before it closes the same hole, so the flaw lands once in the mesh, not once on every node (the herd, measured above). The packet is the fix’s test. A flaw in the gate and in the grammar at once would not be caught this way.

“How does a partner reach a node on loopback?”

Through what already carries the feed to you. Your TLS endpoint, VPN or file drop runs on the same machine and passes each record to the node. The node never needs a port on the network, so it adds nothing to your attack surface there.

“A partner sends a record wrongly by mistake.”

It is refused with its stage and reason, written to the journal, and the partner resends it correctly with the next counter. Mistakes cost a partner nothing: the rebound starts only after 100 refusals.

“Has anyone outside tested it?”

Not yet. The battery, the pilot, the herd and the tarpit runs are ours; what an outsider can do today is re-run every one of them, since the code, the claims and the receipts are public and CI re-runs them on every push. No outside team has reported on it, and no break has been filed in FINDINGS.md. Your own red team is welcome: the rules are in Break it.

“High availability?”

One node writes one ledger, under a lock. For capacity or a second site, run more nodes, each with its own ledger, pinned to each other.

The case for the board

White paperVerify before parse, measured

FAQQuestions buyers ask

What is break-it?

A secure ingest gateway. It sits in front of a feed you take in from partners or devices and checks every record's Ed25519 signature, its counter and its exact layout on the raw bytes before any software parses it. Every refusal becomes an antibody that recognises the same attack on sight, a repeat attacker must pay proof-of-work for each new look, and an independent referee watches the app behind it. It is MIT-licensed, runs on your own machine and sends nothing out.

Has it been tested on real data?

Yes. In the Liveware Pilot one real node ingested all 180,000 payment records of the UCI Default of Credit Card Clients dataset (DOI 10.24432/C55S3H) in 925 seconds, 194.6 a second on a laptop, with every signature checked and every record synced to disk before the app saw it. Its books equalled the feed on all 210,000 keys, six attack shapes injected mid-feed were each refused and then dropped on sight, and the referee found 0 breaches. 9 of the 10 claims sealed in git before the run held; the one that failed is kept on the page with its reason.

Does it send data anywhere?

No. The node listens on 127.0.0.1, has no telemetry and calls no service. In the pilot an egress meter loaded into the node process before the node counted every TCP, TLS, UDP, DNS and fetch attempt: once the node was listening there were none. The only call it made at all was Node resolving the literal 127.0.0.1 it binds to, which Node answers itself. The live page runs the same kernels in your browser under a security policy that allows requests only to its own files.

What does it cost to run compared with AWS WAF and API Gateway?

break-it is MIT-licensed with no licence fee; the running cost is the machine and its electricity. The page's cost case uses your own volumes with dated list prices: at AWS's own worked example of one web ACL, 19 rules and 10 million requests a month, WAF is $30.00 and a REST API Gateway adds $35.00, while one node drawing the laptop chip's 55 W maximum all month costs £10.57 at the Ofgem cap for October to December 2026.

What counts as breaking it?

The referee decides, and it is written independently of the gate. You win if the app acts on a message the gate never admitted, if the gate admits a packet an independent grammar rejects, if an action does not match its ledger entry, or if the app's state stops being a replay of the ledger. A win mints a signed Breaker's Rune.

Who supplies and supports it?

AI Native Solutions (ai-nativesolutions.com). The software is MIT-licensed and keeps running without us. Support, service levels, warranty and liability are agreed per deployment, in each deployment's agreement.

Whose work does it build on?

The sentinel's behaviour ladder is Gary W. Floyd's GEP ladder (Lumiea Systems Research Division, ThunderStruck Service, LLC; “GEP-Based Security: Behavioral Entropy Signatures for Cybersecurity and DevOps”, 2025), published as Open Defensive Prior Art under Creative Commons. The product is powered by the Konomi architecture, created by Thomas Frumkin, used with his permission. The pilot's feed is the UCI Default of Credit Card Clients dataset by I.-C. Yeh and C.-H. Lien, CC BY 4.0.