The vendor’s deck answers the question the vendor chose. A security architect asks a different one: what does this software need from outside my network, and what leaves through it? Put the eight requirements below to the vendor in writing, before the demonstration. Each comes with the test you run yourself and the answer that ends the meeting.
1. It runs under your accounts, your keys and your jurisdiction
The software installs in infrastructure you control, authenticates against your identity provider and stores under keys you issued. No vendor control plane is needed to start, stay licensed or keep working; if one exists, you can switch it off and the software keeps running.
How you verify it. Block the vendor’s domains at the firewall and restart the software. Ask for the list of every host it will ever try to reach, then read your egress logs after a week in production and compare.
The wrong answer. “The control plane is hosted in an EU region.” Legal geography defeats physical geography: data held under American jurisdiction is reachable whatever datacentre it sits in.[1] The CLOUD Act obliges a provider subject to United States jurisdiction to produce data in its possession, custody or control regardless of where that data is stored.[2]
2. It runs fully closed, and you can prove it
A deployment you can run today with no outside model and no outside network, against a model you host yourself. An intelligence layer that presupposes a connection to a datacentre under foreign jurisdiction is a hostage, and it will be treated as one at precisely the moment it matters.[3]
How you verify it. Deploy in a network segment with no default route. Run the demonstration there. If it needs an exception, you have your answer.
The wrong answer. “Our model endpoint is private and encrypted in transit.” Encryption describes the pipe. The question was whether the pipe exists.
3. No copy of your data exists that you did not decide to make
Every extract, index, cache and embedding store is a copy, and a copy has three properties you must know: where it sits, who reads it, and when it was taken. A vendor that holds copies outside your perimeter holds your data.
How you verify it. Ask for the inventory of every place the software persists anything derived from your data. Then look at the volumes yourself and compare.
The wrong answer. “We only keep metadata.” A schema with your column names, your customer identifiers and your product codes is a description of your business.
4. Access rights live where they cannot be bypassed
Who can see which record is a rule of the store, enforced at the layer every query passes through, and never a filter in application code that a bug, a prompt or a new integration can walk around. An agent inherits the rights of the person it acts for, and nothing more.
How you verify it. Take an account with restricted rights. Put the question the restriction exists to block, in three phrasings. Then put it through every second path the vendor offers: the API, the export, the report.
The wrong answer. “The agent is instructed not to return that data.” An instruction is a request. A permission is a fact.
5. Every action waits for a named human
The software proposes. A person, named and timestamped, approves, and only then does anything change in a system of record.
How you verify it. Ask what happens between the proposal and the write, and who sees it first. Ask how many proposals one approver is expected to clear in a day, and decide whether that is a review.
The wrong answer. “Human in the loop is configurable.” A human validating several hundred machine proposals in a working day validates nothing; he is a signature apparatus attached to a process he cannot examine.[4]
6. The trail can be re-run
A trail that records what the model said is a transcript. What you need is 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 nobody can rewrite afterwards. Sovereignty reveals itself in the exception, and the exception is the case the regulator will ask about, the one a statistical system answers in the same confident register as everything else.[5]
How you verify it. Pick a decision from last month. Ask for its answer to be reproduced from the trail alone, on the same data, without the model. If the figure moves, the trail is a story.
The wrong answer. “We log every prompt and completion.” A log of what was said is no record of what was done.
7. If the vendor disappears, you operate what you installed
The software keeps working with no vendor, on your infrastructure, under your operations team. A licence does not expire into a locked screen. The formats it writes are ones you can read without it.
How you verify it. Ask for the runbook your team would follow with the vendor gone. Then read the termination clause.
The wrong answer. “We offer escrow.” Source code in escrow is a promise that you will one day rebuild a thing 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 improved on your data and served to your competitor. Sovereignty is a stack: silicon, weights, data, ontology, decision, and a single shared layer makes the entire stack shared.[6]
How you verify it. Ask whether anything derived from your data leaves the deployment, including telemetry, evaluation samples and anonymised usage. Ask who else runs the weights the deployment uses, and whether your data ever touched them.
The wrong answer. “Your data is logically isolated.” Logical isolation is an application promise. Separation is a fact you can inspect.
This is the list we want to be measured against. Monarch installs inside your infrastructure, under your accounts, your keys and your jurisdiction. We operate no hosting for your data. It is never shared: one deployment, one ontology, one organisation. Run the eight tests from your own network. See it on your data.