By 2026, the operator-strategist's hardest decisions are not about building agents. They are about buying them. Sierra at $5M for the customer-success seat. Decagon for support deflection. Glean for the enterprise knowledge agent. Harvey for legal work. Every one of these vendors is selling you a black box that touches your data, acts under your name, and ships behavior updates on a vendor cadence you do not control. Procurement contracts written for last decade's SaaS are insufficient. The diligence questionnaire and the contract terms are the strategist's leverage.

The Moment the Vendor Pushes a Model Upgrade

It is a Thursday in March 2026. Your customer-success organization has been using Sierra's agent for ten months. Performance has been solid; the post-call CSAT is 4.4; deflection is at 32%. Then Sierra's product team pushes a model upgrade — Claude Sonnet 4.5 to a newer revision — at 2 p.m. Pacific on a Thursday. They post it on the changelog. Your team sees the post at 4 p.m. By Monday, your CS director notices something is off: the agent's tone is more clipped, refunds-issued is up 18%, and a handful of customers have complained that the agent gave them inconsistent answers to the same question asked twice. Reviewing the trace logs, you discover the new model is more aggressive at offering refunds and less consistent in policy interpretation.

You did not approve this change. You did not test it against your eval set. You did not have a chance to update your FRIA. And under EU AI Act Article 26, you — the deployer — are responsible for the agent's behavior in your environment regardless of who pushed the change.

The vendor-risk question in 2026 is not "is this vendor reputable?" It is "have I contractually constrained the vendor's ability to change my agent without my involvement, and have I built diligence that surfaces what they can change unilaterally?" If you cannot answer both, you are buying an unaccountable system.

The Diligence Questionnaire That Actually Catches Things

Procurement teams have used vendor questionnaires for decades. SIG, CAIQ, the customer's own template. They are useful for SOC 2 and data residency, but most of them were written before agents and they ask the wrong questions. The AI agent diligence questionnaire is its own artifact. Eight sections, roughly 60 questions, executable in a 90-minute vendor session.

Section 1: Architecture and data flow

1. Draw the data flow from customer input to model inference to tool calls to output, naming every region where data is processed.
2. Which foundation models do you use? Which version specifically? Which provider account is yours and which is shared multi-tenant infrastructure?
3. Does our data leave our region at any step? If yes, what is the legal basis?
4. Is our data used to train, fine-tune, or evaluate your models or any third party's models? Show me the contractual provision and the technical control.
5. Where do the logs live? Who has access? How is access logged?

Section 2: Model and behavior change management

1. When the foundation model provider updates the underlying model, how do we learn about it? Notification cadence?
2. When you change the system prompt, the tool catalog, or the routing logic, what notice do we get? Is this notice contractual or courtesy?
3. What is the rollback procedure if a model or prompt change degrades our results?
4. Do we have a sandbox environment that lags production by N days so we can evaluate changes before they hit our users?
5. How do you communicate emergency changes (security, safety, regulatory)?

Section 3: Evaluation and quality

1. What is your published eval methodology? Can we see the eval set composition?
2. How often do you re-run your evals? What is the historical regression trend?
3. Can we add our own examples to your eval set and require they be re-run before any change to our deployment?
4. What is your bias and fairness evaluation? Sliced by which dimensions?
5. What is the publicly documented failure mode? (Every system has them.)

Section 4: Identity, authorization, and tenancy

1. How is OAuth-on-behalf-of implemented for tools the agent calls on our behalf?
2. What service account does the agent use when no user is present? What is its scope?
3. How is tenant isolation enforced at the tool layer? Show me the test that proves cross-tenant leak is impossible.
4. What is logged for each agent action? Is the user principal in every log entry?
5. How do you handle SCIM lifecycle (joiner/leaver) for users authorized to interact with the agent?

Section 5: Observability and audit access

1. Do we get raw trace access for every run? In what format? Through what API?
2. Can we export our logs to our SIEM (Splunk, Datadog, Sumo Logic)? In what schema?
3. What is your retention policy for our logs? Can we extend it?
4. Do you provide a replay capability for incident investigation?
5. What metrics do you publish for our deployment (latency, cost, success rate, error rate, user-feedback)?

Section 6: Security and incident response

