Third-Party Tool Admission Governance

2. Summary

Third-Party Tool Admission Governance requires that every third-party tool, plugin, library, model, adapter, or external service integrated into an AI agent's operational environment passes through a formal, documented admission process before it is permitted to operate. The admission process evaluates security posture, licence compliance, behavioural predictability, data handling practices, and ongoing maintenance commitment. No third-party component may be integrated into a production agent without explicit approval through this process. The principle is straightforward: the boundary of the agent's trusted execution environment must be a controlled gate, not an open door.

3. Example

Scenario A — Malicious Plugin Admitted Without Review: An AI agent development team discovers an open-source tool-calling plugin on a public registry that provides convenient integration with a popular CRM system. The plugin has 3,200 stars on GitHub and appears well-maintained. A developer adds it to the agent's configuration and deploys to production. The plugin functions correctly for its stated purpose but also exfiltrates all API credentials it encounters to an external endpoint controlled by the plugin author. The exfiltration is discovered 6 weeks later when anomalous outbound network traffic is flagged by the SOC team. By that point, 14 API keys and 3 database credentials have been compromised.

What went wrong: No admission process existed. The developer's assessment — "it has lots of stars" — was the only review. No security analysis, no code review, no network behaviour assessment, and no licence review occurred. A formal admission process would have flagged the outbound network calls to unknown endpoints during sandbox testing. Consequence: 14 compromised API keys, 3 compromised database credentials, estimated 6 weeks of potential data exfiltration, credential rotation across all affected services, incident response costs, regulatory notification under GDPR Article 33 (72-hour window exceeded), and supply-chain integrity review of all other components.

Scenario B — Licence-Incompatible Tool Causes Product Withdrawal: An organisation deploys a customer-facing AI agent incorporating a third-party natural language processing library. The library is functionally excellent and passes all quality benchmarks. It is licensed under the Server Side Public License (SSPL), which requires that any organisation offering the library as part of a managed service must release the complete source code of the service. The organisation's legal team is unaware of this dependency. When a competitor identifies the SSPL component, the organisation must choose between open-sourcing its proprietary agent code or withdrawing the product to replace the library.

What went wrong: No licence review was part of the tool admission process. The SSPL's copyleft provisions — which are specifically designed to restrict SaaS use — were not evaluated against the organisation's intended deployment model. An admission process with licence compatibility checks would have flagged the SSPL component before any development effort was invested. Consequence: Product withdrawal for 8 weeks while the library is replaced, £340,000 in engineering costs for the replacement, 3 customer contract penalties for service interruption, and legal costs for licence compliance review across all other components.

Scenario C — Unmaintained Tool Creates Persistent Vulnerability: An AI agent uses a third-party data transformation plugin that was last updated 18 months ago. The plugin's maintainer has abandoned the project. A vulnerability is discovered in the plugin's XML parsing logic. No patch is available because the project is unmaintained. The organisation cannot update the plugin without forking and maintaining it — a commitment they did not anticipate. Meanwhile, the agent remains vulnerable to XML external entity (XXE) attacks through any data it processes.

What went wrong: The admission process, if one existed, did not assess the maintainer's ongoing commitment or establish criteria for minimum maintenance activity. A maintenance health check at admission would have flagged the low commit frequency, single maintainer, and absence of a security disclosure process. An admission policy requiring a minimum maintenance commitment (e.g., responsive to security issues within 30 days) would have either rejected the tool or required a mitigation plan. Consequence: Persistent XXE vulnerability in production, emergency fork-and-patch effort costing £85,000, and adoption of long-term maintenance burden for a component the organisation did not author.

4. Requirement Statement

Scope: This dimension applies to all third-party components that are integrated into an AI agent's operational environment and can influence the agent's behaviour, outputs, or data handling. "Third-party" means any component not wholly developed, maintained, and controlled by the deploying organisation. This includes: open-source libraries, commercial plugins, model adapters from public registries, external API services, data connectors, tool-calling plugins, embedding models, vector database engines, and any other component where the source code, model weights, or operational logic is controlled by an entity other than the deploying organisation. The scope extends to components accessed via API — even if the component does not run in the organisation's infrastructure, its outputs influence the agent's behaviour and its availability affects the agent's operation.

