A vendor’s deck answers the questions the vendor chose. A security architect asks a different one: what does this software need from outside my network, and what leaves through it? Send the eight requirements below to the vendor in writing, before the demonstration. Each comes with a test you run yourself and the answer that should disqualify the vendor.
1. It runs under your accounts, your keys and your jurisdiction
The software installs in infrastructure you control, authenticates against your identity provider and encrypts with keys you issue. It needs no vendor control plane to start, stay licensed or keep working. If one exists, you can switch it off and the software keeps running.
How to verify. Block the vendor’s domains at the firewall and restart the software. Ask for the list of every host it will ever contact, then compare it with your egress logs after a week in production.
Disqualifying answer. “The control plane is hosted in an EU region.” What counts is the jurisdiction, not the location: data held by a provider under US jurisdiction is reachable wherever the datacentre is.[1] The CLOUD Act requires such a provider to produce data in its possession, custody or control, regardless of where it is stored.[2]
2. It runs fully isolated, and you can prove it
The deployment can run today with no external model and no external network, on a model you host yourself. An AI system that depends on a connection to a datacentre under foreign jurisdiction can be cut off at the moment it matters most.[3]
How to verify. Deploy in a network segment with no default route and run the demonstration there. If it needs an exception, you have your answer.
Disqualifying answer. “Our model endpoint is private and encrypted in transit.” Encryption protects the connection. The question is whether the connection exists.
3. No copy of your data exists without your decision
Every extract, index, cache and embedding store is a copy. For each, you must know where it is, who reads it and when it was made. A vendor that keeps copies outside your perimeter holds your data.
How to verify. Ask for an inventory of every place the software stores anything derived from your data. Then check the volumes yourself.
Disqualifying answer. “We only keep metadata.” A schema with your column names, customer identifiers and product codes is a description of your business.
4. Access rights cannot be bypassed
Who can see which record is enforced by the data store, at the layer every query passes through, not by a filter in application code that a bug, a prompt or a new integration can get around. An agent inherits the rights of the person it acts for, and nothing more.
How to verify. Use an account with restricted rights. Ask the question the restriction is meant to block, phrased three ways. Then try every other path the vendor offers: API, export, report.
Disqualifying answer. “The agent is instructed not to return that data.” An instruction is a request, not a permission.
5. Every action waits for a named person
The software proposes. A named person approves, with a timestamp, and only then does anything change in a system of record.
How to verify. Ask what happens between the proposal and the write, and who sees it first. Ask how many proposals one person is expected to approve per day, and judge whether that is a real review.
Disqualifying answer. “Human in the loop is configurable.” Someone approving several hundred machine proposals a day is not reviewing them.[4]
6. The trail can be replayed
A record of what the model said is a transcript. You need a trail from which the decision can be reconstructed: which records were read, which rule applied, which plan ran, who approved it, in an order that cannot be rewritten. The regulator will ask about the exceptional case, precisely where a statistical system answers with the same confidence as everywhere else.[5]
How to verify. Pick a decision from last month. Ask for its result to be reproduced from the trail alone, on the same data, without the model. If the figure changes, the trail is not evidence.
Disqualifying answer. “We log every prompt and completion.” A log of what was said is not a record of what was done.
7. If the vendor disappears, you keep operating
The software keeps working without the vendor, on your infrastructure, run by your operations team. The licence does not expire into a locked screen. The formats it writes can be read without it.
How to verify. Ask for the runbook your team would follow without the vendor. Then read the termination clause.
Disqualifying answer. “We offer source code escrow.” Escrow means you might one day rebuild a system you never learned to run.
8. Nothing is shared between customers
One deployment, one model of the business, one organisation. No shared tenant, no shared index, no pooled embeddings, no model trained on your data and served to a competitor. Sovereignty covers every layer, from hardware and model weights to data, ontology and decisions; one shared layer makes the whole stack shared.[6]
How to verify. Ask whether anything derived from your data leaves the deployment, including telemetry, evaluation samples and anonymised usage data. Ask who else runs the model weights in your deployment, and whether your data ever trained them.
Disqualifying answer. “Your data is logically isolated.” Logical isolation is an application-level promise. Physical separation is something you can inspect.
This is the list we ask to be measured against. Monarch runs inside your infrastructure, under your accounts, your keys and your jurisdiction. Galahad hosts none of your data. Each deployment serves one organisation, with its own ontology. Run the eight tests from your own network. See it on your data.