Blog

Seven questions to ask any AI vendor


AI vendors are selling to your business the same way every software vendor has: quickly, enthusiastically, and with a security story that falls apart two questions deep. The difference is that regulators are already updating the rulebook. In September 2026, the OCC, Federal Reserve, FDIC, and NCUA proposed revised third-party risk management guidance (comments due November 16, 2026), and NCUA’s due diligence letters, 01-CU-20 from 2001 and 07-CU-13 from 2007, have set the baseline expectations for years: vendor risk is your risk, and “the vendor told us it’s secure” is not diligence.

You don’t need to be a credit union to benefit from that discipline. These seven questions come from the checklist we use when assessing AI vendors, and an AI vendor that can’t answer them isn’t ready for your data.

1. What identity does the agent run under?

Its own service identity, or a borrowed user login? What’s the maximum reach of those credentials? The security agencies of five countries put privileges first in their agentic AI guidance for a reason: an agent’s blast radius is the permissions you granted it, full stop. A vendor that can’t name the identity and scope hasn’t done the basic work.

2. Where is authorization enforced?

In your infrastructure, in a policy engine, or in the prompt? “The agent is instructed not to” is not a control. Tool access should be denied by default and allowed deliberately, with task-bound tokens and session limits, not a polite paragraph in a system prompt.

3. What are the data boundaries?

What exactly can it read? Does content from outside your company enter its context, emails, web pages, attachments? Can it send data out, and to where? Is your customers’ personal information excluded or masked by design? Get the boundaries in writing, as a list, not as adjectives.

4. How does it handle prompt injection?

Untrusted content is the delivery mechanism for most AI attacks, so ask directly: how is outside content handled? Has the product been tested against indirect injection specifically, by people who don’t work for the vendor? Vague answers about “AI guards” are a red flag; named mechanisms and test results are not.

5. What requires human approval?

Which actions stop and wait for a person: payments, deletions, data sharing, messages sent under your name? Is every action, input, and output logged, and who at the vendor owns incident response when the AI misbehaves? An AI vendor without a human-approval story is selling you an unmonitored employee.

6. Which models, where, and who trains on what?

Which models run the product, in what region, and is there a contractual commitment against training on your data? Ask about subprocessors and version changes too. The model behind your vendor’s product can change overnight, and behaviors change with it.

7. Can they map to a framework?

NIST’s AI Risk Management Framework and ISO 42001, the certifiable AI management system standard, are becoming the reference points in procurement, the same way SOC 2 did for SaaS. A vendor that can map their controls to a framework will support your auditors. One that can’t will leave you holding the risk with nothing on paper.

The one-line version

Every question above is a version of one question: when this system misbehaves or gets manipulated, what stops it, and who is accountable? If a vendor answers with features instead of controls, keep shopping. And if you want help pressing a vendor on any of this, this assessment is a standard part of the work we do before any AI goes live on a client’s data.

Want this handled for you?

This is exactly the kind of work we handle in Managed AI Services.

Explore Managed AI Services