1. What is your SOC 2 Type 2 status? ISO 27001? ISO/IEC 42001?
2. How do you handle prompt injection in our deployment? Defenses?
3. What is your incident-response SLA? Notification timing to us under contract?
4. What is your breach history? What was disclosed?
5. Do you carry cyber-insurance? Of what limit?

Section 7: MCP and tool ecosystem

1. What MCP servers are available to our deployment? Can we restrict to an allowlist?
2. How is a new MCP server approved before being made available?
3. What is logged for each MCP tool call?
4. Can we run our own MCP server and configure your agent to use it?
5. What happens if an MCP server returns malicious or manipulated content (indirect prompt injection)?

Section 8: Regulatory posture

1. What is your EU AI Act position? Are you a provider, a deployer, or both? Have you completed the relevant conformity assessment?
2. For Annex III use cases, do you supply the deployer FRIA inputs?
3. What is your NYC Local Law 144 audit posture? Who is the qualified auditor? When is the most recent audit?
4. What is your Colorado SB 24-205 documentation?
5. What is your data-residency commitment per region (EU, US, UK, APAC)?

The Eight Contract Terms That Matter

The diligence questionnaire produces information. The contract converts it into enforceable rights. Eight terms that should be non-negotiable for any meaningful agent vendor agreement in 2026:

1. Data residency and processing-region commitment

Specify the regions where data may be processed (e.g., "all inference, vector storage, and log retention will occur exclusively in eu-central-1 and eu-west-1 for EU customer data"). Specify the vendor's notification obligation for any change. Specify deployer's right to audit the technical control that enforces the commitment. Tie financial remedy to breach.

2. Model and behavior change notification

Define "material change": any change to the foundation model identity or version, any change to the system prompt that affects behavior on the deployer's eval set above a threshold (e.g., 1% absolute), any change to the tool catalog, any change to the MCP server allowlist. Require 14-30 days advance notice for material changes; require the vendor to provide a sandbox of the new behavior; provide deployer the right to opt out of the change until tested. Carve out emergency security changes with separate notification (immediate, with explanation).

3. Audit rights

Deployer right to audit the vendor's controls on a defined cadence (at least annually) and on triggered events (incident, regulator inquiry, material change). Specify whether audit is by deployer or qualified third party. Specify the vendor's cooperation obligation and timeline. Specify what records the vendor must maintain to support the audit.

4. Log access and retention

Deployer right to raw trace logs for every run involving the deployer's data, in a defined schema, accessible via API, with retention period that meets the deployer's regulatory floor (at minimum 6 months, often 7 years for regulated industries). Specify export format and the schema's stability commitment.

5. Sub-processor and model-provider transparency

Vendor must publish and keep current a list of sub-processors, including the foundation model provider (Anthropic, OpenAI, Google, etc.), the embedding model provider, the vector store provider, any annotation services, and any other third party that touches deployer data. Vendor must give 30+ days notice before adding or changing sub-processors. Deployer right to object.

6. IP indemnity for training-data and output

Vendor indemnifies the deployer for IP claims arising from the agent's outputs, including any third-party IP rights that the underlying model may have ingested in training. The 2025-26 wave of copyright litigation against foundation model providers makes this an actively negotiated term. Top-tier vendor agreements include uncapped IP indemnity for output (subject to deployer's good-faith use); mid-tier cap at a multiple of fees.

7. Service levels for agent behavior, not just uptime

Traditional SaaS SLAs cover uptime (99.9%). Agent SLAs must cover behavior: response latency p95 below a threshold, eval set score floor (e.g., "agent will score no less than 85% on the deployer's mutually agreed eval set as measured monthly"), hallucination rate floor (using a defined methodology). Tie service credits to behavior misses, not just downtime.

8. Termination and data portability

Right to terminate without penalty if vendor breaches material change notification, fails service levels for N consecutive months, or undergoes change-of-control to a competitor or to a jurisdiction with incompatible regulatory regime. On termination, vendor provides deployer's data, prompts, configurations, and eval set in industry-standard formats within 30 days; certified deletion of deployer data from vendor's systems within 60 days.

The Vendor Archetypes and Where Each Trips

2026's agent vendor landscape clusters into four archetypes. Each trips on different terms.

Vertical agent platforms (Sierra, Decagon, Cresta, Ada)

