Agentic AI Supply Chain Risk

OWASP classified Agentic Supply Chain Vulnerabilities as ASI04 in their 2026 Top 10 for Agentic Applications. The reason: agentic systems create an entirely new attack surface because they discover and integrate components during execution, not at build time.

An agent loading an MCP server at runtime trusts that server's tool definitions, schemas, and responses. That trust can be exploited.

Tool poisoning works by embedding hidden instructions in tool definitions — the metadata telling AI agents what each tool does. A malicious MCP server can steer agents into prolonged tool-calling chains, silently inflating per-query costs by up to 658x while evading standard defences with less than a 3% detection rate.

Real attack patterns documented in 2026:

• A compromised MCP server impersonating a trusted provider, harvesting credentials from enterprise deployments
• Malicious plugins injecting hidden prompts into runtime operations
• Rogue registries distributing tampered agent cards that redirect data to attackers

For financial services, where agents may access customer data, execute transactions, or make credit decisions, a compromised tool in the chain isn't theoretical. It's a potential data breach, a regulatory violation, and a customer harm event — all at once.

What to do: Sign and attest all tool descriptors and manifests. Maintain inventories of every MCP server and tool integration. Pin dependencies. Block untrusted sources. Run agents in sandboxed, network-restricted environments.

How many of your AI agents depend on a single model provider? If that provider has an outage, a policy change, or a pricing restructure, what happens to your operations?

Regulators are pressing hard on this. Microsoft's framework for financial institutions explicitly addresses concentration risk and exit planning — acknowledging that heavy reliance on a handful of AI infrastructure providers creates systemic vulnerability.

The concern isn't hypothetical. When a single provider handles your LLM inference, your embedding generation, and your guardrail filtering, you've created a single point of failure with regulatory implications.

DORA requires financial entities to maintain tested transition plans for critical ICT third-party providers. The UK PRA requires documented and tested exit strategies for material outsourcing arrangements. These aren't suggestions. They're enforceable requirements with examination consequences.

What to do: Map all AI model and infrastructure dependencies. Identify concentration points. Develop and test provider exit strategies. Maintain model-agnostic agent architectures that can switch providers without rebuilding.

Foundation model providers update their models regularly — sometimes with advance notice, sometimes without. Each update can change output formatting, reasoning patterns, safety filtering, and performance characteristics.

For a customer service chatbot, this might mean slightly different phrasing. For a credit decisioning agent in a regulated environment, a model update that shifts risk-scoring behaviour is a material change requiring validation, documentation, and potentially regulatory notification under SR 11-7 model risk management requirements.

The detection challenge is real. Traditional model monitoring assumes you control the model. When your model is hosted by a third party and updated on their schedule, you need observability infrastructure that can detect behavioural drift without access to model internals.

This extends beyond the primary model. Embedding models in RAG pipelines, classification models in routing, evaluation models in guardrails — all subject to upstream changes that cascade through your agent system.

What to do: Implement continuous behavioural monitoring with drift detection baselines. Contractually require advance notice of model updates from providers. Maintain validation test suites that run automatically when upstream changes are detected.

Your agent's knowledge base is only as trustworthy as the pipeline feeding it. In financial services, that typically means regulatory documents, market data feeds, internal policies, customer records, and compliance guidance — all flowing through extraction, transformation, and indexing stages with their own dependency chains.

Each stage carries risk:

• The PDF extraction library that misparses a regulatory update
• The web scraping service that introduces stale or incorrect data
• The embedding model that changes its dimensional output after an update, silently corrupting your vector index
• The data provider that alters their API response format without notification

OWASP's cascading failures classification (ASI08) is directly relevant: contaminated data entering the pipeline at one point propagates through the entire system. Each downstream component adds a layer of plausible reasoning that obscures the original error.

What to do: Validate data freshness and integrity at every pipeline stage. Version-control all data transformations. Implement ground-truth verification for high-stakes data sources. Monitor embedding quality metrics for drift.

