Treating AI Agents as Third Parties in Your Vendor Risk Program

Most organizations have a functioning vendor risk management program and an AI deployment process, and the two rarely touch. AI tools get evaluated on capability and cost, procured quickly because a team wants to move, and connected to internal systems without passing through the vendor due diligence assessment that a conventional SaaS platform would face.

The result is a category of third party with deep system access and no corresponding risk documentation. This article covers how to close that gap using the program you already have.

Why AI Vendors Are Not a New Category

There is a tendency to treat AI vendors as something requiring an entirely new evaluation framework. In most respects they are not. An AI vendor is a third party that processes your data, holds access to your environment, and depends on its own third parties to deliver its service. That is a description of vendor risk, and your existing discipline applies.

What differs is scope of action. A conventional SaaS platform stores and serves data. An AI agent takes actions inside your environment. That difference should raise the risk tier, not create a separate program.

Risk Tiering for AI Systems

Apply the same tiering logic you use elsewhere, driven by three questions. What data does this system access? What systems can it reach? What actions can it take without human approval?

An AI tool summarizing publicly available research is a Low Risk Vendor. An agent with write access to a production database, the ability to initiate transactions, or access to customer information is a critical vendor by any reasonable definition and should receive the corresponding level of scrutiny before onboarding and annually thereafter.

What to Ask During Due Diligence

Security Attestation

Request the vendor's most recent SOC 2 Type 2 report or equivalent attestation and read the scope section carefully. AI providers sometimes hold an attestation covering their platform infrastructure while the specific AI service you are procuring sits outside the described boundary.

Data Handling and Retention

What happens to the data you send. Whether it is retained, for how long, and where. Whether your inputs are used to train or improve models. Whether data can be segregated or deleted on request. For organizations subject to GLBA or NYDFS Part 500, these answers determine whether the arrangement is even permissible under your existing obligations.

Model Provenance and Dependencies

Which underlying models the service uses, whether they are the vendor's own or licensed from another provider, and what happens if that upstream relationship changes. A vendor that switches its underlying model has materially changed the service you assessed, and you may not be notified unless the contract requires it.

Fourth Parties

Agentic services typically depend on external tools, plugins, libraries, and APIs. Those are fourth parties in your environment, reached through a vendor you assessed rather than one you selected. Ask what the toolchain includes and how the vendor manages security across it. This is frequently the least documented area and one of the more consequential.

Contractual Protections Worth Negotiating

Minimum security standards the vendor is required to maintain. Notification obligations in the event of an incident affecting your data or operations, with a specific timeframe and a named contact rather than a general process. The right to receive security audit results on request. Restrictions on data use, including whether your data may be used for model training. Notification if the underlying model or material dependencies change. Termination rights if the vendor experiences a material security incident or fails to meet security requirements.

These provisions are generally negotiable at contracting and considerably harder to obtain afterward. Many organizations accept vendor standard terms for AI services because the procurement moved quickly, and discover the gap during an audit or an incident.

Ongoing Monitoring

An annual vendor risk assessment for every critical and high risk AI vendor, covering updated attestation reports, incident history, any material changes to the service, and whether the access originally granted is still appropriate to current use.

AI services change faster than most vendor categories. A capability set assessed twelve months ago may bear limited resemblance to what the service does today. Reassessment on a fixed annual cycle is a reasonable floor, with an additional trigger when the vendor announces significant functional changes.

Documentation

A vendor risk program that operates without documentation will not satisfy an auditor, an enterprise customer security review, a sponsor bank, or a regulatory examiner. Maintain an inventory of AI vendors with risk tier classifications, records of what was reviewed and when, contractual security requirements for critical and high risk vendors, annual review outcomes, and an escalation record for any issues identified and how they were resolved.

This article is provided for general information and does not constitute legal advice. Regulatory requirements, compliance dates, examiner priorities, and enforcement posture change frequently. Verify current requirements against primary agency sources and your legal counsel before acting on anything described here.