---
title: "Third-party agent due diligence: the vendor risk framework your governance is missing"
date: 2026-04-16
author: david
excerpt: "88% of organizations reported confirmed or suspected AI agent security incidents in the past year. 91% of AI tools operate without IT approval. The average SaaS application now has at least 10 AI agents associated with it. Yet most governance frameworks focus exclusively on agents you build. Third-party agents, embedded in your SaaS tools, managed by your vendors and chained through partner integrations, operate outside your governance perimeter. This is the due diligence framework for the agents you did not build but are accountable for."
category: strategy
tags:
  - agent governance
  - third-party risk
  - vendor management
  - due diligence
  - supply chain
  - SaaS
  - procurement
  - audit
draft: false
tldr: "Most AI agent governance frameworks address only the agents an organization builds and deploys. Third-party agents, those embedded in SaaS products, managed by vendors or chained through partner integrations, represent the fastest-growing and least-governed category of agent risk. This guide covers why third-party agents are a governance blind spot, the five due diligence dimensions (transparency, controllability, auditability, data handling, incident responsibility), contract provisions for agent governance, ongoing monitoring requirements, supply chain risk for agents that call other agents and a 50-question due diligence questionnaire for evaluating third-party agent vendors."
seo:
  title: "Third-party AI agent due diligence: vendor risk framework and questionnaire"
  description: "A vendor risk management framework for third-party AI agents covering due diligence dimensions, contract provisions, ongoing monitoring, supply chain governance and a 50-question evaluation questionnaire for SaaS-embedded and vendor-managed agents."
faqs:
  - question: "Why are third-party AI agents a governance blind spot?"
    answer: "Third-party agents are embedded directly in SaaS products, CRM systems, HR platforms and productivity tools your organization already uses. They operate inside vendor-managed infrastructure where your governance team has no visibility into agent behavior, data access patterns or decision logic. 91% of AI tools operate without IT approval and the average SaaS application now has at least 10 AI agents associated with it. Your governance perimeter covers the agents you built. It likely misses the agents your vendors deployed."
  - question: "What should a third-party agent due diligence questionnaire cover?"
    answer: "A thorough questionnaire covers five dimensions: transparency (model architecture, training data provenance, decision logic), controllability (configuration options, override mechanisms, kill switches), auditability (logging completeness, audit trail access, evidence export), data handling (data residency, retention policies, training data usage, cross-tenant isolation) and incident responsibility (notification timelines, root cause analysis, remediation obligations). Each dimension should include 8-12 specific questions with verifiable answers."
  - question: "What contract provisions should govern third-party AI agents?"
    answer: "Essential provisions include: no-training clauses prohibiting the vendor from using your data to train models for other customers, audit rights granting access to agent logs and decision trails, SLAs for agent behavior (uptime, accuracy, response time), incident notification within defined timeframes (24-72 hours), liability allocation for agent-caused harm, data deletion obligations on contract termination and decommissioning procedures for agent shutdown."
  - question: "What is supply chain risk for AI agents that call other agents?"
    answer: "Multi-agent supply chains create cascading risk. When your vendor's agent calls another vendor's agent, which calls a third-party API, each hop introduces latency, data exposure and potential failure points. A single agent interaction may traverse three or four vendors, each with different security postures, data handling practices and governance standards. The deploying organization is accountable for the aggregate risk regardless of where each component originated."
  - question: "How often should third-party agent due diligence be updated?"
    answer: "Annual due diligence reviews are insufficient for AI agents. Vendors update agent capabilities, model versions and data handling practices continuously. Trigger-based reassessment should occur when the vendor changes the underlying model, modifies data handling practices, expands agent capabilities or reports a security incident. Continuous monitoring through an observability platform provides ongoing assurance between formal reviews."
---

A mid-size financial services firm completed its annual vendor risk assessment. Every SaaS vendor passed. The assessment covered data encryption, access controls, incident response plans and business continuity. Six months later, the firm's compliance team discovered that four of those vendors had embedded AI agents in their products during the assessment period. One agent in the firm's CRM was summarizing client conversations and feeding the summaries to the vendor's analytics pipeline. Another agent in the HR platform was screening resumes using criteria the firm had never reviewed or approved.

Every vendor had passed the assessment. None of the agents had been assessed.

## The blind spot

