Proving What Your AI Could Not Reach

You cannot prove that an AI system never leaked data by reading its logs, because the log is written by the thing under suspicion. The provable claim is narrower and stronger: there was no route out to use. Mickai binds inference to loopback only and denies outbound traffic by default, so no destination exists until a person deliberately opens a named one, and that opening is a consequential action a human must approve or refuse. The rest is evidence you gather yourself, capturing packets on your own network while real work runs.

• Absence of leakage cannot be established from logs alone: logs are testimony from the system being questioned.
• Absence of a path can be established, because a path is a fact about bindings, routes and rules anyone can enumerate.
• Default deny outbound refuses every destination unless a human opens one deliberately and the opening is recorded.
• Loopback binding keeps the model reachable from the machine that owns it and from nowhere else.
• Packet capture during a real workload is buyer-run evidence, produced on your hardware, with our staff absent.
• Ask any supplier which parts of a no-egress claim you can test yourself and which have to be taken on trust.

Why can't log review prove that nothing was exfiltrated?

A log is testimony from the system under examination. For a leak to appear in it, the component must be built to record the act, be running the code you believe it is running, and have no reason to stay quiet. A serious auditor grants none of the three.

The request also has an impossible shape: prove a negative, from a source that is not independent of the question. A quiet log is consistent with nothing happening, and equally consistent with something happening quietly.

What does it mean to prove the absence of a path instead?

A path is a configurable fact: a socket bound to an address, a route in a table, a rule in a firewall, a name a resolver will answer. Facts of that kind can be listed and tested, unlike an account of past behaviour.

They are also checkable from outside, without asking the model anything: you ask the operating system what it is listening on, the network what it will forward, and a capture device what crossed the wire. That is architecture plus observation, and it counts because you can falsify it.

How do loopback binding and default deny remove the route?

Mickai runs a capable model on hardware the customer owns, and the inference endpoint binds to loopback. Loopback is itself an interface, but traffic on it never leaves the machine and never crosses a physical interface or the wire. The owning machine is served, while another host on the segment finds nothing to connect to: no listener exists on any routable address.

Outbound is default deny. There is no telemetry beacon, no licence check calling home and no background fetch waiting for connectivity. Where a deployment genuinely needs a destination, it is opened deliberately and named explicitly, and that opening is itself a consequential action, staged for a human to approve or refuse and sealed into the audit record. The same boundary holds across all sixty-three studios, production-ready and in development alike, so a capability added later cannot quietly add a destination.

How do you verify no-egress with your own packet capture?

Put a capture on the host and another on the network segment, then run the work you actually care about: long documents, sensitive matters, awkward queries, the studios your teams use most. Load matters, because a leak would be easiest to hide inside genuine traffic.

Then read what you caught. You are looking for any packet leaving the host for an address you did not authorise, any DNS query for a name you did not expect, and any refused connection that is retried. Our people do not need to be in the room: the evidence comes from your instruments, and it reads the same if we are wrong. Repeat it after every upgrade.

What should you ask any supplier who claims no egress?

Put the claim in terms a test can settle. Ask what address the inference endpoint binds to, and whether that address is loopback or routable. Ask what the outbound posture is before anyone configures anything: deny by default, or allow by default with a list of exceptions. Ask who has to approve opening a destination, and where that approval is recorded.

Then ask which parts of the answer you can observe for yourself and which have to be taken on trust. A supplier confident in the architecture hands over the deployment, stands back, and lets your own capture settle the question. Anything that lives only in a supplier's documentation is testimony, and testimony from an interested party is what this argument began by refusing.

What does the audit record prove once the path is closed?

Closing the path answers where data could go. The Open Audit Record answers what was done. Every consequential action is sealed into an append-only, hash-chained log, each entry carrying an index, a timestamp, an actor, a typed action, a target and a SHA-256 of its payload, signed with FIPS 204 ML-DSA, the post-quantum signature standard.

The record is tamper-evident, which means interference is detectable. Altering an entry breaks the chain and the signature, so the change surfaces when anyone verifies the record cold and offline with the operator public key alone. That property rests on key custody: an adversary holding the operator signing key could rewrite and re-sign a chain, which is why signed checkpoints written off the box and anti-rollback matter.

Frequently asked questions

Can the packet capture be run without Mickai staff present?

Yes, and better so. The test carries weight because we are absent from it. Bring your own tooling, network team and workload, and keep the files as your evidence.

What if your security team wants to attempt exfiltration deliberately?

That is a welcome exercise. Ask them to open outbound connections from inside the deployment, resolve external names, and reach the inference endpoint from another host. Expect refusals at the boundary and nothing to connect to from off the box.

Does having no outbound path mean the system can never be updated?

No. A closed default does not freeze a machine. It makes connectivity an event somebody authorises rather than a standing condition, which is the shape a consequential action already has: staged for a person to approve or refuse, with an owner and a record. Ask any supplier how material reaches the box and who has to approve it.

How can an auditor be shown that data stayed inside?

Present three artefacts together: the binding and firewall configuration showing no route existed, the capture files showing nothing crossed the wire while real work ran, and the audit record showing what was done and by whom, verifiable offline with the operator public key.

How do you get hands on it to test the claim?

We run a selective closed beta at mickai.co.uk/beta. Not every applicant is accepted, because we would rather work closely with organisations that intend to test the egress claim properly. If proving the absence of a path is your board's question, say so when you apply.