4.1. A conforming system MUST enforce a formal admission process for all third-party tools, plugins, libraries, models, and external services before they are permitted to operate within any production AI agent environment.

4.2. A conforming system MUST evaluate each candidate third-party component against defined admission criteria covering, at minimum: (a) security posture — known vulnerabilities, code quality indicators, and network behaviour; (b) licence compliance — compatibility with the organisation's deployment model and IP strategy; (c) maintenance health — update frequency, maintainer responsiveness, and security disclosure process; (d) data handling — what data the component accesses, processes, stores, or transmits; and (e) behavioural predictability — whether the component's behaviour is deterministic and observable.

4.3. A conforming system MUST record the admission decision for each component, including the assessment results, the approver, the date, and any conditions or restrictions imposed on the component's use.

4.4. A conforming system MUST maintain an approved component registry listing all components that have passed the admission process, including the approved version, permitted use cases, and any restrictions.

4.5. A conforming system MUST block integration of any third-party component not present in the approved component registry into a production agent environment.

4.6. A conforming system MUST re-evaluate admitted components when a new version is released, when a vulnerability is disclosed, or at minimum annually — whichever occurs first.

4.7. A conforming system SHOULD conduct sandbox testing of candidate components in an isolated environment before admission, observing network behaviour, resource consumption, and data access patterns for a minimum of 48 hours under representative workloads.

4.8. A conforming system SHOULD implement automated pre-admission scanning that checks candidate components against vulnerability databases, licence databases, and known-malware signatures before human review.

4.9. A conforming system SHOULD require that admitted components declare their data access requirements (which data they read, write, store, and transmit) and enforce those declarations at runtime.

4.10. A conforming system MAY implement tiered admission levels (e.g., restricted, standard, trusted) with different levels of access and monitoring based on the component's risk profile and the thoroughness of its admission assessment.

5. Rationale

AI agents are increasingly designed to be extensible — accepting plugins, tools, and adapters that expand their capabilities at runtime. This extensibility is a core architectural feature, but it transforms every plugin slot into an attack surface and every tool integration into a trust decision. When a third-party tool is integrated into an agent, it typically operates with the agent's permissions, accesses the agent's data, and can influence the agent's outputs. A malicious or poorly-secured tool does not need to compromise the agent itself — it is already inside the trust boundary.

The admission process is the primary control that prevents the agent's extensibility from becoming its vulnerability. Without it, the security of the agent depends on the security of the least-reviewed component in its dependency tree. In practice, this means the agent is only as secure as whatever open-source plugin a developer found convenient last Tuesday.

The threat model for third-party tool admission includes: (1) deliberately malicious tools distributed through public registries — supply-chain attacks; (2) legitimate tools with undisclosed vulnerabilities — the most common case; (3) tools that function correctly but have incompatible licence terms; (4) tools whose maintainers abandon the project, leaving vulnerabilities unpatched; and (5) tools that access more data than necessary, creating privacy risk even when functioning as designed.

The admission process is inherently a gate — it slows down the integration of new tools. This is intentional. The cost of evaluating a tool before admission (days to weeks) is orders of magnitude less than the cost of remediating a supply-chain incident after the tool has been operating in production (weeks to months). Organisations that view the admission gate as friction to be minimised are misunderstanding the risk — the gate is not a bottleneck, it is a control.

6. Implementation Guidance

The admission process should be implemented as a defined workflow with clear stages, criteria, and decision authority. It should not be an ad hoc review that varies by reviewer — it should be a repeatable process that produces consistent, auditable outcomes.

Recommended patterns:

