External Dependency Surface Taxonomy for Production LLM Agents

Research Question

What is the complete taxonomy of external dependencies for a production Large Language Model (LLM)-based agent, how does each dependency class fail, what is the blast radius of each failure class, and which existing frameworks from software supply chain security, operational risk, and distributed systems engineering are applicable?

Findings

Executive Summary

A production LLM agent depends on at least seven external classes, and no single existing framework covers their combined failure and blast-radius profile end to end.

Model-service availability and lifecycle change create broad outage classes, while identity and delegated permission create the highest-consequence action failures because they turn model or tool mistakes into unauthorized actions.

Harness and tool-API dependencies mostly fail through explicit breaking changes, while retrieval and context dependencies mostly fail through silent behavioral drift that conventional software inventories do not capture.

The strongest governance pattern in this evidence base is layered: use SBOM and SSDF controls for deterministic components, operational-risk and NIST AI RMF controls for ownership and change governance, and SRE containment patterns for runtime failure handling.

Key Findings

1. A production LLM agent has at least seven distinct external dependency classes, namely model service availability, model lifecycle and behavior, safety and policy controls, harness and orchestration framework, tool API contract, identity and delegated permissions, and runtime context and retrieval corpus.
2. Provider availability and infrastructure incidents can disable model-dependent workflows and adjacent integrations, as shown by repeated Anthropic model outages and an infrastructure change that broke GitHub-dependent Claude Code and plugin-sync workflows for customers using source-address allowlists.
3. Model retirement, alias drift, and migration semantics should be treated as a separate failure class from outages, because OpenAI and Anthropic both document shut-down dates, replacement models, and behavior or parameter changes that can break prompts, tools, or orchestration even when application code stays unchanged.
4. Harness and orchestration frameworks are shared dependencies whose migrations can change import paths, state-schema rules, middleware hooks, and supported agent-building primitives across every workflow that uses the framework, not just one tool integration.
5. Tool APIs mainly fail through contract drift, mandatory version headers, quota changes, and rate-limit enforcement, which usually creates narrower blast radius than provider outages but can still disable any workflow whose action path depends on one unredundant external service.
6. Identity and delegated-permission surfaces are the highest-consequence dependency class per action, because zero-trust requirements, machine-speed execution, and shared or weakly bounded credentials can turn one reasoning or tool failure into unauthorized writes, data exposure, or untraceable actor chains.
7. Runtime context and Retrieval-Augmented Generation dependencies differ from package dependencies because document, index, and query-planning changes can silently alter grounding evidence and downstream decisions without any model release, which can make this class more drift-prone and less observable than ordinary software dependencies.
8. The most useful governance answer is a layered stack rather than a single imported framework, with SBOM and SSDF practices covering deterministic components, NIST AI RMF and Basel operational-risk controls covering ownership and change governance, OWASP covering agent-specific failure classes, and SRE patterns containing runtime cascades.

Assumptions

• Treating mutable knowledge assets and policy services as inventory-worthy dependencies is a reasonable extension of SBOM logic even though CISA and NTIA define SBOM around software components rather than around agent reasoning inputs. Justification: the cited sources establish inventory logic and the broader agent surface, but they do not themselves publish a canonical agent-specific inventory schema.
• Public status pages under-report some tenant-specific failures, but they are still adequate for proving that provider availability is a real dependency surface. Justification: the item's claim is about dependency-class existence, not about exact outage frequency.

Analysis

The evidence supports a taxonomy that separates hard-fail classes from silent-drift classes.

Model endpoints, retired aliases, and many harness migrations surface as explicit failures in logs or error rates when the dependency breaks compatibility.

Retrieval context, policy tuning, and some model-behavior changes instead degrade outputs or action choices while the agent still appears healthy at the transport layer.

A rival interpretation would treat these surfaces as ordinary vendor-management issues rather than as a special taxonomy problem, but that misses two distinctive properties of agents: one reasoning loop can traverse several dependency classes in one run, and delegated action rights can make a small upstream change materially consequential.

