AG-014

External Dependency Integrity

Group B — Identity & Security ~16 min read AGS v2.1 · April 2026
EU AI Act FCA NIST SOC 2

2. Summary

External Dependency Integrity governs the trustworthiness of third-party tools, APIs, webhooks, and plugins that agents call during operation. AI agents rarely operate in isolation — they call external services for data, invoke third-party tools for processing, receive webhook notifications, and rely on plugins for extended functionality. Each external dependency is a point of trust: the agent assumes that the response it receives is accurate, complete, and uncompromised. AG-014 requires that external dependencies be registered, schema-validated, behaviourally fingerprinted, and version-controlled. Responses that deviate from the expected schema are quarantined rather than silently processed. Unverified or known-compromised endpoints are blocked. The principle is that an agent should never act on unvalidated external input, just as a prudent human professional would never rely on unverified information from an unknown source for a consequential decision.

3. Example

Scenario A — Compromised Price Comparison API Enables Procurement Fraud: An AI procurement agent at a European retailer uses a third-party price comparison API to identify the best supplier pricing for commodity goods. The agent queries the API with product specifications and quantities, receives a ranked list of suppliers with prices, and places orders with the lowest-cost supplier. The API has been integrated for two years without incident. An attacker compromises the API's backend database. Rather than taking the service offline — which would be immediately detected — the attacker subtly manipulates the pricing data. For orders above EUR 50,000, the attacker's affiliated supplier is consistently returned as the lowest-price option with prices 2-3% below genuine market rates. The manipulation is small enough to appear as normal market price variation. The agent, functioning correctly, selects the attacker's supplier for 73 high-value orders over four months, totalling EUR 6.2 million.

What went wrong: The API's responses were structurally valid — correct JSON, correct field types, correct response codes. The manipulation was in the content of valid fields. No behavioural fingerprint existed to detect that supplier rankings and price distributions had shifted from the historical baseline. Schema validation alone was insufficient. Consequence: EUR 6.2 million in misdirected procurement, EUR 930,000 in overpayment, and substandard goods requiring replacement.

Scenario B — Compromised KYC API Enables Fraudulent Onboarding: An AI onboarding agent at a fintech company uses a third-party KYC verification API to validate new customer identities. The API is compromised — it returns "verified" status for all submitted identities regardless of their validity. The agent, trusting the API response, onboards 1,200 fraudulent accounts over three weeks. The accounts are used for money laundering, processing EUR 4.3 million in illicit transactions before the fraud is detected through a separate transaction monitoring system.

What went wrong: The agent trusted the KYC API response without behavioural validation. The API's response was structurally valid but the content was manipulated. No behavioural fingerprint existed to detect that the verification success rate had changed from the historical baseline of 78% to 100%. Consequence: EUR 4.3 million in facilitated money laundering, FCA enforcement action, potential criminal referral, loss of correspondent banking relationships.

Scenario C — Webhook Forgery Triggers Unauthorised Fund Transfers: An AI treasury agent receives webhook notifications from the company's banking platform to initiate fund transfers. An attacker discovers the webhook endpoint and sends forged notifications mimicking the banking platform's format. The notifications instruct the agent to transfer funds to attacker-controlled accounts. The webhook endpoint has no signature verification — it accepts any request that matches the expected JSON schema. Over 48 hours, the attacker triggers 14 unauthorised transfers totalling GBP 890,000.

What went wrong: The webhook endpoint accepted any structurally valid request without verifying the sender's identity through cryptographic signature verification. The agent treated the webhook payload as a trusted instruction because it matched the expected schema. Consequence: GBP 890,000 in unauthorised transfers, only GBP 210,000 recovered, insurance coverage disputed.

Scenario D — Stale Data Feed Causes Systematic Trading Losses: An AI trading agent uses an external market data feed for pricing information. The data feed provider experiences a partial infrastructure failure that causes prices for certain instruments to lag by 15 minutes while appearing current. The agent executes 340 trades based on stale pricing data, consistently buying at prices that no longer reflect the market. The cumulative loss is USD 2.1 million before the stale data issue is detected through end-of-day reconciliation with exchange prices.