• Staged admission pipeline. Implement the admission process as a multi-stage pipeline: (1) automated pre-screening — vulnerability scan, licence check, malware check, and maintenance health indicators; (2) sandbox evaluation — deploy the component in an isolated environment for a minimum of 48 hours under representative workload, monitoring network traffic, resource consumption, and data access; (3) human review — security engineer reviews sandbox results, code quality, and risk assessment; (4) approval — authorised approver grants admission with any conditions or restrictions recorded. Each stage has defined pass/fail criteria. Failure at any stage blocks admission.
• Approved component registry. Maintain a registry of all admitted components including: component name, approved version(s), approval date, approver, conditions, permitted use cases, and next re-evaluation date. The registry is the single source of truth. The CI/CD pipeline checks the registry before deploying any agent — components not in the registry are rejected. The registry integrates with AG-087 (AI-BOM) to verify that deployed agents contain only approved components.
• Declarative data access manifests. Require each third-party component to declare its data access requirements in a machine-readable manifest: what data it reads, what data it writes, where it sends data, and what external endpoints it contacts. During sandbox evaluation, observed behaviour is compared against the declared manifest. Deviations — such as undeclared outbound network calls — are flagged for investigation before admission.
• Risk-tiered admission levels. Not all components pose the same risk. A data formatting library that processes no sensitive data and makes no network calls is lower risk than a tool-calling plugin that accesses customer records and calls external APIs. Implement tiered admission: (a) low-risk components (pure functions, no I/O, permissive licence) receive expedited review; (b) standard-risk components (network access, data processing) receive full pipeline review; (c) high-risk components (access to sensitive data, external API calls, non-standard licences) receive extended review including adversarial testing.

Anti-patterns to avoid:

• Admission by popularity. GitHub stars, download counts, and community adoption are not security indicators. Popular components are attractive targets for supply-chain attacks precisely because they are widely used. Popularity should not substitute for security analysis.
• Admission without sandbox testing. Reviewing source code or documentation alone is insufficient. Many supply-chain attacks are designed to pass code review — obfuscated payloads, time-delayed activation, or behaviour that differs between test and production environments. Sandbox testing under realistic conditions is essential to observe actual behaviour.
• Permanent admission without re-evaluation. A component admitted in 2024 may have new maintainers, new vulnerabilities, or abandoned maintenance by 2025. Admission is not permanent — it requires periodic re-evaluation. Without mandatory re-evaluation, the approved registry becomes a historical record of past assessments rather than a current risk assessment.
• Exemption pathways that bypass the process. An admission process with an "emergency bypass" that is used regularly is not an admission process — it is a suggestion. If the process is too slow for legitimate operational needs, the process should be improved, not bypassed. Every component that bypasses the process is an unassessed risk in production.
• Admission of the component without version pinning. Admitting "library X" without specifying the approved version means that any future version — including compromised versions — is implicitly approved. Admission must be version-specific. A new version requires re-evaluation, even if the previous version was approved.

Industry Considerations

Financial Services. FCA expectations under SYSC 8 (Outsourcing) extend to AI component dependencies. Third-party tools that process financial data or influence financial decisions are functionally equivalent to outsourced services and should be subject to equivalent due diligence. The admission process should align with the firm's existing third-party risk management framework and vendor due diligence standards.

Healthcare. Third-party components integrated into clinical AI agents may constitute part of a medical device under FDA or EU MDR regulations. The admission process must document sufficient information to support regulatory submissions, including component provenance, intended use, and risk assessment. Components that influence clinical outputs require the highest level of admission scrutiny.

Critical Infrastructure. Components integrated into AI agents controlling critical infrastructure must be assessed against IEC 62443 security level requirements. Admission should include evaluation of the component's suitability for the target security level, including resistance to adversarial inputs and fail-safe behaviour under component failure.

Maturity Model

Basic Implementation — The organisation has a documented policy requiring third-party components to be reviewed before use in production agents. Reviews are conducted by development team leads and cover basic licence compatibility and known vulnerability checks. An approved component list exists as a shared document. Compliance is enforced through code review rather than automated pipeline controls.

Intermediate Implementation — The admission process is implemented as a formal pipeline with automated pre-screening (vulnerability scan, licence check, maintenance health metrics), sandbox evaluation in isolated environments, and documented human approval. An approved component registry is maintained as a structured data store integrated with the CI/CD pipeline. Deployment is blocked for components not in the registry. Re-evaluation occurs annually or on vulnerability disclosure. Admission decisions are fully auditable.

Advanced Implementation — All intermediate capabilities plus: declarative data access manifests are required for all components and enforced at runtime. Risk-tiered admission levels provide appropriate scrutiny based on component risk profile. Adversarial testing is conducted for high-risk components. Continuous monitoring compares runtime component behaviour against declared behaviour. The admission pipeline integrates with threat intelligence feeds to automatically flag components associated with known supply-chain campaigns. Average admission cycle time is tracked and optimised to balance security thoroughness with operational velocity.

7. Evidence Requirements

Required artefacts:

