You bought the AI. You still own the risk.

The way enterprises get AI changed faster than the way they vet it. In Menlo Ventures’ 2025 enterprise survey, 76% of AI use cases were purchased rather than built internally, up from 53% a year earlier, against enterprise generative-AI spend that tripled to $37 billion. The build-versus-buy debate is settling, decisively, on buy.

Buying transferred the build. It did not transfer the accountability.

What that looks like when it fails

In August 2025, attackers used stolen OAuth tokens belonging to Drift, an AI chat agent, to export data from victims’ Salesforce instances over a ten-day window, according to Google’s Threat Intelligence Group. The attackers then searched the exported data for AWS access keys and Snowflake tokens, turning one vendor’s compromise into a foothold on victims’ broader infrastructure. FINRA’s alert to member firms on the AI supply-chain attack put the impact at more than 700 organizations.

Nobody at those 700+ organizations wrote insecure code. They approved an integration. The vendor’s agent held broad, long-lived access to their CRM, and the vendor’s token store became the perimeter of 700 companies at once. That is the specific new thing about buying AI: the product is an agent with credentials to your systems, which makes vendor risk an access-engineering problem.

The accountability is moving toward you, in writing

The legal direction of travel is consistent. California’s AB 316 forecloses the “the AI did it” argument: it is not a defense that the artificial intelligence autonomously caused the harm. Texas requires healthcare providers to disclose their AI use to patients, regardless of who built the model. Insurance regulators under the NAIC’s model bulletin expect written AI programs that cover third-party systems, meaning the insurer answers for the vendor’s model in a market-conduct exam. The buyer holds the liability while the vendor holds the design; diligence is the only tool that closes that gap before the contract does or doesn’t.

Some of what’s marketed won’t survive contact anyway. Gartner’s read on “agent washing” is that a large share of agentic vendors are rebranded assistants and RPA, which makes capability verification part of the same diligence pass as security.

Diligence questions that predict trouble

The questionnaire that matters is short, technical, and answerable in a live session rather than a returned PDF:

1. Access: exactly which scopes and permissions does the integration request, and will the vendor run with less? A chat widget that wants org-wide CRM export scope is the Drift lesson.
2. Revocation: how fast can you, unilaterally, cut its access, and have you tested that path?
3. Tokens: how are credentials stored, rotated, and bounded? Long-lived tokens in a vendor’s store were the entire Drift blast radius.
4. Logs: what per-action records exist, and can they land in your monitoring, so an incident in their product is visible in your tooling?
5. Data: is training on your data off by default and by contract, and what’s the retention?
6. Evidence: evaluation results for the claimed capability, on something resembling your workload.
7. Incidents: notification SLA, and what they actually did in their last one. Drift’s tokens were revoked twelve days after the exports began.
8. Exit: can you disable the integration in one step, without breaking the systems it touched?

None of these questions requires a security team the size of Google’s. They require someone senior enough to insist on live answers and technical enough to evaluate them, with accountability for the resulting inventory of vendor-AI access. In many mid-market companies no one holds that role, so the questionnaire stays a PDF and the OAuth grant stays org-wide.

Standing that function up, an owner for vendor-AI governance with the authority to say “smaller scope or no deal,” is the kind of gap fractional platform leadership is built for: senior review where the risk concentrates, without the full-time headcount.