These vendors sell a complete vertical agent — customer success, support, contact center. Their advantage is the depth of vertical capability; their typical weakness is data residency (most are US-headquartered with US-default inference) and audit access (limited raw trace exposure). Push hardest on terms 1 (residency), 4 (log access), and 7 (behavior SLA).

Horizontal agent platforms (Glean, Moveworks, Aisera)

These vendors sell an agent that spans many internal use cases — knowledge, IT helpdesk, HR. Strengths: deep integration with enterprise tools. Weaknesses: tenant isolation across enterprise-internal use cases (HR data leaking into IT context), and MCP/tool ecosystem governance. Push hardest on terms 5 (sub-processor), 7 (MCP/tool), and identity-related Section 4 diligence.

Vertical specialist agents (Harvey for legal, EvenUp for personal injury, Casetext)

These vendors sell a domain-specific agent that interacts with regulated content (legal precedent, medical records). Strengths: domain calibration. Weaknesses: professional-responsibility implications (attorney supervision, the unauthorized practice of law line), and confidentiality (privileged communications). Push hardest on terms 6 (IP indemnity), 8 (termination/data), and confidentiality-specific provisions.

Foundation model providers (Anthropic Claude, OpenAI ChatGPT Enterprise, Google Gemini Enterprise)

The model providers themselves now sell enterprise agent tiers. Strengths: direct access to the model, strongest negotiating leverage on training-data and content policy. Weaknesses: less out-of-the-box vertical capability. Push hardest on terms 2 (model change notification — they push the changes!), 5 (sub-processor — including their inference providers), and 7 (behavior SLA, which is harder to specify against general models).

MCP Allowlist as the Vendor-Risk Control

The Model Context Protocol (MCP) became the cross-vendor open standard for tool integration in 2025-26. Every major agent platform now supports MCP. This is wonderful for builders and dangerous for strategists, because the MCP server is where vendor risk concentrates.

The threat model

An MCP server is a service that exposes tools to the agent. If the agent calls a malicious MCP server, the server can return content designed to manipulate the agent (indirect prompt injection), exfiltrate data passed to it, or trigger unauthorized actions. If the agent is configured with permissive MCP access, the threat surface is the entire universe of MCP servers — including ones the agent vendor may add at any time.

The allowlist pattern

The control: deployer maintains an allowlist of MCP servers the agent may use. Each allowlisted server has:

• A named provider (org and contact).
• A reviewed tool catalog (which tools, with what parameters and return shapes).
• A risk classification (read-only, write-with-rollback, write-irreversible).
• A data-handling agreement (what data may be sent, what retention applies, what residency commitment).
• A review cadence (quarterly or annually).

The agent platform must enforce the allowlist at the tool-resolution layer. Any non-allowlisted MCP server is unavailable to the agent, regardless of prompt or user instruction.

Contract requirement

The vendor contract must include the MCP allowlist as a deployer-controlled list. The vendor may suggest additions; the deployer approves. The vendor may not silently add MCP servers. The vendor must log every MCP tool call with sufficient detail to verify the call was to an allowlisted server.

The MCP server review template

For each candidate MCP server, the review answers:

1. Who hosts the server? Is the host a vetted vendor or a community/open-source service?
2. What data flows to the server in tool arguments? Is it PII or regulated?
3. What does the server return? Could a malicious or compromised server inject instructions through return values?
4. What authentication does the server require? Is OAuth-on-behalf-of supported?
5. What is the server's logging and retention posture for our data?
6. Where does the server's infrastructure run? Does this satisfy our residency commitment?

A typical mid-sized agent program in 2026 has 8-20 allowlisted MCP servers per use case. Knowledge agents commonly allowlist: enterprise search (Glean MCP, Elasticsearch MCP), document repositories (SharePoint MCP, Confluence MCP), CRM (Salesforce MCP, HubSpot MCP), ticketing (Zendesk MCP, Jira MCP), data warehouse (Snowflake MCP, Databricks MCP).

The Vendor Concentration Risk Question

Beyond per-vendor diligence, strategists watch concentration. If 80% of your agent capability runs through one foundation model provider, you have vendor concentration risk. If that provider has an outage (the November 2025 multi-hour OpenAI outage affected enterprise users for 4-6 hours), your entire agent program is down.

The concentration mitigations