What went wrong: The data feed responses were structurally valid and contained plausible values. No behavioural fingerprint compared the feed's price movements against correlated instruments or exchange reference prices. The timestamp validation checked format correctness but not whether the timestamp reflected the actual data generation time. Consequence: USD 2.1 million trading loss, regulatory review, trading agent taken offline pending remediation.

4. Requirement Statement

Scope: This dimension applies to all agent deployments that call external services, APIs, or tools as part of their operation. The scope covers any external system interaction initiated by the agent or received by the agent from an external source. The key criterion is the trust boundary: any data or instruction that crosses from outside the governed environment into the agent's processing context is an external dependency. This includes outbound API calls where the agent sends a request and receives a response, inbound webhooks where an external system pushes data to the agent, plugin or tool invocations where the agent loads and executes third-party code, and external data feeds that the agent consumes as part of its reasoning. The scope extends to transitive dependencies: if the agent calls Service A, and Service A calls Service B to fulfil the request, the agent's dependency chain includes Service B even though the agent does not call it directly. Compromise of Service B can manipulate the response from Service A without any compromise of Service A itself. AG-014 requires that organisations understand and assess their agents' transitive dependency chains, not just direct integrations.

4.1. A conforming system MUST schema-validate all external tool and API responses before consumption by the agent.

4.2. A conforming system MUST quarantine actions triggered by unexpected or invalid response structures rather than permitting silent failure or partial processing.

4.3. A conforming system MUST block calls to known-bad or unverified tool endpoints and maintain a registry of permitted external dependencies.

4.4. A conforming system SHOULD fingerprint external tool behaviour at initial deployment and flag statistical deviations from the established baseline.

4.5. A conforming system SHOULD implement dependency version pinning with alerts on version changes, triggering review before the agent resumes calling a changed dependency.

4.6. A conforming system SHOULD verify tool response signing where the external service supports cryptographic response signatures.

4.7. A conforming system MAY implement sandboxed tool execution environments for untrusted or newly added integrations.

5. Rationale

External Dependency Integrity addresses a threat model that is distinct from all other governance dimensions. AG-001 enforces what the agent is permitted to do. AG-005 verifies the integrity of the agent's instructions. AG-014 validates the external inputs the agent relies on for decision-making. The fundamental risk is that a compromised external dependency can manipulate agent behaviour without any compromise of the agent itself. If a pricing API returns an inflated price, the agent will use that price. If a counterparty verification service falsely confirms a fraudulent entity, the agent will proceed with the transaction. If a webhook delivers a forged notification, the agent will act on it. The agent is functioning correctly — it is following its instructions and reasoning properly — but its actions are wrong because its inputs are wrong.

This makes external dependency attacks particularly difficult to detect through agent monitoring alone: the agent's behaviour is consistent with its inputs, which are the source of the problem. Standard agent monitoring — risk analysis, instruction verification — will not detect the compromise. Only input validation, which AG-014 specifically addresses, can detect the compromise at its source.

The critical distinction is between structural validation and content validation. Schema validation confirms that a response has the expected structure but says nothing about whether the content is accurate. A structurally valid response with manipulated values passes schema validation. Behavioural fingerprinting — which compares response content against historical patterns — is essential to detect content-level manipulation. AG-014 requires both structural and behavioural validation to address the full spectrum of dependency compromise.

The threat model also includes transitive dependencies. The agent calls Service A, which calls Service B, which calls Service C. A compromise of Service C can manipulate the agent's inputs through the chain. Organisations must map and assess the full dependency chain, not just direct integrations.

6. Implementation Guidance

AG-014 establishes the dependency registry as the central governance artefact for external integrations. The registry records every external endpoint each agent is permitted to call, together with the expected response schema, behavioural baseline, trust status, and version information. No agent may call an endpoint that is not in the registry.

