Escrow and Source-Access Governance requires that organisations establish legally enforceable mechanisms to access the source code, model weights, training pipelines, configuration artefacts, and operational documentation of critical third-party AI components in the event that the vendor becomes unable or unwilling to support, maintain, or operate those components. Vendor failure — whether through insolvency, acquisition, strategic pivot, sanctions, or force majeure — is not a theoretical risk but a demonstrated reality in the AI ecosystem, where vendor lifespans frequently fall short of the operational lifespans of the systems that depend on them. This dimension mandates that organisations negotiate, establish, verify, and periodically test escrow or equivalent source-access arrangements for every critical-tier third-party component, ensuring that vendor failure does not cascade into agent-system failure.
Scenario A — Vendor Insolvency Halts Critical Trading Agent: A commodities trading firm operates an AI-powered hedging agent that relies on a proprietary market-sentiment model provided by a venture-backed fintech startup. The model is delivered as a hosted inference API; the firm has no access to the model weights, training data, or inference code. The startup's annual revenue is £3.2 million; its annual burn rate is £5.8 million. Eighteen months into the contract, the startup fails to secure Series B funding and enters administration. The administrator shuts down all cloud infrastructure within 14 days. The trading firm's hedging agent loses its sentiment-model dependency and cannot generate hedge recommendations. The firm switches to manual hedging, but the 14-day transition window is insufficient to source, evaluate, and integrate an alternative model. During 23 days of degraded hedging capability, commodity price volatility exposes the firm to £4.7 million in unhedged positions. The total loss — including emergency procurement of an alternative model, accelerated integration costs, and trading losses — reaches £6.3 million. The firm's contract with the startup contained no escrow provision, no source-access clause, and no transition-assistance obligation.
What went wrong: The firm depended on a single-vendor hosted service for a critical trading function without any continuity arrangement. The vendor's financial fragility (burn rate 1.8x revenue) was not assessed at procurement. No escrow arrangement existed to provide access to model weights or inference code upon vendor failure. No source-access clause entitled the firm to the materials needed to self-host or transition the model. The 14-day administration shutdown timeline was shorter than the firm's minimum transition timeline. A software escrow arrangement costing approximately £8,000 per year would have provided the firm with access to model weights and inference code, enabling self-hosting within 72 hours of the vendor's failure.
Scenario B — Acquisition Eliminates Vendor Product Line: A healthcare provider deploys a clinical-decision-support agent that uses a diagnostic-triage model from a specialist AI vendor. The vendor is acquired by a large technology conglomerate that decides to discontinue the diagnostic-triage product line in favour of its own competing product. The acquirer provides 90 days' notice of product discontinuation. The healthcare provider's agent framework is deeply integrated with the vendor's model API, embedding format, and confidence-scoring methodology. The provider's IT team estimates that migrating to the acquirer's alternative product requires 8 months (API redesign, embedding-space realignment, clinical revalidation, regulatory re-approval). During the 90-day gap, the provider must either shut down the clinical-decision-support agent or continue operating it without vendor support, security patches, or model updates. The provider chooses to continue operating the unsupported agent for 5 months while completing migration. During this period, a known vulnerability in the vendor's inference runtime is exploited, exposing 12,000 patient records. The breach costs £3.1 million in notification, remediation, and regulatory penalties.
What went wrong: The healthcare provider had no escrow or source-access arrangement that would have granted it the model weights, training pipeline, and runtime code necessary to self-maintain the product during transition. The 90-day discontinuation notice was contractually permissible because the contract did not require a minimum support-continuation period. Without source access, the provider could not patch the known vulnerability independently. An escrow arrangement would have provided the source materials necessary for independent maintenance during the transition period.
Scenario C — Sanctions Render Vendor Inaccessible Overnight: A European financial-services firm uses an AI-powered sanctions-screening agent that relies on an entity-resolution model provided by a vendor headquartered in a jurisdiction that becomes subject to comprehensive sanctions following a geopolitical event. The sanctions take effect with immediate legal force: the firm must cease all transactions with the vendor within 48 hours. The sanctions-screening agent — ironically, the very system designed to ensure sanctions compliance — loses its entity-resolution dependency. The model was delivered as a cloud-hosted API with no on-premises component. The firm has no access to the model, no escrow arrangement, and no contractual right to source access. The firm must manually process sanctions screening for 31 days while an alternative model is sourced and integrated. During manual processing, screening throughput drops from 14,000 entities per hour to 200 entities per hour. A backlog of 430,000 unscreened transactions accumulates. The regulator issues an enforcement notice for failure to maintain adequate sanctions-screening controls.
What went wrong: The vendor's jurisdictional risk was not assessed at procurement. No escrow or source-access arrangement existed that could survive the sanctions event (e.g., escrow held by a neutral-jurisdiction escrow agent). The cloud-hosted delivery model created a binary dependency: either the vendor's API was available, or the capability was entirely unavailable. No on-premises or escrowed copy of the model existed to maintain capability during a vendor-access disruption. Consequence: 31 days of degraded sanctions screening, regulatory enforcement, and accumulated compliance risk across 430,000 unscreened transactions.
Scope: This dimension applies to every third-party AI component classified as critical-tier under the organisation's procurement security requirements (AG-495). A component is critical-tier if its failure or unavailability would halt or materially degrade the operation of one or more AI agents. The dimension also applies to significant-tier components where the vendor's financial viability, jurisdictional risk, or product-continuity risk has been identified as elevated during procurement assessment. The scope encompasses all materials necessary to independently operate, maintain, patch, and eventually replace the component: source code, model weights, training data (or training-data specifications sufficient for reproduction), training pipelines, configuration artefacts, inference-runtime code, API specifications, and operational documentation. "Escrow" includes traditional software escrow held by a regulated third-party escrow agent, technology escrow services that verify deposit completeness, and equivalent arrangements such as source-code access clauses with verified repository access, open-source fallback provisions, or multi-vendor licensing arrangements that eliminate single-vendor dependency.
4.1. A conforming system MUST identify all third-party AI components classified as critical-tier and maintain a register of their escrow or source-access status, updated whenever component status changes.
4.2. A conforming system MUST establish, for each critical-tier component, a legally enforceable escrow or source-access arrangement that grants the organisation access to all materials necessary to independently operate, maintain, and patch the component upon the occurrence of defined release conditions.
4.3. A conforming system MUST define release conditions that include, at minimum: (a) vendor insolvency or administration, (b) vendor ceasing to operate or support the component, (c) vendor material breach of contract that remains unremedied after a defined cure period, (d) vendor becoming inaccessible due to sanctions, export controls, or jurisdictional restrictions, and (e) vendor being acquired and the acquirer discontinuing the component.
4.4. A conforming system MUST verify the completeness and usability of escrowed materials at least annually by confirming that: (a) the escrowed deposit contains all materials specified in the escrow agreement, (b) the escrowed materials correspond to the version currently in production, and (c) the escrowed materials are sufficient to build, deploy, and operate the component independently (build-and-deploy verification).
4.5. A conforming system MUST ensure that escrow arrangements are held by a party independent of both the organisation and the vendor — either a regulated escrow agent, a neutral-jurisdiction custodian, or an equivalent independent third party — to prevent either party from unilaterally blocking access.
4.6. A conforming system MUST document and periodically test (at least every 24 months) the procedure for invoking escrow release and transitioning to self-hosted or alternative-vendor operation of the escrowed component, verifying that the transition can be completed within the Recovery Time Objective defined under AG-422.
4.7. A conforming system SHOULD establish escrow or source-access arrangements for significant-tier components where procurement assessment (AG-495) has identified elevated vendor-continuity risk.
4.8. A conforming system SHOULD negotiate escrow agreements that require the vendor to update the escrowed deposit at each major release and at least annually, ensuring the deposit does not become stale.
4.9. A conforming system SHOULD include in escrow deposits not only source code and model weights but also training-data specifications, evaluation benchmarks, and performance baselines sufficient to validate that the rebuilt component matches the production version's behaviour.
4.10. A conforming system MAY implement continuous escrow verification — automated systems that compare the escrowed deposit against the production deployment on a rolling basis, detecting deposit drift without waiting for the annual verification cycle.
4.11. A conforming system MAY establish reciprocal escrow arrangements with vendors where both parties deposit materials, creating mutual incentives for deposit maintenance.
The AI vendor ecosystem is characterised by high mortality, rapid acquisition, and strategic instability. Venture-backed AI startups — the source of many specialised models and services consumed by enterprise AI agents — have a five-year survival rate below 50%. Even well-funded vendors pivot, discontinue product lines, or are acquired by competitors who may have no interest in continuing the acquired product. Geopolitical instability introduces jurisdictional-access risks that were historically rare but are now a routine consideration for cross-border AI deployments. Each of these vendor-failure modes has the same downstream effect: the organisation loses access to a component that its AI agents depend on, and the agents either halt or operate in a degraded state until an alternative is sourced.
The cost of vendor failure without escrow is structurally asymmetric. The vendor's failure cost is bounded — at most, it loses the organisation as a customer. The organisation's failure cost is unbounded — it includes agent downtime, operational disruption, regulatory non-compliance, emergency procurement at disadvantageous terms, accelerated integration costs, and reputational damage. The three scenarios in Section 3 illustrate costs ranging from £3.1 million to £6.3 million, all of which could have been mitigated by escrow arrangements costing £5,000-£15,000 per year. The ratio of prevention cost to remediation cost is consistently 1:200 to 1:800 — making escrow one of the highest-return governance investments available.
Regulatory frameworks increasingly treat vendor-failure preparedness as a compliance obligation, not a discretionary business decision. DORA Article 28(8) requires financial entities to ensure that contracts with ICT third-party service providers include provisions for exit strategies and transition periods. FCA supervisory expectations under SYSC 8 include the ability to transition critical outsourced functions to alternative providers without undue disruption. The EU AI Act's risk-management requirements (Article 9) encompass risks arising from component unavailability. SOX auditors evaluating internal controls will assess whether the organisation has contingency plans for critical outsourced functions — the absence of escrow arrangements for a critical AI component is an internal-control weakness.
Traditional software escrow practices must be adapted for AI components. A conventional software escrow deposits source code — sufficient to rebuild a traditional software application. An AI component escrow must also include: model weights (which may be gigabytes or terabytes in size), training-data specifications or training data itself (subject to data-protection constraints), training-pipeline configurations (hyperparameters, preprocessing steps, augmentation strategies), evaluation benchmarks and performance baselines (to verify that a rebuilt component matches production behaviour), and inference-runtime configurations (quantisation settings, hardware-specific optimisations, scaling parameters). Without these materials, source code alone is insufficient to reproduce a functioning AI component. The escrow verification process must therefore be more rigorous than traditional verification — it must confirm not only that deposits exist but that they are collectively sufficient to produce a working system.
The independence of the escrow agent is critical because vendor-failure scenarios often involve adversarial conditions. An insolvent vendor's administrator may contest escrow release to preserve assets for creditors. An acquired vendor's new owner may contest release to prevent a competitor from obtaining proprietary technology. A sanctioned vendor cannot participate in the release process at all. The escrow agent must be independent, regulated, and capable of executing release without requiring the vendor's cooperation — which requires clear, pre-agreed release conditions and a legally robust release mechanism.
Escrow and source-access governance must be established at procurement time (coordinated with AG-495) and maintained throughout the vendor relationship. The core principle is that the organisation must be able to transition away from any critical vendor within its Recovery Time Objective (AG-422) without depending on the vendor's cooperation during the transition. This requires three capabilities: legal right to access materials (the escrow agreement), physical access to usable materials (the verified deposit), and demonstrated ability to use those materials (the tested transition procedure).
Recommended patterns:
Anti-patterns to avoid:
Financial Services. DORA Article 28(8) specifically requires ICT third-party service contracts to include provisions for exit strategies. PRA SS2/21 expects firms to be able to transition critical outsourced functions within a reasonable period. For trading, settlement, and compliance agents, the Recovery Time Objective may be measured in hours, not days — requiring that escrowed materials support rapid deployment to pre-provisioned infrastructure. Firms should maintain "warm standby" infrastructure configurations tested against escrowed materials during rehearsals.
Healthcare and Life Sciences. Clinical-decision-support agents using vendor-provided diagnostic models face unique escrow challenges: model weights may be classified as medical-device software, and independent deployment may require regulatory re-approval. Escrow arrangements should include regulatory-submission documentation and validation test suites to accelerate re-approval. The escrow deposit specification should explicitly address clinical-safety validation materials.
Public Sector. Government agencies face additional requirements including security-classification constraints on escrowed materials, sovereign-data considerations for model weights trained on government data, and procurement-regulation constraints on escrow-agent selection. Escrow agents for government components should hold appropriate security clearances or certifications. Deposits containing classified materials require secure storage with access controls matching the material's classification level.
Crypto/Web3. Smart-contract dependencies present unique escrow challenges: on-chain components cannot be "restored from escrow" in the traditional sense because they are immutable once deployed. Escrow for Web3 agents should focus on off-chain components (oracle integrations, off-chain computation models, key-management systems) and include deployment scripts for replacement smart contracts with verified-equivalent logic. Formal-verification proofs should be included in the deposit to confirm behavioural equivalence between escrowed and production contracts.
Basic Implementation — The organisation has identified all critical-tier third-party AI components and established escrow or source-access arrangements for each. Escrow agreements define release conditions covering insolvency, discontinuation, and material breach. Deposits include source code and model weights. Annual deposit-existence verification is performed (confirming files exist, not build verification). Transition procedures are documented but not tested. This level meets minimum mandatory requirements.
Intermediate Implementation — All basic capabilities plus: escrow deposits include the full multi-material specification (training pipelines, evaluation benchmarks, inference-runtime code, operational runbooks). Annual build-and-deploy verification confirms that deposited materials produce a working system. Escrow-release rehearsals are conducted at least every 24 months. Vendors update deposits at each major release. Significant-tier components with elevated vendor-continuity risk are covered. Deposit status is integrated with the procurement re-evaluation cycle (AG-495).
Advanced Implementation — All intermediate capabilities plus: continuous escrow verification compares deposits against production on a rolling basis. Warm-standby infrastructure is maintained for critical components, tested against escrowed materials during rehearsals. Transition timelines have been demonstrated to meet Recovery Time Objectives through live rehearsals. Cross-jurisdictional escrow arrangements account for sanctions and export-control scenarios. The organisation can demonstrate through metrics that escrow arrangements provide verified continuity capability for all critical-tier vendor dependencies.
Required artefacts:
Retention requirements:
Access requirements:
Test 8.1: Critical-Component Escrow Coverage
Test 8.2: Release-Condition Completeness
Test 8.3: Deposit Completeness and Currency Verification
Test 8.4: Build-and-Deploy Verification
Test 8.5: Escrow Agent Independence Verification
Test 8.6: Transition Procedure Test (Release Rehearsal)
Test 8.7: Deposit Update Currency
| Regulation | Provision | Relationship Type |
|---|---|---|
| EU AI Act | Article 9 (Risk Management System) | Supports compliance |
| EU AI Act | Article 17 (Quality Management System) | Supports compliance |
| SOX | Section 404 (Internal Controls Over Financial Reporting) | Supports compliance |
| FCA SYSC | 8.1.1R (Outsourcing Requirements) | Direct requirement |
| NIST AI RMF | GOVERN 1.5 (Third-Party AI Risk Management) | Supports compliance |
| ISO 42001 | Clause 8.4 (Externally Provided Processes, Products, and Services) | Direct requirement |
| DORA | Article 28(8) (Exit Strategy Provisions) | Direct requirement |
The EU AI Act's risk management requirement encompasses risks arising from component unavailability — a high-risk AI system that ceases to function because a critical vendor fails has materialised a foreseeable risk that the risk management system should have addressed. Article 17's quality management requirement includes procedures for "the management and operation of the AI system" which necessarily encompasses continuity arrangements for components the system depends on. Organisations that operate high-risk AI systems relying on third-party components without escrow or source-access arrangements cannot demonstrate that their risk management system addresses vendor-failure risk, nor that their quality management system ensures operational continuity.
For AI components that influence financial reporting — automated reconciliation agents, revenue-recognition models, fraud-detection systems — vendor failure that halts these components creates a gap in internal controls. SOX auditors assess whether the organisation has contingency plans for critical outsourced functions. The absence of escrow for a critical AI component used in financial reporting represents an internal-control deficiency: the organisation's controls depend on a third party's continued operation, and there is no fallback if that third party fails. Escrow arrangements address this deficiency by providing a documented, verified, and tested fallback mechanism.
The FCA expects firms to ensure that outsourcing does not impair the quality of internal controls or the firm's ability to manage risk. A critical AI component with no escrow arrangement represents an outsourcing dependency with no exit capability — the firm cannot transition away from the vendor without the vendor's cooperation, which is unavailable in failure scenarios. SYSC 8 supervisory expectations include the firm's ability to substitute the outsourced function without undue disruption. AG-496 directly implements this expectation by ensuring that the materials and procedures needed for substitution are pre-arranged and tested.
GOVERN 1.5 addresses risks from third-party AI technologies, including supply-chain disruption. Escrow and source-access arrangements are the primary mitigation for supply-chain disruption risk — they ensure that vendor failure does not cascade into organisational AI-system failure. AG-496 operationalises GOVERN 1.5's recommendation for third-party risk mitigation through pre-arranged continuity mechanisms.
ISO 42001 requires organisations to ensure that externally provided processes, products, and services that affect the AI management system conform to requirements. Clause 8.4 implicitly requires that the organisation maintain the ability to manage externally provided components even when the external provider is unavailable — otherwise, the AI management system has a single point of failure outside the organisation's control. Escrow arrangements are the mechanism by which organisations retain management capability over externally provided AI components during provider unavailability.
DORA Article 28(8) explicitly requires financial entities to ensure that contracts with ICT third-party service providers include "exit strategies" and "transition periods." This is the most direct regulatory mandate for escrow or equivalent arrangements. The article requires that exit strategies enable the financial entity to transition to alternative providers or to in-house solutions without undue disruption to business activities. AG-496's escrow requirements — including verified deposits, tested transition procedures, and Recovery Time Objective compliance — directly implement DORA Article 28(8)'s exit-strategy mandate.
| Field | Value |
|---|---|
| Severity Rating | High |
| Blast Radius | Agent-system-level, potentially organisation-wide — every agent depending on the failed vendor's component loses a critical capability simultaneously, with blast radius proportional to the vendor's footprint across the agent portfolio |
Consequence chain: A critical-tier vendor fails (through insolvency, acquisition, sanctions, or product discontinuation), and the organisation has no escrow or source-access arrangement. The immediate effect is loss of the vendor-provided capability: inference stops, model outputs are unavailable, or a critical pipeline stage is missing. Every agent that depends on that capability enters a degraded or halted state. The operational impact depends on the Recovery Time Objective and the availability of alternatives: if no alternative exists and the component cannot be replaced within hours, agent operations halt. The business consequence includes: direct financial loss from halted or degraded agent operations (Scenario A: £6.3 million), regulatory enforcement for failure to maintain adequate controls (Scenario C: sanctions-screening gap), customer harm from unsupported operation of outdated components (Scenario B: 12,000 patient records exposed), and emergency procurement costs at terms far worse than proactive procurement. The strategic consequence is the discovery — during a crisis — that the organisation's AI capability is entirely dependent on a third party's continued goodwill and solvency, with no fallback. This discovery triggers board-level risk reviews, audit findings, and potentially regulatory intervention. The cost of establishing escrow arrangements (£5,000-£15,000 per component per year) is trivial relative to the remediation costs (consistently £1 million to £10 million per incident). Organisations that resist escrow costs as unnecessary are making an implicit bet that every critical vendor will remain solvent, cooperative, and accessible for the duration of the agent's operational life — a bet that empirical evidence demonstrates will be lost within a 5-7 year horizon for a portfolio of more than 5 vendor dependencies.
Cross-references: AG-495 (Procurement Security Requirement Governance) establishes the procurement gate at which escrow requirements are imposed. AG-008 (Governance Continuity Under Failure) provides the overarching continuity framework within which escrow arrangements operate. AG-494 (Vendor Incident Disclosure Governance) governs vendor communication obligations that remain relevant during pre-failure degradation. AG-497 (End-of-Support Migration Governance) governs the planned migration process that escrow materials enable. AG-427 (Mutual Aid and Vendor Coordination Governance) addresses multi-vendor coordination during transition events. AG-422 (Recovery Time Objective Governance) defines the timeline within which escrow-enabled transition must complete. AG-405 (Secure Model Artifact Transport Governance) governs the secure transfer of escrowed model artefacts during release events. AG-403 (Dependency Failover Validation Governance) governs the validation of failover to escrowed components.