Privacy & security

A security review checklist for an AI inference vendor

A vendor review for an AI service tends to reuse the questionnaire written for a SaaS tool: encryption, retention, access control, certifications. Those still matter. But an AI service has risks the questionnaire does not reach, because the thing processing your data is a model that reads instructions in the data, and the files that model came from are a supply chain of their own. This checklist adds the questions that reach them. Each one comes with what a good answer looks like, so you can tell a considered design from a reassurance.

7 min read Updated October 21, 2026

How to use it

The questions are grouped by what they protect: your data, the actions a model could take, the model files themselves, and the platform around them. For each, the second column is the answer a well-designed system can give. An answer that is a policy ("we do not do that") is weaker than an answer that is a structure ("there is no path by which that could happen"), and the difference is worth pressing on. The UK National Cyber Security Centre’s guidelines for secure AI development, written with international partners, organise the same ground by lifecycle phase: design, development, deployment, operation. The questions below are the ones a buyer can ask from the outside.

Your data

How long is content kept after a job finishes?: A fixed number of days, stated in writing, with deletion automatic rather than on request.
Is it ever used to train a model?: "Never," in the terms, with no plan-dependent exception.
Do prompts or results appear in logs?: No. Logs carry identifiers, counts, statuses and error categories.
How is one customer kept apart from another?: A key per customer for stored content, so that reaching another customer’s files yields nothing readable. Access rules alone are a policy.
Where is it processed, and can I set a boundary?: Named regions, and a per-customer boundary the scheduler enforces rather than prefers.
What does a machine processing my job hold?: The one job it is running and a short-lived key for that job. Not other customers’ keys, not the rest of your data.

What the model can do

This is the group a SaaS questionnaire misses. The model will read instructions in your data, and no filter stops that reliably. What matters is what an instruction can reach.

Can the model make a call?: No. A model step produces data. If the pipeline calls out, a separate step does it, to a destination declared before the run.
Who chooses the destination of a call?: The customer, in the pipeline definition, in advance. Never the model at run time.
Where do the credentials for a call sit?: With the customer’s endpoint. The platform signs the request; the model never sees a key and the sender holds a signature, not the secret.
Is the plan fixed before the run?: Yes. Every step, destination and output shape is known from the definition, and nothing in the data can add a step.
Is every output validated before anything reads it?: Against a schema the customer declared, with a stated action on failure.
Can a person be put in front of a consequential step?: Yes, as a step in the pipeline that waits, with the resume authenticated.
Does the platform make outbound requests on my behalf, and how are they guarded?: Only to endpoints registered in advance, over HTTPS, with private address ranges refused at connection time and redirects not followed.

The model files

In what format are weights loaded?: One that cannot carry code. Safetensors, not pickle-format checkpoints.
Is a model pinned to a specific revision?: Yes, by commit, with the files mirrored into the vendor’s own storage. A branch reference means the model can change without anyone deciding it should.
What happens when a model is updated?: A new revision is a deliberate change with a record. Ask whether you are told.
Do you vet models for backdoors?: The honest answer is that nobody can. A good vendor says so and explains what bounds the damage instead.

The platform around it

Is the operator surface separate from the customer surface?: Separate processes on separate addresses, with the operator one behind a zero-trust gateway. A shared process is a shared blast radius.
Does the component that holds keys and the database ever dial a customer URL?: No. Outbound calls leave from a component that holds neither.
What happens when the key store is unreachable?: The service refuses to process content until it is back. It never falls back to plaintext.
Which parts can I read?: A list of what is open source, with the parts that handle data among them.
How are dependencies and images scanned, and what blocks a release?: A stated gate: reachable vulnerabilities in the code and the base image block, with the rest tracked.
Who do I contact, and what are you obliged to tell me?: A security contact and a breach notification commitment in the terms.

What nobody can promise

Three answers should make you trust a vendor less if they claim otherwise.

That the model will not follow an injected instruction. It will, sometimes. The defence is in what the output can reach, not in the model.
That a model has no backdoor. There is no test for one. The defence is that a triggered model can give a wrong answer and nothing more.
That your data is encrypted while the model reads it. It is in memory on a machine, in plaintext, for the duration of the job. What can be promised is which machine, who controls it, what else it holds, and what happens to the data afterwards.

How Otium answers

Your data: Content is deleted 30 days after a job finishes, never used for training, kept out of logs, and encrypted with a key per customer. A machine holds the one job it is running and a short-lived key for it. A per-customer residency boundary is enforced by the scheduler.
What the model can do: A model step’s output is data, validated against the step’s schema, going to the steps that read it. Tool steps call one declared operation at one endpoint registered in advance, in a request the platform signs at the moment it is leased; the sender holds a signature, never the key, and the control plane never dials. Private address ranges are refused after DNS resolution and redirects are not followed. A human or external step parks the run and resumes through an authenticated call.
The model files: A model is imported from the Hugging Face Hub only from the organisation of the lab that trained it, quantizations included, at a pinned commit. It is mirrored into Otium’s own storage under that revision and loaded from there as safetensors only, so a model file can never run code. Otium does not vet models for backdoors, because nothing can.
The platform: The operator surface is a separate process on a separate port behind a zero-trust gateway. The scheduler, which holds the key store and the database, makes no outbound calls to customers. When the key store is unreachable the service returns errors on content paths rather than falling back to plaintext. Reachable vulnerabilities in the code and the base image block a release. The open-source page lists what can be read.

Frequently asked questions

Which of these questions matter most?

If you ask only three: whether the model can make a call, whether content is ever trained on, and whether the model files are pinned and loaded in a code-free format. Those three separate a system designed for this from one that bolted an API onto a model.

Is a certification (SOC 2, ISO 27001) a substitute for these?

No. A certification covers the organisation’s controls, and it is worth having. It does not say whether the model can make a call or where the credentials sit, because the frameworks were written before those questions existed.

What if the vendor answers "it depends on the plan"?

Then the answer for your plan is the only one that counts, and the default should be the protective setting. A protection that must be switched on is one that will be off somewhere.

An injected instruction can only do what the system around the model allows. Where the three ingredients of an attack live in an agent loop and a fixed graph.

Where the secrets go: least privilege for AI tool calls

A model step should hold the authority its one task needs and no more, as a CI job does. Where credentials sit in an agent, a tool server and a fixed graph.

Model supply chain security: pickle, safetensors, pinned revisions and backdoors

A model file can run code when it loads, a repository can change under you, and weights can carry a trigger. What stops each attack, and what nothing stops yet.

Privacy in AI inference: retention, training, and isolation

Is your data retained, trained on, or readable by someone else? The privacy questions that matter in AI inference, and how open models change the answers.

Data residency for AI inference: pick a boundary, not a region

Compliance obligations are jurisdictional, not regional. Why a residency boundary is the right primitive for AI inference, and how a lock must behave.