Get started
AI securityAI securityTrustEvidenceGovernance

How to verify an AI vendor before you trust it with your data

Adam Cowles2026-09-19T14:00:00.000Z4 min read
A vendor claim resolving into a checkable record under inspection, cyan and teal over near-black

The right question to ask an AI vendor is not "are you secure". It is "what can you prove, and can I check it myself".

Most AI vendor security pages ask for trust and offer a badge in return. If the software will run inside your infrastructure, hold your credentials, or take actions on your systems, trust is not the thing to give. Verification is. Here are six checks you can run before you hand anything over, and what a trustworthy answer to each looks like.

1. Where do your secrets live, and who can read them

Ask exactly where credentials are stored, how they are encrypted at rest, and whether any log line, error report or support tool could print them. A good answer names the store and the encryption, and can show that no code path emits a secret in plaintext. A weak answer is "they are encrypted" with no further detail. The strongest position of all belongs to a self-hosted vendor whose software keeps your secrets on your own box, because there is simply less to trust when the secrets never leave.

2. What leaves your box, and did you ask it to

Every outbound connection is a decision you should get to make. Ask for the full list of what the software sends out: analytics, crash reports, licence checks, model calls, update pings, and exactly what data rides with each. A trustworthy vendor can name every destination without hesitating. The strongest answer is a system that phones home for nothing by default, so anything leaving your network is there because you switched it on.

3. Can you read the code, or only the marketing

"Audit us" means little if the code is closed. Ask whether the parts that actually carry the risk, credential handling, network egress, the boundaries between one tenant and another, are open to inspection. If they are, you can point your own tools, including your own AI, at the repositories and check the claims yourself instead of believing them. A vendor that hands you the source is inviting exactly the scrutiny a badge is designed to avoid.

4. Is there a gate before the action, or only a log after it

A system that records "here is what I did" after the fact can describe a bad action, it cannot stop one. Ask whether a consequential action is checked against a rule before it runs, and whether a required human approval waits with a real deadline rather than quietly auto-approving on a timeout. This is the difference between oversight and a post-mortem, and for an autonomous agent that can act on your systems it is the whole game. Quox puts every consequential action behind a policy and approval gate for this reason.

5. Can you prove the record was not changed

A log you can quietly edit is not evidence. Ask whether each action is written as a signed record on an append-only chain, so a specific decision can be produced weeks later with proof it was not altered (WARD is how Quox does this). Be precise about what this buys you: tamper-evident is not tamper-proof. It will not stop a bad decision being made, and a signed record of a bad decision is still a bad decision. What it gives you is the truth of what actually happened, which is the thing every review turns out to need.

6. Can you run the checks yourself, on your own instance

The best answer to "can I trust this" is "run the tests and see for yourself". Ask whether the platform ships a verification suite you can run on your own deployment, on your own schedule, with results you keep. A vendor that lets you prove it repeatedly, on your terms, is making a different kind of promise than one that asks you to take a point-in-time certificate on faith.

The shift that matters

Every one of these checks turns a question of trust into a question of evidence. You are not asking the vendor to be trustworthy, you are asking them to make their claims checkable, and then you check. A vendor who welcomes that is telling you something a badge never can.

None of this is legal or security advice, and no single control makes a system safe. But the direction is the point: prefer what you can verify over what you are asked to believe. It is the standard we hold Quox to, and the one we think you should hold every AI vendor to, us included.