Most AI agent governance frameworks address the agents an organization builds and deploys. Risk classification, monitoring, human oversight, audit trails: these controls apply to agents within the governance perimeter. But the fastest-growing category of agents in most enterprises operates outside that perimeter entirely.

:::fact
The average SaaS application now has at least 10 AI agents associated with it. 91% of AI tools operate without IT approval. Gartner predicts 40% of enterprise applications will feature task-specific AI agents by end of 2026, up from under 5% in 2025. The agents your vendors embed in their products are multiplying faster than the agents you build yourself.
:::

Third-party agents arrive through three channels, and each creates a different governance challenge.

### SaaS-embedded agents

Your CRM, HR platform, project management tool and customer support system all ship with AI agents now. These agents summarize conversations, draft responses, classify tickets, score leads and flag anomalies. They operate inside the vendor's infrastructure, process your data and make decisions that affect your operations. You did not build them. You may not have approved them. In many cases, you were not notified when they were activated.

The governance challenge: you cannot inspect what you cannot see. SaaS-embedded agents run inside vendor-managed environments where your security and compliance teams have no instrumentation. Agent behavior, data access patterns and decision logic are opaque.

:::cite{name="Gal Nakash" title="CTO and Co-Founder, Reco" linkedin="https://www.linkedin.com/in/naksec/"}
Unlike a traditional SaaS plugin that sits in a defined scope with static permissions, an AI agent can act autonomously. Organizations track hundreds of connected applications but have thousands of connected AI agents.
:::

### Vendor-managed agents

Some vendors deploy agents as a managed service: the vendor operates the agent, configures its behavior and maintains its infrastructure. Your organization provides data and receives outputs. The agent runs in the vendor's environment, but its decisions affect your customers, employees or operations.

The governance challenge: accountability does not transfer with the infrastructure. If a vendor-managed agent makes a biased hiring recommendation or leaks customer data, your organization faces the regulatory and reputational consequences. The vendor operates the agent. You own the risk.

### Partner integration agents

API-connected agents from partners and third parties interact with your systems through integrations. A payment processor's fraud detection agent, a logistics partner's routing agent or a marketing platform's personalization agent: each operates in its own environment but takes actions that affect your business outcomes.

The governance challenge: integration points create trust boundaries that agents cross without human review. An agent that sends data to a partner's API and receives a decision back has extended your data processing chain beyond your governance perimeter.

## The five due diligence dimensions

Standard vendor risk assessments evaluate security posture, compliance certifications and business continuity. These assessments were designed for software that executes deterministic logic. AI agents are different: they make decisions, generate content, access tools and behave differently depending on context. Due diligence for third-party agents must evaluate five dimensions that standard assessments do not cover.

### Dimension 1: transparency

Can the vendor explain how the agent works?

This is not a request for proprietary model weights. It is a request for operational transparency: what model architecture does the agent use, what data was it trained on, how does it make decisions and what are its known limitations.

**What to ask:**
- What foundation model does the agent use, and what version
- Was the model fine-tuned on customer data? If so, whose data
- What is the agent's decision logic for its primary use case
- What are the agent's known failure modes and error rates
- Does the vendor publish accuracy, precision and recall metrics
- How frequently is the model updated, and are customers notified before updates

**Red flags:** Vendors who cannot describe their model architecture, refuse to disclose training data sources or do not track accuracy metrics lack the transparency required for governance.

### Dimension 2: controllability

Can you control what the agent does?

Controllability means configuration options that let your organization define the agent's scope, override its decisions and shut it down when necessary.

**What to ask:**
- Can the agent be disabled without disabling the entire product
- What configuration options exist for the agent's behavior
- Can your organization define which data the agent can access
- Is there a kill switch that stops agent operations immediately
- Can you restrict the agent to specific use cases or user groups
- What override mechanisms exist for agent decisions

**Red flags:** Agents that cannot be disabled independently, offer no configuration options or lack kill switches create ungovernable dependencies.

### Dimension 3: auditability

Can you verify what the agent did?

Auditability means access to logs, decision trails and evidence that demonstrates how the agent operated and what decisions it made.

**What to ask:**
- Does the agent produce audit logs for every action
- Can your organization access those logs directly
- What format are the logs in, and can they be exported
- How long are logs retained
- Do logs capture inputs, outputs and the decision rationale
- Can logs be provided to external auditors during compliance reviews

**Red flags:** Vendors who do not log agent actions, retain logs for less than your regulatory requirements or restrict log access to vendor personnel only.