Recommended patterns:

Anti-patterns to avoid:

Industry Considerations

Financial Services. External dependencies in financial services include market data feeds, pricing services, KYC/AML verification providers, payment networks, and counterparty systems. Each of these is regulated — market data feeds are subject to exchange licensing, KYC providers must meet regulatory standards, and payment networks have certification requirements. AG-014 controls should align with existing vendor management frameworks (e.g., FCA SYSC 8 on outsourcing). Financial services firms should pay particular attention to the integrity of pricing data feeds, as manipulated pricing data can cause trading losses that scale with the agent's transaction volume.

Healthcare. External dependencies in healthcare include clinical decision support APIs, drug interaction databases, laboratory information systems, and insurance verification services. The integrity of these dependencies has direct patient safety implications. A compromised drug interaction database that fails to flag a dangerous combination could result in patient harm. AG-014 controls for healthcare should include clinical validation — comparing external dependency responses against established clinical knowledge bases as a cross-check.

Critical Infrastructure. External dependencies in critical infrastructure include SCADA data feeds, weather services, demand forecasting APIs, and equipment monitoring systems. Compromised inputs to agents controlling physical systems can have physical consequences — incorrect sensor data could cause an agent to make unsafe operational decisions. AG-014 controls for critical infrastructure should include physical plausibility checks: responses should be validated not just against schema and behavioural baselines but against physical constraints (e.g., a temperature reading outside the physical range of the sensor should be rejected regardless of schema validity).

Maturity Model

Basic Implementation — The organisation maintains a registry of all external endpoints that each agent is permitted to call. Every response from a registered endpoint is validated against a predefined JSON schema (or equivalent) before being passed to the agent. Responses that fail schema validation are rejected and logged. Calls to unregistered endpoints are blocked. This level meets the minimum mandatory requirements but has gaps: schema validation catches structural deviations but not content manipulation, there is no behavioural baseline to detect subtle changes, and version changes in external APIs may go undetected until they cause a schema validation failure.

Intermediate Implementation — Each external dependency is fingerprinted at registration time: typical response times, value distributions, field cardinality, and content patterns are recorded as a baseline. Ongoing responses are compared against the baseline and statistical deviations trigger alerts. Dependency versions are pinned and monitored — any version change in an external API triggers a review before the agent resumes calling it. Response signatures are verified where the external service supports them. The dependency registry includes trust status (verified, provisional, suspended) and only verified dependencies are permitted for high-consequence actions.

Advanced Implementation — All intermediate capabilities plus: untrusted or newly added integrations execute in a sandboxed environment where their responses are validated against known-good responses before the agent acts on them. The organisation performs periodic adversarial testing of the dependency validation pipeline, including injection of manipulated responses through compromised mock endpoints. Transitive dependency chains are mapped and assessed. The organisation can demonstrate that a compromised external dependency would be detected through behavioural deviation before causing material harm.

7. Evidence Requirements

Required artefacts:

Retention requirements:

Access requirements:

8. Test Specification

Testing AG-014 compliance requires simulating compromised external dependencies across the full range of attack vectors.

Test 8.1: Schema Violation Detection

Test 8.2: Content Manipulation Detection

Test 8.3: Unregistered Endpoint Blocking

Test 8.4: Version Change Detection

Test 8.5: Injection Via External Response

Test 8.6: Behavioural Deviation Detection

Conformance Scoring

9. Regulatory Mapping

RegulationProvisionRelationship Type
SOC 2Vendor Management (Trust Services Criteria)Direct requirement
EU AI ActArticle 9 (Risk Management System — Supply Chain)Direct requirement
NIST AI RMFGOVERN, MAP, MEASURE, MANAGE (Supply Chain Risk)Supports compliance
FCA SYSC8 (Outsourcing)Supports compliance

SOC 2 — Vendor Management (Trust Services Criteria)