• Admission policy document. The formally approved policy defining the admission process, criteria, decision authority, and re-evaluation requirements.
• Admission records. For each admitted component: the assessment results for each criterion (security, licence, maintenance, data handling, behavioural predictability), sandbox evaluation results, the approver identity, the approval date, and any conditions or restrictions.
• Approved component registry. The current registry listing all admitted components with version, approval date, and next re-evaluation date.
• Rejection records. Records of components that were denied admission, including the reason for rejection — these demonstrate that the process has teeth.
• Re-evaluation records. Records of periodic re-evaluations and the outcomes, demonstrating that admission is not permanent and that the registry reflects current assessments.
• Pipeline enforcement evidence. CI/CD logs demonstrating that deployments were blocked when unapproved components were detected.

Retention requirements:

• Admission records and rejection records: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Testing AG-088 compliance requires verifying both the admission process itself and the enforcement mechanisms that prevent unapproved components from reaching production.

Test 8.1: Unapproved Component Blocking

• Stimulus: Attempt to deploy an agent containing a third-party component not present in the approved component registry.
• Expected behaviour: The deployment is blocked before the agent reaches the production environment. A structured rejection identifies the unapproved component.
• Pass criteria: The agent does not deploy. The rejection message names the specific unapproved component and indicates that admission is required.
• Fail criteria: The agent deploys with the unapproved component, or the deployment proceeds without checking the registry.

Test 8.2: Version-Specific Enforcement

• Stimulus: Admit version 2.3.1 of a component. Attempt to deploy an agent containing version 2.4.0 of the same component (unapproved version).
• Expected behaviour: The deployment is blocked because version 2.4.0 has not been admitted, even though version 2.3.1 of the same component is in the registry.
• Pass criteria: Version-specific blocking occurs. The rejection identifies the version mismatch.
• Fail criteria: The deployment proceeds because a different version of the same component is in the registry.

Test 8.3: Admission Criteria Completeness

• Stimulus: Submit a component for admission that passes all criteria except one (e.g., passes security, licence, maintenance, and data handling checks but fails behavioural predictability due to non-deterministic outputs).
• Expected behaviour: The admission process rejects the component or imposes conditions addressing the failing criterion.
• Pass criteria: The component is not admitted unconditionally. The failing criterion is documented in the admission record.
• Fail criteria: The component is admitted despite a failing criterion with no conditions or documentation.

Test 8.4: Sandbox Behaviour Observation

• Stimulus: Submit a test component designed to make undeclared outbound network calls to an external endpoint during sandbox evaluation.
• Expected behaviour: The sandbox monitoring detects the undeclared outbound call and flags it in the evaluation report.
• Pass criteria: The undeclared network call is identified and documented. The admission process flags the discrepancy for investigation.
• Fail criteria: The undeclared network call is not detected, or the component is admitted without the discrepancy being investigated.

Test 8.5: Re-Evaluation Triggering

• Stimulus: Publish a CVE affecting a component that is in the approved registry. Verify that a re-evaluation is triggered.
• Expected behaviour: The system detects the CVE, correlates it with the approved component, and initiates a re-evaluation. The component's status in the registry is updated to reflect the pending re-evaluation.
• Pass criteria: Re-evaluation is triggered within 24 hours of CVE publication. The component's registry status indicates pending re-evaluation.
• Fail criteria: No re-evaluation is triggered, or the component retains its approved status without review.

Test 8.6: Admission Record Auditability

• Stimulus: Request the complete admission record for a randomly selected admitted component.
• Expected behaviour: The record includes: assessment results for all criteria, sandbox evaluation results, approver identity, approval date, conditions, and version approved.
• Pass criteria: All required fields are present and populated. The record is retrievable within 48 hours.
• Fail criteria: Any required field is missing, or the record cannot be located.

Conformance Scoring