### Dimension 4: data handling

What happens to your data?

:::fact
77% of employees who use AI tools paste sensitive business data into them. IBM research shows that shadow AI usage added an average of $670,000 to breach costs. One in five organizations has already experienced a breach linked to shadow AI. The data handling practices of third-party agents are not a theoretical concern.
:::

**What to ask:**
- Will your data be used to train or fine-tune models for other customers
- Where is your data processed and stored
- Is there cross-tenant isolation between your data and other customers' data
- What is the data retention policy for agent inputs and outputs
- Can you request deletion of all data the agent has processed
- Does the agent send data to any sub-processors or third-party services

**Red flags:** Vendors who use customer data for model training without explicit opt-in consent, lack data residency controls or cannot confirm cross-tenant isolation.

### Dimension 5: incident responsibility

Who is responsible when something goes wrong?

:::cite{name="Scott Lane" title="CEO and Founder, Speeki" linkedin="https://www.linkedin.com/in/scott-lane/"}
Each of these components introduces potential risks and the organisation deploying the system is ultimately accountable for the aggregate risk of the whole, regardless of where each component originated.
:::

**What to ask:**
- What is the incident notification timeline for agent-related issues
- Does the vendor provide root cause analysis for agent incidents
- What is the vendor's remediation process and timeline
- Is there a dedicated contact for agent-related incidents
- Does the vendor carry insurance for AI-related liabilities
- What liability does the vendor accept for agent-caused harm

**Red flags:** Vendors with no defined incident notification process, no root cause analysis commitment or contracts that disclaim all liability for agent behavior.

## Contract provisions for agent governance

Due diligence findings must translate into enforceable contract provisions. A vendor that provides satisfactory answers during assessment but lacks contractual commitments can change practices without notice or consequence.

### Essential contract provisions

**No-training clause.** The vendor shall not use customer data, including agent inputs, outputs and interaction data, to train, fine-tune or improve models used for other customers without explicit written consent.

**Audit rights.** The customer shall have the right to audit agent behavior, including access to agent logs, decision trails and configuration records. Audit rights shall extend to the customer's designated third-party auditors.

**Behavioral SLAs.** The contract shall define measurable performance standards for agent behavior: accuracy thresholds, response time limits, error rate ceilings and availability targets. Breach of behavioral SLAs shall trigger remediation obligations and, for sustained breaches, termination rights.

**Incident notification.** The vendor shall notify the customer of agent-related incidents within 24-72 hours of detection. Notification shall include the nature of the incident, affected data, initial impact assessment and remediation plan.

**Liability allocation.** The contract shall allocate liability for agent-caused harm proportional to each party's control over the agent's behavior. Vendors who retain full control over agent configuration and operation should accept proportional liability for agent failures.

**Data deletion.** On contract termination, the vendor shall delete all customer data processed by the agent, including any derived data, embeddings or model adaptations, within a defined period. The vendor shall certify deletion in writing.

**Change notification.** The vendor shall notify the customer before making material changes to the agent's model, capabilities, data handling practices or sub-processor relationships. Material changes shall require customer acknowledgment before taking effect.

**Decommissioning obligations.** The contract shall define decommissioning procedures: how the agent is shut down, how data is returned or deleted, what transition support the vendor provides and the timeline for complete decommissioning.

### Provisions for regulated industries

Organizations in regulated industries should add provisions specific to their regulatory requirements:

- **Financial services:** SR 11-7 validation rights, examiner access to agent documentation and compliance with [applicable regulatory frameworks](/blog/ai-agent-governance-financial-services)
- **Healthcare:** HIPAA business associate agreement covering agent data processing, PHI handling controls and breach notification within HIPAA timelines
- **Government:** Data sovereignty requirements, prohibition on foreign AI systems where applicable and compliance with [public sector governance mandates](/blog/ai-agent-governance-government)
- **Legal:** Privilege preservation commitments, no-training clauses covering privileged data and compliance with [professional conduct obligations](/blog/ai-agent-governance-legal)

## Ongoing monitoring requirements

Due diligence is not a point-in-time activity. Third-party agents change between assessment cycles. Vendors update models, expand capabilities, modify data handling practices and add sub-processors. Governance that relies solely on annual assessments governs a snapshot, not a system.

### Continuous monitoring framework

