Meerkat

Name: Meerkat
Brand: DeltaCoders

Sovereign AI with a Gate

Your people get AI good enough that they stop going around IT, and your sensitive material still never leaves the building. Two machines make that possible: one holds your documents and has no route to the internet, the other holds the credentials and decides, request by request, what may go out.

Get in Touch See All Products

At a glance

On-premises appliance Per-request egress decision Local model, optional cloud Labelled at ingestion Verifiable decision log No inbound remote access Installed and ingested on site

The box with your data has no way out,
and the box with a way out has no data

Meerkat is a local AI deployment that your people can actually use, with a border post in front of the internet. It runs on two machines: one holds the chat interface, the local model, and your documents, and has no route out; the other holds the cloud credentials and decides, for every single request, whether it may leave. The machine with your data cannot reach the internet, and the machine with the internet holds no data beyond what the gate allowed through.

A meerkat stands sentry while the rest of the group gets on with its work. It watches, and it decides what is worth passing on.

The Challenge

If your organisation has banned cloud AI, your people are already using it anyway, on their own phones, with company material pasted in. That is the leak that actually happens, and no policy has ever stopped it.

A purely local deployment is the usual answer, and it fails for a different reason: it is not good enough for the hardest tasks, so the workaround comes straight back. What is missing is not a better local model. It is a safe way to reach a bigger one when the request allows it.

The Solution

Meerkat puts a border post between your AI and the internet. The sanctioned tool becomes good enough to use for real work, because a request that carries nothing sensitive can be answered by a frontier model, while anything touching your protected material is answered locally and never leaves.

That decision is not a policy document or a setting somebody can turn off. It is enforced by the shape of the deployment: only one machine holds credentials to the outside, and it is not the machine holding your data.

One decision, in one place

Everything upstream of the gate can tighten the decision. Nothing upstream can loosen it.

Plenty is decided on the machine your people talk to: they can pick a model, retrieval returns only what they are cleared to read, and the classifier can refuse a request outright. But every one of those decisions can only stop information leaving. None of them can cause it to leave. The decision to send exists in exactly one place, on the only machine that can act on it.

The rules that define the product

Break one of these and it is a different product, not a configuration change.

Local can be forced, cloud cannot

A user can always insist a request stays on the local model. No user, and no setting available to a user, can insist that one goes to the cloud.

Unlabelled means sensitive

Material that has not been classified is treated as protected. An oversight during ingestion fails closed, towards keeping something in rather than letting something out.

Only the border post permits

The machine holding your documents has no route out. The machine holding the credentials decides for itself, and does not relay a judgement made elsewhere.

Honest about its limits

Meerkat defends against accident and default, which is where real leaks come from. It is not sold as a defence against a determined authorised insider.

Judgement at ingestion, not at runtime

Sensitivity is decided once, when your material is brought in. There is no latency budget at that moment, and a person can review the hard cases properly, with your vocabulary rather than a generic one.

The consequence matters more than it sounds: at the moment of the request, the gate performs a deterministic lookup rather than a probabilistic guess. A classifier still runs, as defence in depth, but it is not what your protection rests on.

Do not trust our log, check it against yours

Every decision is recorded: what was asked, what the verdict was, and why. That record is useful to an auditor, but on its own it is still our word.

So the design gives you something better. Because exactly one machine on that network has a route out, you can reconcile our decision log against your own firewall telemetry. Anything that left and is not in the log would show up in yours, which is an assurance no certificate can offer.

Key Features

Two-machine design: the box holding your documents has no route to the internet, and only the box that does can permit an escalation

A per-request decision, made in exactly one place, on the content of the request rather than on how capable the local model happens to be

Sensitivity labelled once at ingestion, where a human can review the hard cases, so the runtime decision is a deterministic lookup instead of a probabilistic guess

Users can force a request to stay local, and can never force one to the cloud

Unlabelled content is treated as sensitive by default, so nothing leaks through an oversight

A decision log you can verify against your own firewall telemetry, rather than having to take ours on trust

Retrieval that returns only what the person asking is cleared to read

Installed in your infrastructure, with the initial ingestion performed on your site: your documents never come to us, and there is no inbound remote access

AI Act Article 50(1) disclosure carried in the deployment baseline

How It Works

Install

We put the hardware into your infrastructure. The machine that will hold your documents is given no route to the internet, and nothing is granted inbound access to it.

Label

We run the initial ingestion on your site, in a workshop with your people, turning your judgement about what is sensitive into labels your material carries from then on.

Ask

Your teams work in an ordinary chat interface, with retrieval over your own documents, returning only what each person is cleared to read.

Decide

Each request reaches the border post, which weighs what it carries and either answers locally or escalates it to a cloud model. Unlabelled material stays in.

Account

The verdict and its reasoning are written to a log you can reconcile against your own network records, whenever you or your auditor want to.

Built for the material that cannot go out

Healthcare

Sending patient data to a cloud model rests on a legal exception that has never been properly tested. This is a way never to have to test it.

Financial services

A cloud provider you escalate to becomes a link in a DORA chain, and regulator audit rights you do not hold cannot be passed down. Containment avoids the chain entirely.

Sovereignty, one step further

EU-hosted alternatives answer where your data goes. Meerkat answers what is allowed to leave at all, which is a different and narrower question.

Your documents never travel

Installation and ingestion happen on your premises. Nothing is shipped to us, and there is no standing remote access into the deployment.