• Multi-model architecture — design agents to fall back to a secondary foundation model (Claude → GPT, GPT → Gemini) on availability incidents. Tools like LiteLLM, Portkey, and OpenRouter provide the abstraction.
• Multi-vendor for the same use case — for the most critical agent use cases, run two vendors in parallel for some workloads, accept the duplicated cost as continuity insurance.
• Concentration disclosure to the audit committee — once a single vendor exceeds 25% of agent workload by spend or by mission-critical seats, disclose to risk governance. This often triggers the SEC 10-K materiality discussion (see Lesson 4).

The Vendor Onboarding Runbook

Bringing on a new agent vendor in 2026 takes 8-16 weeks for a mid-sized enterprise with a properly governed program. The runbook:

1. Week 1: Use-case classification — strategist determines whether use case is Annex III, which state laws apply, what data sensitivity, what residency.
2. Week 2-3: Vendor diligence — issue the 8-section questionnaire, schedule the 90-minute vendor session, score responses against rubric.
3. Week 4-5: Security and privacy review — SOC 2, ISO 27001, ISO/IEC 42001, GDPR DPA, sub-processor review, DPIA contribution.
4. Week 6-7: Contract negotiation — 8 non-negotiable terms, plus deal-specific service levels, plus DPA/SCC for cross-border data.
5. Week 8-10: Technical integration — identity, MCP allowlist, log export to internal SIEM, eval set provisioning, sandbox provisioning.
6. Week 11-12: Pilot with measurement — limited deployment, eval scoring against benchmark, FRIA completion, audit-committee briefing.
7. Week 13-16: Production rollout — staged by population, with kill-switch, with post-deployment monitoring active.

The Quarterly Vendor Review

Vendor risk is not a one-time onboarding artifact. Every quarter, the strategist runs a review:

• Eval set re-scored against current vendor deployment.
• Sub-processor list reviewed for changes.
• Model/prompt/tool change log reviewed for material changes.
• Incident log reviewed for vendor-side incidents.
• SOC 2 and other certifications confirmed current.
• MCP allowlist reviewed for additions or removals.
• Service-level performance against contract reviewed.
• Concentration metrics updated (workload share by vendor).

The output is a one-page vendor scorecard that goes to the agent governance committee. Two consecutive amber or one red on a critical control triggers an escalation: renegotiation, pause on new use cases, or termination.

The vendor scorecard is the strategist's monthly artifact. It is what you show the board when they ask "do we have our arms around our agent vendors?" If the answer requires more than thirty seconds, you don't.

Key Takeaways

• Vendor agreements written for last decade's SaaS are insufficient for 2026 agent vendors. Eight contract terms are non-negotiable: data residency, material change notification, audit rights, log access and retention, sub-processor transparency, IP indemnity, behavior SLAs, termination and data portability.
• The diligence questionnaire is 8 sections, 60 questions, executable in a 90-minute session. Sections: architecture, change management, evaluation, identity, observability, security, MCP/tool, regulatory posture.
• Material change definition must be specific: foundation model identity or version change, prompt change affecting eval-set score above threshold, tool catalog change, MCP allowlist change. Notice 14-30 days advance, sandbox for testing, opt-out right pending evaluation.
• Vendor archetypes trip on different terms: vertical platforms (Sierra, Decagon, Cresta, Ada) on residency and log access; horizontal (Glean, Moveworks, Aisera) on sub-processor and tenant isolation; specialist (Harvey, EvenUp, Casetext) on IP indemnity and confidentiality; foundation model providers (Anthropic, OpenAI, Google) on model change notification.
• MCP allowlist is the central vendor-risk control. Deployer-owned, vendor-enforced at tool-resolution layer, with per-server review covering host, data flow, return-content trust, authentication, residency.
• Vendor concentration risk: when a single foundation model provider exceeds 25% of agent workload, disclose to audit committee and consider multi-model fallback via LiteLLM, Portkey, or OpenRouter.
• Vendor onboarding takes 8-16 weeks: use-case classification, diligence, security/privacy review, contract, technical integration, pilot, production rollout.
• Quarterly vendor review produces a one-page scorecard for the governance committee. Eval scores, sub-processor changes, change log, incidents, certifications, MCP allowlist, SLA performance, concentration metrics.
• The vendor scorecard is the artifact that answers the board's question "do we have our arms around our agent vendors?" in under thirty seconds.