**Behavioral monitoring.** Track the outputs and actions of third-party agents in your environment. An [observability platform](/platform/observer) that monitors agent behavior across both internal and third-party agents provides a unified view of your agent portfolio.

**Configuration change detection.** Monitor for changes in how third-party agents operate. When a vendor updates the agent's model or capabilities, your governance team should be notified and the change should trigger reassessment.

**Data flow monitoring.** Track what data third-party agents access and where they send it. Data flow monitoring identifies when agents access data outside their authorized scope or transmit data to unexpected destinations.

**Performance tracking.** Monitor third-party agent performance against contractual SLAs. Accuracy degradation, increased error rates or response time increases may indicate model drift or infrastructure issues.

### Reassessment triggers

Annual reviews provide baseline assurance. Trigger-based reassessment catches changes between cycles:

- **Model change:** The vendor updates the foundation model or fine-tuning
- **Capability expansion:** The agent gains new features, tool access or data sources
- **Data handling change:** The vendor modifies data processing, storage or retention practices
- **Incident:** The vendor reports an agent-related security or compliance incident
- **Regulatory change:** New regulations affect the agent's risk classification or compliance requirements
- **Sub-processor change:** The vendor adds or changes sub-processors in the agent's data processing chain

## Supply chain risk: agents that call agents

The most complex third-party agent risk emerges when agents call other agents. A vendor's agent that uses a tool API, which is itself powered by another vendor's agent, creates a multi-hop supply chain where risk compounds at each step.

:::fact
Only 24.4% of organizations have full visibility into which AI agents are communicating with each other. 80% of IT professionals have witnessed AI agents perform unauthorized or unexpected actions. The agent supply chain is growing faster than the visibility infrastructure required to govern it.
:::

### The chain of risk

Consider a common scenario: your customer service agent (built internally) calls a sentiment analysis API (Vendor A), which uses a language model (Vendor B), which was fine-tuned on data processed by a data labeling service (Vendor C). A single customer interaction traverses four organizations with four different security postures, data handling practices and governance standards.

Each hop in the chain introduces:

- **Latency risk:** downstream failures cascade upward, so if Vendor C's data labeling introduced bias, Vendor B's model inherits it, Vendor A's API propagates it and your agent acts on it
- **Data exposure:** customer data flows through multiple vendors, and each vendor's data handling practices apply to the data they receive; a no-training clause with Vendor A does not bind Vendor B or C
- **Accountability gaps:** when something goes wrong, tracing the root cause through a multi-vendor chain requires cooperation from every vendor in the chain; if any vendor lacks logging or refuses to cooperate, the chain breaks

### Governing the supply chain

**Map the chain.** For every third-party agent, document the complete supply chain: which models, APIs, data sources and sub-processors the agent depends on. Require vendors to disclose their agent supply chain as part of due diligence.

**Require flow-down provisions.** Contract provisions for agent governance should flow down to sub-processors. A no-training clause that binds your vendor but not their model provider leaves a gap in the chain.

**Monitor chain changes.** Vendors change sub-processors. When a vendor switches model providers or adds a new API dependency, the supply chain risk profile changes. Change notification provisions should cover sub-processor changes.

**Limit chain depth.** Where possible, prefer vendors with shorter supply chains. An agent that calls one external API carries less supply chain risk than one that calls five. Supply chain depth should factor into [risk classification](/blog/ai-agent-risk-classification).

Register third-party agents in your [agent registry](/platform/agent-registry) alongside internal agents. A governance framework that tracks only the agents you built covers half the portfolio. The [8 pillars of AI agent governance](/blog/8-pillars-ai-agent-governance) apply to third-party agents with the same rigor as internal ones. The difference is that enforcement requires contracts, not code.

:::subscribe{title="AI governance, in your inbox" cta="Subscribe"}
Weekly analysis on AI agent governance, compliance and runtime risk. No fluff.
:::

## The due diligence questionnaire

The following questionnaire covers the five due diligence dimensions with specific, verifiable questions. Use it as a starting point and adapt to your industry and regulatory requirements. For a comprehensive evaluation framework covering platform capabilities, see the [RFP template for agent governance](/blog/rfp-template-agent-governance).

### Transparency (10 questions)