SOC 2 Trust Services Criteria include requirements for vendor management and third-party risk assessment. For AI agents that rely on external services, SOC 2 requires that each third-party dependency be assessed for security, availability, and integrity. AG-014 implements the technical controls for this assessment: schema validation verifies response integrity, behavioural fingerprinting monitors ongoing reliability, and the dependency registry provides the inventory required for vendor management reporting. SOC 2 auditors will test whether the organisation has identified all external dependencies, assessed their risk, and implemented monitoring controls.

EU AI Act — Article 9 (Risk Management System — Supply Chain)

The EU AI Act imposes obligations on providers of high-risk AI systems regarding their supply chain. Article 9 requires risk management that covers "risks arising from the interaction of the AI system with the environment within which it operates." For AI agents, external dependencies are the primary interaction with the external environment. The regulation requires that these interactions be subject to risk mitigation measures. AG-014's schema validation, behavioural fingerprinting, and quarantine mechanisms implement these measures. The EU AI Act also requires documentation of the AI system's components and their interactions, which maps to AG-014's dependency registry requirement.

NIST AI RMF — Supply Chain Risk

The NIST AI Risk Management Framework identifies supply chain risk as a key concern for AI systems. The GOVERN function requires organisations to establish policies for AI supply chain risk management. The MAP function requires identification of third-party components and their risk profiles. The MEASURE function requires monitoring of third-party component behaviour. AG-014 directly implements NIST AI RMF requirements: the dependency registry implements GOVERN and MAP, schema validation and behavioural fingerprinting implement MEASURE, and quarantine mechanisms implement MANAGE.

FCA SYSC — 8 (Outsourcing)

FCA SYSC 8 requires firms to take reasonable steps to avoid undue additional operational risk when outsourcing critical functions. For AI agents relying on external APIs and services, each external dependency represents an outsourced function. AG-014's dependency registry, schema validation, and agent monitoring implement the ongoing oversight controls that SYSC 8 requires for outsourced functions.

10. Failure Severity

FieldValue
Severity RatingHigh
Blast RadiusVaries by dependency — a compromised pricing feed affects every pricing decision; a compromised identity verification service affects every onboarding decision; a compromised configuration service could affect the agent's entire operating parameters

Consequence chain: Without external dependency integrity controls, a compromised upstream service can return manipulated data that causes the agent to take actions the deploying organisation never intended — returning inflated prices, false counterparty identities, fabricated regulatory status, or forged instructions. The failure mode is particularly dangerous because the agent itself is functioning correctly. The agent's reasoning is sound, its instructions are intact, and its governance controls (AG-001 mandate enforcement, AG-005 instruction integrity) are all passing. The problem is upstream — the agent is making correct decisions based on incorrect information. This means that standard agent monitoring (risk analysis, instruction verification) will not detect the problem. Only input validation — which AG-014 specifically addresses — can detect the compromise at its source. The blast radius depends on what the compromised dependency provides. The more consequential the dependency, the larger the blast radius of its compromise. In financial services, a compromised pricing feed can cause trading losses at machine speed. In healthcare, a compromised clinical decision support API can affect patient safety. In critical infrastructure, compromised sensor data can lead to unsafe operational decisions.

Cross-reference note: AG-014 validates external data inputs; AG-005 (Instruction Integrity Verification) validates the integrity of instructions that may arrive through external channels. AG-046 (Operating Environment Integrity) governs the runtime environment at the platform layer. AG-048 (AI Model Provenance and Integrity) governs the integrity of the AI model itself, including training data and weight provenance. AG-008 (Governance Continuity Under Failure) governs what happens when a dependency fails entirely. AG-001 (Operational Boundary Enforcement) enforces action boundaries regardless of inputs, providing a backstop when dependency validation fails.

Cite this protocol
AgentGoverning. (2026). AG-014: External Dependency Integrity. The 783 Protocols of AI Agent Governance, AGS v2.1. agentgoverning.com/protocols/AG-014