AI vendor security questions: what a good answer sounds like

The standard questionnaire will not tell you what you need. SOC 2 covers how a vendor runs their own company, not what the agent they build for you is able to do when it is talked into the wrong action. The questions that separate a serious builder are about permissions, credentials, and what capability they gave up to get there.

JarvisBitz

When a company commissions a custom AI agent, procurement usually sends the vendor the same security questionnaire it sends everyone else. Parminder Singh of DeepInspect names the problem in one line: "Most AI vendor security questionnaires are SOC 2 templates with two AI questions tacked on." We are on the receiving end of these regularly, and he is right. They are answerable, and answering them proves almost nothing about the thing being bought.

The mismatch is not carelessness, it is a category error. SOC 2 describes how a vendor runs their own company: who can reach their laptops, how they onboard staff, whether they rotate their own keys. That is worth knowing. It says nothing about the system they are about to build inside your environment, holding your credentials, reading content written by strangers. Those are two different objects, and only one of them is going to be talked into issuing a refund.

What follows is the shorter list we would want asked of us, with what a serious answer sounds like and the answer that should end the conversation. It is written from the build side deliberately: you can score a vendor far better when you know what a good answer looks like than when you are collecting yes and no.

What can this agent do if it is talked into the wrong thing?

Not whether it can be, but what happens when it is. Assume the model has been fooled and ask what the blast radius is at that moment.

A good answer is a short, specific list of consequential actions and the statement that those permissions are fixed before the agent reads anything untrusted, rather than decided afterwards based on what it read. It usually comes with a description of how reading is separated from acting.

The answer that should worry you is any version of "we filter malicious inputs". We have written at length on why input filtering does not hold. A vendor leading with it is describing a product they bought, not a system they designed.

Where do the credentials actually live?

Every agent that touches a real system holds some form of access. The question is what holds it and how narrow it is.

A good answer puts credentials in a service the vendor controls and exposes a small set of named operations to the model, so the model receives a menu rather than a connection. Ask what happens if the model asks for something not on the menu; the answer should be that it cannot express the request at all.

Worrying: the model has database access, or an API token with broad scope, with safety resting on it choosing sensible queries. That design is one convincing paragraph of injected text away from a very bad afternoon.

What did you give up to make it safe?

This is the question that most reliably separates people who have built these from people who have read about them, because constraining an agent always costs capability.

A good answer names the trade in concrete terms: which tasks the agent will refuse or escalate, roughly how often, and what the user sees when it does. Published work on constrained agent designs puts real numbers on this cost, which we go through in the piece on prompt injection. What matters in a vendor conversation is simply whether they can talk in that register at all, or whether the question surprises them.

Worrying: "there is no performance impact". Either they have not measured, or the constraint is not doing anything.

Which actions need a human, and how did you decide?

The method matters more than the answer. You are testing whether the list was reasoned or copied.

A good answer tiers actions by whether they can be undone and how far the damage reaches, gates the irreversible ones, and deliberately leaves the rest ungated so the automation is still worth having. Ask them to walk you through two examples from your own workflow, one gated and one not, and to say why each landed where it did.

Worrying: "every action requires approval", which means nobody has thought about throughput and the reviewers will stop reading within a week. Equally worrying: "everything is logged". Logging is how you find out afterwards. It is not a control.

What happens when a tool returns something unexpected?

Agents read the results of their own tool calls, and those results routinely contain content the vendor did not write: a support ticket, a scraped page, a document someone uploaded.

A good answer treats tool output as data to evaluate rather than instructions to follow, and can say what stops a returned string from redirecting the agent's next step. If they are using MCP or connecting to another party's agent, ask specifically what review that third party's server received, because installing it means running someone else's code against your credentials.

How will we know it works before it touches anything real?

A good answer describes a staged rollout: the agent runs against real inputs with its writes going nowhere, its proposed actions compared against what actually happened, then a limited share of live traffic with spend caps and a way to stop it quickly. Ask what the promotion criteria are between stages. If there are none, the stages are decoration.

Worrying: a demo, and a plan to watch it closely after launch.

How to use this

Send it before the proposal, not after. Vendors write proposals to the questions they expect, and these questions change what gets proposed. You are not looking for perfect answers. Prompt injection sits at LLM01:2025, first in the OWASP Top 10 for LLM Applications, and nobody has solved it. You are looking for a vendor who describes the trade accurately rather than one who claims not to be making it.

• Ask what the agent can do when fooled, not whether it can be fooled.
• Make them locate the credentials and describe the operation menu.
• Make them quantify the capability they traded away.
• Test whether the approval list was reasoned or copied.
• Ask what stops tool output from steering the agent.
• Get the promotion criteria between rollout stages in writing.

If you would rather not run this alone, our procurement pack contains the documentation these questions ask for, and we are happy to be on the receiving end of them. If you are mid evaluation and want a second opinion on the answers you have already collected, a free AI audit is the fastest way to get one.

Related reading

Build vs buy an AI agent: the arithmetic that decides it

You cannot answer it until you know how many billable actions one conversation takes, because every pricing model now meters actions rather than conversations. That makes your bill a consequence of how the agent is designed, and it means the same use case can land either side of the line depending on choices you have not made yet.

What you should own when the AI build ends

The code is the least valuable thing you funded. Name the prompts, the eval set, the embeddings and index configuration, the fine-tuned weights if any, and the infrastructure definition, in usable formats. The eval set matters most, because it is the artifact a successor cannot cheaply rebuild.

Can an AI project be fixed price? Only after discovery

Not the build, and yes the discovery. Fixed price requires knowing what correct looks like before work starts, and on an AI project that knowledge is the output of the first phase rather than an input to it. Fix the price of discovery, and let it produce the evidence a build number can stand on.