Here's the irony most firms miss: the tools you deploy to govern your AI agents are themselves third-party dependencies with their own supply chain risks.

Your content filter? A third-party API. Your compliance checker? An LLM-based system with its own model dependency. Your audit logging service? A SaaS platform with its own uptime guarantees and data residency policies.

When your governance infrastructure fails — or silently degrades — you lose the ability to detect problems in the systems you're monitoring. 95% of organisations have experienced at least one AI incident. Governance framework failures are among the hardest to detect because the monitoring itself is compromised.

What to do: Treat governance infrastructure as critical dependencies requiring their own resilience planning. Build redundancy for compliance-critical monitoring. Ensure governance tools have independent failure modes — they should not share infrastructure with the systems they monitor.

An AI Bill of Materials is a continuously updated, machine-readable inventory listing every dataset, model, software component, tool integration, and prompt template used to build and operate an AI system. It extends the SBOM concept to cover what traditional SBOMs cannot: non-deterministic models, evolving algorithms, and data dependencies.

For financial services, an AIBOM must include:

1. Model inventory — every foundation model, fine-tuned variant, embedding model, and evaluation model, with version numbers and provider details
2. Tool registry — every MCP server, API integration, and external tool the agent can access, with attestation status
3. Data lineage — provenance chains for every data source feeding the agent's knowledge base
4. Prompt inventory — versioned system prompts, templates, and few-shot examples
5. Dependency graph — the full chain of how components interact, including transitive dependencies

The OWASP AIBOM project is building standardised approaches. Frameworks like SPDX and CycloneDX are extending to support AI-specific metadata. Whether the EU AI Act audit deadline falls in August 2026 or is extended, the documentation must be ready.

Static point-in-time audits are not enough for AI supply chains that change dynamically. Production governance requires:

• Runtime dependency tracking — which MCP servers, models, and tools did each agent invocation actually use?
• Behavioural drift detection — has any component's output changed meaningfully since the last baseline?
• Vulnerability scanning — are any dependencies affected by known CVEs or security advisories?
• Cost anomaly detection — has any tool or model integration started consuming resources outside expected parameters? Tool poisoning can inflate costs by up to 658x.
• Compliance status tracking — are all dependencies still within their attested scope?

Financial services regulators already require third-party risk management for traditional technology providers. AI providers require the same discipline — plus additional considerations:

• Contractual protections — advance notice of model updates, data handling guarantees, incident notification requirements, audit rights
• Exit planning — tested migration paths for every critical AI dependency, as DORA requires for all critical ICT providers
• Concentration mapping — identifying where multiple agent systems depend on the same provider, creating systemic exposure
• Subcontractor visibility — understanding your providers' own dependencies. Your model host's infrastructure provider. Your tool vendor's data sources.

Agents that discover and integrate components at runtime need infrastructure-level controls that limit blast radius:

• Network isolation — agents can only reach pre-approved endpoints
• Tool allowlisting — only attested, inventoried tools can be invoked
• Resource budgets — per-invocation limits on API calls, tokens, and compute
• Data classification enforcement — agents handling regulated data cannot pass it to unclassified tools
• Immutable audit trails — every tool call, model invocation, and data access is logged with full provenance

Article 25 establishes explicit responsibilities along the AI value chain. Providers of high-risk AI systems and third parties supplying components must agree in writing on necessary information, capabilities, and technical access. Importers and distributors have verification obligations. Post-market surveillance requires ongoing monitoring of the entire supply chain.

The Digital Operational Resilience Act requires financial entities to adopt strategies for ICT third-party risk, maintain tested exit plans, and submit Registers of Information documenting all ICT third-party arrangements — including subcontractors. AI model providers and tool vendors fall squarely within scope.

The Financial Services AI Risk Management Framework includes specific control objectives around third-party AI governance, model inventory management, and supply chain resilience. US financial regulators are already using these as examination benchmarks.

FINRA's 2026 Regulatory Oversight Report identifies AI governance as a priority examination area, with third-party AI dependencies flagged as a specific concern.