- What foundation model(s) does the agent use (include model name, version and provider)
- Was the model trained or fine-tuned on customer data (if so, from which data sources and consent mechanisms)
- What is the agent's decision logic for its primary use case (provide a technical description)
- What are the agent's documented error rates, accuracy metrics and known failure modes
- How frequently is the model updated (describe the update cycle and customer notification process)
- Does the agent use retrieval-augmented generation (RAG), listing what data sources it retrieves from
- What prompt engineering or system instructions govern the agent's behavior, and can customers review them
- Does the agent have access to tools or APIs (list all tool integrations and their purposes)
- Has the agent been tested for bias across demographic groups (share testing methodology and results)
- Is the model architecture documented sufficiently for third-party audit

### Controllability (10 questions)

- Can the agent be disabled without disabling the host application
- What configuration options does the customer have for agent behavior
- Can the customer define which data sources the agent can access
- Is there a kill switch that stops agent operations within a defined latency threshold
- Can the agent be restricted to specific user groups, roles or organizational units
- What override mechanisms exist for agent decisions
- Can the customer set output filters or content restrictions on agent responses
- Does the agent respect customer-defined business rules and policies
- Can the customer roll back to a previous agent version if an update causes issues
- Are there rate limits or usage caps the customer can configure

### Auditability (10 questions)

- Does the agent produce audit logs for every action, decision and data access
- Can the customer access agent logs directly through an API or dashboard
- What format are the logs in? Are they compatible with standard SIEM and observability tools
- How long are logs retained? Can retention be extended to meet regulatory requirements
- Do logs capture inputs, outputs, tool calls and decision rationale
- Can logs be exported for external auditor review
- Are logs tamper-evident or immutable
- Does the vendor provide log access for compliance examinations by regulators
- Can the customer reconstruct the full decision path for any specific agent action
- Does the vendor support real-time log streaming for continuous monitoring

### Data handling (10 questions)

- Will customer data be used to train, fine-tune or improve models for other customers
- Where is customer data processed (specify data centers and jurisdictions)
- Is there cross-tenant isolation between customers' data (describe the isolation mechanism)
- What is the data retention policy for agent inputs, outputs and intermediate processing
- Can the customer request deletion of all data the agent has processed, and what is the deletion timeline
- Does the agent send data to sub-processors or third-party services (list all data recipients)
- How is data encrypted in transit and at rest within the agent's processing pipeline
- Does the agent process personal data as defined under GDPR, and if so under what lawful basis
- Are there data loss prevention (DLP) controls within the agent's processing environment
- Does the vendor maintain a data processing agreement (DPA) compliant with applicable regulations

### Incident responsibility (10 questions)

- What is the incident notification timeline for agent-related issues? Specify hours from detection.
- Does the vendor provide root cause analysis for every agent incident? What is the delivery timeline
- What is the vendor's remediation process and expected resolution timeline
- Is there a dedicated contact or team for agent-related incidents
- Does the vendor conduct post-incident reviews and share findings with affected customers
- What liability does the vendor accept for harm caused by agent errors or failures
- Does the vendor carry professional liability or cyber insurance covering AI-related incidents
- Are there penalty provisions for repeated incidents or SLA breaches
- How does the vendor handle incidents caused by sub-processors in the agent supply chain
- Does the vendor participate in coordinated disclosure for vulnerabilities affecting the agent

## From assessment to governance

A completed questionnaire is a snapshot. Governance is the system that ensures the snapshot remains accurate over time. The transition from due diligence to ongoing governance requires three structural changes:

**Register third-party agents alongside internal ones.** Your [agent registry](/platform/agent-registry) should include every agent that processes your data or affects your operations, regardless of who built it. A registry that covers only internal agents is half a registry.

**Apply risk classification consistently.** Third-party agents should be [classified by risk](/blog/ai-agent-risk-classification) using the same framework as internal agents. A vendor-managed agent that processes customer PII is high-risk regardless of who operates it.

**Monitor continuously.** Annual assessments catch what changed between cycles. Continuous [observability](/platform/observer) catches what is happening now. For organizations building the governance business case, the [ROI framework for agent governance](/blog/business-case-agent-governance-roi) maps the financial impact of third-party agent incidents against the cost of governance infrastructure.

The agents you did not build are still your agents. They process your data, serve your customers and operate under your brand. The due diligence framework that governs them is not optional. It is the other half of your governance program.

:::cta{title="See Roval in action" description="Book a 15-minute walkthrough of the agent registry, compliance certification and LLM monitoring." cta="Book a demo" href="/demo"}
:::