That is why a package-only bill of materials is insufficient, a generic AI-risk checklist is insufficient, and generic SRE containment alone is insufficient: the operationally useful design needs all three viewpoints at once.

Risks, Gaps, and Uncertainties

• Public status pages prove the dependency surface exists, but they do not expose tenant-by-tenant blast radius or all second-order failures.
• Provider behavior drift is more weakly evidenced than retirement and migration because some semantic changes appear in release notes or migration advice rather than in formal incident postmortems.
• Tool API evidence is strong for contract and quota drift, but less strong for multi-tool cascade frequency because official vendors document constraints more readily than they publish root-cause postmortems.
• Retrieval and context claims are high-confidence on mechanism and lower-confidence on prevalence because named public incident records remain sparser than the platform mechanics.

Open Questions

• What is the minimum agent-specific bill-of-materials schema that can record model alias, tool contract, identity boundary, and runtime knowledge source in one machine-readable inventory?
• Which fallback and degradation patterns actually reduce cascade risk for multi-provider agent estates rather than merely multiplying complexity?
• What evaluation protocol best catches cross-class drift when a provider, harness, and tool API all change inside one release window?

sources

• [x] National Institute of Standards and Technology (NIST) (2023) Artificial Intelligence Risk Management Framework 1.0
• [x] NIST Artificial Intelligence Risk Management Framework Playbook
• [x] NIST (2022) Secure Software Development Framework (SSDF) SP 800-218
• [x] NIST (2020) Zero Trust Architecture SP 800-207
• [x] Cybersecurity and Infrastructure Security Agency (CISA) Software Bill of Materials portal
• [x] National Telecommunications and Information Administration (NTIA) (2021) Software Bill of Materials hub
• [x] Open Worldwide Application Security Project (OWASP) Top 10 for Large Language Model Applications
• [x] Basel Committee (2021) Revisions to the Principles for the Sound Management of Operational Risk
• [x] Bank for International Settlements (BIS) Financial Stability Institute summary of Principles for the Sound Management of Operational Risk
• [x] Google Site Reliability Engineering (SRE) book, Addressing Cascading Failures
• [x] OpenAI API Deprecations
• [x] OpenAI API Changelog
• [x] OpenAI Assistants migration guide
• [x] OpenAI Status
• [x] Anthropic Claude API Docs Model Deprecations
• [x] Anthropic Claude API Docs Migration Guide
• [x] Anthropic Claude Status
• [x] LangChain v1 migration guide
• [x] Slack API rate limits
• [x] Notion API versioning
• [x] Lewis et al. (2020) Retrieval-Augmented Generation for Knowledge-Intensive Natural Language Processing (NLP) Tasks
• [x] Microsoft (2026) Retrieval augmented generation in Microsoft Foundry
• [x] Microsoft (2026) Agentic retrieval in Azure AI Search
• [x] Amazon Web Services (AWS) (2026) Four security principles for agentic AI systems
• [x] Mitchell (2026) Artificial Intelligence coding harnesses: agent execution model, memory, and context management across commercial and open-source tools
• [x] Mitchell (2026) Artificial Intelligence concept classification taxonomy: prompts, instructions, memory, failure modes, controls, and problem domains
• [x] Mitchell (2026) What control and governance principles best address access-control amplification caused by agents operating continuously at machine speed under inherited permissions?
• [x] Mitchell (2026) To what extent do enterprise Artificial Intelligence and operational-risk frameworks explicitly recognise human speed, attention, fatigue, and working hours as implicit controls whose removal by agentic AI increases blast radius?
• [x] Mitchell (2026) Is the deployment pipeline the only truly enforceable governance control point for citizen-developed and agentic systems in a Microsoft low-code stack?
• [x] Mitchell (2026) Which identity and attribution model is most appropriate for multi-agent Artificial Intelligence systems that execute tool calls across user-scoped and service-scoped boundaries?
• [x] Mitchell (2026) When Retrieval-Augmented Generation source documents change after agent build and test, what failure modes and behavioral regressions arise, and what dependency and change management practices exist to detect, govern, and mitigate them?