• Score 0: No admission process exists — third-party components are integrated into agents without review or approval.
• Score 1: An informal review occurs but is not standardised, not documented, and not enforced by the deployment pipeline — reviews happen but cannot be audited and can be bypassed.
• Score 2: A formal admission process with defined criteria, documented decisions, and pipeline-enforced blocking of unapproved components — structural prevention of unapproved tool integration.
• Score 3: Verified by independent testing demonstrating pipeline enforcement, sandbox detection of undeclared behaviour, version-specific blocking, and re-evaluation triggering — an independent party has confirmed that the admission gate operates as specified.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
EU AI Act	Article 15 (Accuracy, Robustness, Cybersecurity)	Direct requirement
DORA	Article 28 (Register of ICT Third-Party Arrangements)	Direct requirement
DORA	Article 30 (Key Contractual Provisions)	Supports compliance
FCA SYSC	8 (Outsourcing)	Supports compliance
NIST AI RMF	GOVERN 1.4, MAP 3.2, MANAGE 2.3	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks), Annex A.8 (Third-Party Management)	Supports compliance
NIS2 Directive	Article 21 (Cybersecurity Risk-Management Measures)	Supports compliance

EU AI Act — Article 15 (Accuracy, Robustness, Cybersecurity)

Article 15 requires that high-risk AI systems achieve an appropriate level of cybersecurity and are resilient against attempts by third parties to exploit vulnerabilities, including supply-chain attacks. The admission process directly implements cybersecurity resilience for the supply chain — by preventing unapproved components from entering the agent's trust boundary, the organisation reduces the attack surface available to supply-chain adversaries. The requirement for robustness further supports admission testing, as components that introduce non-deterministic or unpredictable behaviour compromise the system's robustness.

DORA — Article 28 and Article 30

Article 28 requires the register of ICT third-party arrangements; Article 30 specifies key contractual provisions for ICT services. For AI agents, each admitted third-party component represents an ICT third-party arrangement. The admission process generates the information required for the Article 28 register, and the admission criteria should align with the contractual provisions specified in Article 30, including security requirements, audit rights, and exit provisions.

FCA SYSC — 8 (Outsourcing)

SYSC 8 requires firms to undertake due diligence on service providers and ensure appropriate oversight. Third-party components that process financial data or influence financial decisions within AI agents are functionally equivalent to outsourced functions. The admission process implements the due diligence requirement, and the ongoing re-evaluation requirement implements the oversight obligation.

NIS2 Directive — Article 21

Article 21 requires essential and important entities to implement supply-chain security measures. The admission process directly implements supply-chain security for AI agent components, ensuring that components entering the agent's operational environment have been assessed for security risks.

NIST AI RMF — GOVERN 1.4, MAP 3.2, MANAGE 2.3

GOVERN 1.4 addresses third-party governance within the AI lifecycle; MAP 3.2 addresses understanding AI system dependencies; MANAGE 2.3 addresses risk mitigation through controls. The admission process implements governance over third-party components, maps dependencies through the evaluation process, and manages risks through the admission gate.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Organisation-wide — potentially cross-organisation where admitted tools process data from or send data to external parties

Consequence chain: Without a formal admission process, the organisation's AI agent security depends entirely on the judgement of individual developers selecting components. A single malicious or vulnerable component admitted without review can compromise the agent's data, credentials, and outputs. The failure mode is a permeable trust boundary — the agent's extensibility becomes its vulnerability. A supply-chain attack through an unapproved tool operates with the agent's full permissions, accessing whatever data and systems the agent can access. The blast radius scales with the agent's access scope and the number of agents that incorporate the compromised component. For organisations with multiple agents sharing common tool plugins, a single compromised tool can affect every agent simultaneously. The business consequence includes: data exfiltration (GDPR/CCPA notification obligations, potential fines up to 4% of global annual turnover under GDPR), credential compromise (cascading access to connected systems), output manipulation (agent producing incorrect results based on compromised tool outputs), and regulatory enforcement for inadequate supply-chain controls. The reputational damage of a supply-chain incident in a customer-facing AI agent — where the agent's compromised behaviour directly affects customers — can exceed the direct financial loss by an order of magnitude.

Cross-references: AG-087 (AI Component Bill of Materials Governance) provides the inventory that the admission process populates and maintains. AG-014 (External Dependency Integrity) provides integrity verification for admitted components. AG-048 (AI Model Provenance and Integrity) provides model-specific provenance checks that complement the admission criteria. AG-089 (Third-Party Tool Revocation Governance) governs the removal of tools that fail re-evaluation or are found to be compromised after admission. AG-006 (Tamper-Evident Record Integrity) protects the integrity of admission records. AG-007 (Governance Configuration Control) governs changes to the admission policy itself. AG-022 (Behavioural Drift Detection) monitors admitted tools for post-admission behavioural changes.