Secure Model Artifact Transport Governance

2. Summary

Secure Model Artifact Transport Governance requires that every model file, policy bundle, configuration payload, and governance artefact moved between environments — whether across networks, between regions, from build systems to staging, or from staging to production — is protected against tampering, interception, and substitution throughout transit. The protection must be structural and cryptographic: transport encryption, integrity verification at origin and destination, and chain-of-custody attestation that records who or what initiated the transfer, the route taken, and whether the artefact arrived unmodified. Without this dimension, an organisation cannot distinguish a legitimately promoted model from one that has been intercepted and replaced mid-transit, rendering all upstream governance controls — training provenance, evaluation results, approval workflows — meaningless once the artefact leaves its origin environment.

3. Example

Scenario A — Model File Substitution During Cross-Environment Promotion: An organisation trains and evaluates a large language model fine-tune for customer service. The model passes all safety evaluations in the staging environment and receives approval for production deployment. The promotion pipeline copies the model weights file (14 GB) from the staging object store to the production object store over an internal network. An attacker who has compromised a network appliance on the transfer path intercepts the file stream and substitutes a modified weights file that includes a backdoor causing the model to exfiltrate customer data when specific trigger phrases are used. The production environment loads the substituted file. No integrity check is performed at the destination because the pipeline trusts the internal network. The backdoor operates undetected for 11 days before anomalous outbound data volumes trigger a security alert.

What went wrong: The transfer relied on network-level trust rather than cryptographic integrity verification. The model file was not signed at the origin, and no hash comparison was performed at the destination. The 14 GB file was treated as trusted because it arrived over an internal network path. Consequence: 11 days of customer data exfiltration affecting approximately 340,000 customer records, GDPR Article 33 breach notification obligation triggered, regulatory fine of EUR 4.2 million, class action litigation, and complete retraining and re-evaluation cycle costing approximately GBP 1.8 million in compute and staff time.

Scenario B — Policy Configuration Tampering During Multi-Region Sync: A financial services firm deploys identical governance policy bundles across three geographic regions (EU, US-East, APAC). Policy bundles — containing action limits, counterparty whitelists, and escalation thresholds — are synchronised every six hours via a replication job that pulls from a central policy repository. An insider with access to the replication infrastructure modifies the APAC policy bundle during transit, raising the per-transaction limit from USD 50,000 to USD 5,000,000 and adding three unauthorised counterparty addresses. The modified policy activates in the APAC region. Over the next synchronisation cycle, an agent in the APAC region executes seven transactions totalling USD 23.4 million to the unauthorised counterparties before the discrepancy is detected during a manual quarterly review.

What went wrong: Policy bundles were not cryptographically signed at the origin repository. The replication job verified only that the file transfer completed (size and checksum of the compressed archive) but did not verify content integrity against a signature from the policy authority. No destination-side attestation compared the received bundle against the authoritative version. Consequence: USD 23.4 million in fraudulent transfers, regulatory investigation by MAS and the FCA for inadequate cross-border controls, personal liability for the Senior Manager responsible for the APAC operation under the Senior Managers Regime.

Scenario C — Stale Artifact Replay in Edge Deployment Pipeline: An organisation deploys quantised model artefacts to 2,400 edge devices running in retail locations. A deployment pipeline pushes updated models monthly. An attacker gains access to the artefact distribution cache and replaces the current model version (v3.7, which includes critical safety guardrails) with a cached copy of an earlier version (v2.1, which lacks those guardrails) by replaying a previously valid signed artefact. Because the deployment pipeline verifies the cryptographic signature — and v2.1 was legitimately signed at the time of its release — the signature check passes. The edge devices accept and load the downgraded model. The missing guardrails lead to the generation of harmful content in 847 customer interactions before the version discrepancy is noticed.

What went wrong: The integrity verification checked only that the artefact was authentically signed, not that it was the correct version for the current deployment. No version-binding or freshness attestation was included in the transport verification. The system was protected against substitution with unsigned artefacts but not against replay of previously valid artefacts. Consequence: 847 harmful customer interactions, brand damage, regulatory inquiry into content safety controls, emergency recall and re-deployment across 2,400 devices costing approximately GBP 420,000 in operational effort.

4. Requirement Statement

Scope: This dimension applies to every transfer of model artefacts, governance policy bundles, agent configuration payloads, fine-tuning datasets, evaluation result packages, and any other file or data structure that influences the behaviour of an AI agent when that transfer crosses an environment boundary. An environment boundary includes: build-to-staging, staging-to-production, region-to-region, cloud-to-edge, on-premise-to-cloud, and any transfer between distinct trust domains even within a single data centre if the transfer traverses infrastructure not under the exclusive control of the governance authority. Intra-process transfers within a single runtime (e.g., loading a model from local disk within the same container) are excluded, provided the local storage itself is integrity-protected. The scope extends to partial transfers: incremental model updates, delta policy patches, and configuration overlays are all within scope because a tampered delta can compromise the resulting state as effectively as a tampered full artefact.

4.1. A conforming system MUST encrypt all model artefact and policy bundle transfers in transit using transport-layer encryption with a minimum of TLS 1.2 or equivalent, with cipher suites that provide forward secrecy.

4.2. A conforming system MUST generate a cryptographic signature over every artefact at the point of origin, using a signing key held in a hardware security module or equivalent tamper-resistant key store, before the artefact leaves the origin environment.

4.3. A conforming system MUST verify the cryptographic signature of every artefact at the destination environment before the artefact is loaded, activated, or made available to any agent runtime.

4.4. A conforming system MUST reject any artefact whose signature verification fails and generate an alert to the security operations function within 60 seconds of the rejection.

4.5. A conforming system MUST bind the artefact signature to a specific version identifier, target environment identifier, and validity window, such that a legitimately signed artefact cannot be replayed to a different environment or after its validity window has expired.

4.6. A conforming system MUST maintain a chain-of-custody log for every artefact transfer, recording: the artefact identifier, the origin environment, the destination environment, the initiating principal (human or automated), the timestamp of dispatch and receipt, the hash of the artefact at origin and destination, and the signature verification result.

4.7. A conforming system MUST block artefact activation in the destination environment if the chain-of-custody log entry is incomplete, missing, or records a verification failure.

4.8. A conforming system SHOULD implement mutual authentication between origin and destination environments, such that the destination verifies the origin's identity and the origin verifies the destination's identity before transfer begins.

4.9. A conforming system SHOULD implement bandwidth and rate controls on artefact transfer channels to detect and prevent bulk exfiltration of model intellectual property.

4.10. A conforming system SHOULD use content-addressable storage for artefact repositories, where the storage key is derived from the artefact's cryptographic hash, preventing silent replacement of stored artefacts.

4.11. A conforming system MAY implement artefact transfer via air-gapped or out-of-band channels for the highest-sensitivity deployments, where the transfer medium is physically transported between environments.

4.12. A conforming system MAY implement incremental artefact transfer with Merkle tree verification, where each chunk of a large artefact is independently verifiable against the root hash.

5. Rationale

Model artefacts and governance policy bundles are the most consequential data objects in an AI agent deployment. A model file defines the agent's capabilities and behavioural tendencies. A policy bundle defines the governance constraints that bound those capabilities. A configuration payload determines how the agent interacts with external systems. If any of these objects is modified, substituted, or downgraded during transport between environments, the entire governance posture of the deployment is compromised — regardless of how rigorous the upstream controls were. An organisation that invests heavily in model evaluation, safety testing, and approval workflows but does not protect the artefact during transport has built a fortress with an unguarded gate.

The threat landscape for artefact transport is broad and well-documented in adjacent domains. Supply chain attacks against software artefacts — such as the SolarWinds incident in 2020, the Codecov breach in 2021, and the XZ Utils compromise in 2024 — demonstrate that sophisticated adversaries routinely target the transport and distribution layer rather than the build or runtime layer. AI model artefacts present an even more attractive target because: (a) model files are large and binary, making manual inspection impractical; (b) subtle modifications to model weights can introduce backdoors that are undetectable by standard functional testing; (c) policy bundles are typically small configuration files where a single changed value (e.g., a transaction limit) can have disproportionate operational impact; and (d) many organisations treat internal network transfers as inherently trusted, creating a gap between the security of external-facing transfers and internal promotions.

The regulatory environment increasingly requires organisations to demonstrate end-to-end integrity of AI systems. The EU AI Act Article 15 requires that high-risk AI systems achieve "an appropriate level of accuracy, robustness and cybersecurity" and that cybersecurity measures address "threats and vulnerabilities specific to the AI system." Artefact substitution during transport is a threat specific to AI systems. DORA Article 9 requires financial entities to manage ICT risks including data integrity risks across all environments. ISO 42001 Clause 8.4 addresses the integrity of AI system components throughout the lifecycle, including deployment. NIST AI RMF MANAGE 2.4 addresses the management of AI system integrity. Organisations that cannot demonstrate cryptographic protection of artefacts in transit will face increasing regulatory scrutiny as AI deployment matures.

The distinction between transport encryption and artefact integrity is critical. TLS protects the channel — it prevents eavesdropping and man-in-the-middle modification during the network transfer. But TLS terminates at endpoints. If the artefact is compromised before entering the TLS channel (e.g., at a compromised build server) or after leaving it (e.g., in a compromised staging cache), TLS provides no protection. Cryptographic signing of the artefact at the point of authoritative creation protects the artefact itself, not just the channel. The signature travels with the artefact and can be verified at any point in the chain of custody, providing end-to-end integrity that transport encryption alone cannot achieve.

6. Implementation Guidance

AG-405 establishes the principle that model artefacts, policy bundles, and configuration payloads are treated as high-value, integrity-critical data objects throughout their lifecycle — but particularly during the vulnerable window when they are in transit between environments. The governance objective is to ensure that the artefact loaded into a production agent runtime is bit-for-bit identical to the artefact that was approved for deployment, and that this identity can be independently verified at any time by examining the chain-of-custody record.

Implementation begins with establishing a signing authority — a service or process that holds the artefact signing keys in a hardware security module and is authorised to sign artefacts that have passed the organisation's approval gates. The signing authority should be architecturally separate from the build pipeline and the deployment pipeline, so that compromise of either pipeline does not grant access to signing keys. The signing process should bind metadata — version identifier, target environment, validity window, and a reference to the approval record — into the signed payload, so that a signature attests not only to the artefact's content but to its authorised context.

Recommended patterns:

• Signed manifest with detached signatures. Generate a manifest file listing every artefact in a deployment package along with its cryptographic hash (SHA-256 minimum). Sign the manifest using the signing authority's key. Distribute the manifest and its detached signature alongside the artefact package. At the destination, verify the manifest signature first, then verify each artefact's hash against the manifest. This pattern is efficient for multi-file deployments and allows partial verification if only some artefacts are updated.
• Notary service with transparency log. Operate a notary service that records every signed artefact in an append-only transparency log (similar to Certificate Transparency or Sigstore's Rekor). The destination environment verifies the artefact signature and additionally confirms that the signature is recorded in the transparency log. This prevents the signing authority from being coerced into signing an unauthorised artefact without the signature being publicly visible. The transparency log provides an auditable record that is independent of the signing authority itself.
• Environment-bound transfer tokens. Before an artefact transfer begins, the destination environment requests a transfer token from a central governance service, specifying the expected artefact identifier, version, and hash. The governance service issues a time-limited, single-use token bound to those parameters. The origin environment includes the token in the transfer metadata. The destination environment validates the token before accepting the artefact. This prevents artefacts from being pushed to environments that have not requested them and prevents replay of transfers to different environments.
• Hardware-attested transfer channels. In deployments using hardware enclaves (AG-400), establish attested channels where both origin and destination enclaves perform remote attestation before the transfer begins. The artefact is encrypted to the destination enclave's attestation-bound key, ensuring that only the intended enclave can decrypt it. This pattern provides the strongest protection against man-in-the-middle attacks and is particularly suitable for edge deployments where the destination environment may be in a physically insecure location.

Anti-patterns to avoid:

• Relying solely on transport encryption. TLS protects the channel but not the artefact. If the artefact is compromised before entering or after leaving the TLS tunnel, transport encryption provides no protection. TLS is necessary but not sufficient.
• Signing artefacts in the build pipeline without key isolation. If the signing key is accessible to the build pipeline — stored as an environment variable, mounted as a file, or accessible via a service account — then compromise of the build pipeline grants the ability to sign arbitrary artefacts. The signing key must be isolated in a hardware security module or equivalent tamper-resistant store, with access controlled by a separate authentication mechanism.
• Verifying signatures but not version binding. Checking that an artefact was signed by a trusted authority is necessary but insufficient. Without binding the signature to a specific version, environment, and validity window, a legitimately signed but outdated or misrouted artefact can pass verification. This is the replay attack vector demonstrated in Scenario C.
• Treating internal network transfers as trusted. The assumption that artefacts transferred over internal networks do not require integrity verification is contradicted by the history of supply chain attacks. Internal networks are routinely compromised. Integrity verification must apply to all transfers that cross an environment boundary, regardless of whether the network path is internal or external.
• Logging transfers without enforcing log completeness. Maintaining a chain-of-custody log is valuable only if the system enforces that every transfer produces a complete log entry. A log that is best-effort — sometimes complete, sometimes missing entries — provides false assurance. The enforcement must be structural: the artefact cannot be activated until the log entry is confirmed complete and consistent.

Industry Considerations

Financial Services. Model artefacts used in trading, credit scoring, or fraud detection carry direct financial and regulatory risk. The FCA expects firms to demonstrate that models deployed in production are the same models that were validated — a requirement that is meaningless without artefact integrity verification. Firms should align artefact transport controls with existing software change management procedures under SYSC 6.1.1R and DORA Article 9. Cryptographic signatures on model artefacts provide the auditable evidence trail that regulators expect.

Healthcare and Life Sciences. Models used in clinical decision support or diagnostic assistance are subject to medical device regulations in many jurisdictions. The integrity of the deployed model is a safety requirement — a substituted or corrupted model could produce incorrect diagnoses. FDA guidance on Software as a Medical Device (SaMD) requires that manufacturers demonstrate control over the software that is deployed to end users. Artefact signing and verification directly supports this requirement.

Edge and Robotic Deployments. Organisations deploying models to edge devices or robotic systems face additional challenges: devices may be in physically insecure locations, network connectivity may be intermittent, and devices may have limited computational resources for signature verification. Implementations should consider pre-provisioning verification keys in hardware, using lightweight signature schemes, and implementing store-and-verify patterns where the artefact is downloaded opportunistically but verified before activation.

Cross-Border Deployments. Artefact transfers between jurisdictions may be subject to export control regulations (particularly for models with dual-use potential), data sovereignty requirements (where model weights encode training data characteristics), and varying encryption standards. Organisations should consult legal counsel on whether specific artefact transfers constitute controlled technology exports.

Maturity Model

Basic Implementation — The organisation encrypts all artefact transfers using TLS 1.2 or later. Artefact hashes (SHA-256) are generated at the origin and verified at the destination. Hash values are communicated out-of-band (e.g., via a separate metadata channel or configuration management system). Transfer events are logged with timestamps and hash verification results. This level provides protection against passive eavesdropping and accidental corruption but does not protect against an attacker who can modify both the artefact and its hash, as the hash is not cryptographically signed.

Intermediate Implementation — All basic capabilities plus: artefacts are cryptographically signed at the origin using keys held in a hardware security module. Signatures are bound to version identifiers, target environments, and validity windows. Destination environments verify signatures before activation and reject artefacts with invalid, expired, or misbound signatures. Chain-of-custody logs are maintained with structural enforcement — artefacts cannot be activated without a complete, verified log entry. Mutual authentication is implemented between origin and destination environments.

Advanced Implementation — All intermediate capabilities plus: artefact signatures are recorded in an append-only transparency log that is independently auditable. Hardware-attested transfer channels are used for the highest-sensitivity artefacts. Merkle tree verification enables incremental and resumable transfers of large artefacts. Automated monitoring detects anomalous transfer patterns (unexpected source environments, unusual artefact sizes, transfers outside maintenance windows). The organisation has conducted red-team exercises specifically targeting the artefact transport layer and can demonstrate that all identified attack vectors are mitigated. Artefact provenance is traceable from training data through build, evaluation, approval, and deployment.

7. Evidence Requirements

Required artefacts:

• Signing authority configuration. Documentation of the signing authority architecture, including the hardware security module deployment, key management procedures, key rotation schedule, and access control policies. Not a description of the intended architecture — the actual deployed configuration.
• Signed artefact samples. Examples of signed model artefacts and policy bundles demonstrating the signature format, bound metadata (version, environment, validity window), and verification procedure. Minimum of one sample per artefact type in active use.
• Chain-of-custody logs. Complete chain-of-custody records for all artefact transfers over the retention period, showing artefact identifier, origin, destination, initiating principal, timestamps, hashes, and verification results. Logs must demonstrate structural completeness — no gaps or missing entries for known transfers.
• Signature verification failure records. All instances where signature verification failed at a destination, including the artefact identifier, the nature of the failure (invalid signature, expired validity, environment mismatch, hash mismatch), the alert generated, and the remediation action taken.
• Adversarial test results. Results from testing that specifically targeted the artefact transport layer, including: artefact substitution attempts, signature bypass attempts, replay attacks with previously valid artefacts, and man-in-the-middle attacks on transfer channels.

Retention requirements:

• Signing authority configuration and key management records: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.
• Chain-of-custody logs and verification failure 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. Chain-of-custody logs must be queryable by artefact identifier, time range, environment, and verification status. Evidence must exist as retained artefacts, not be reconstructable after the fact.

8. Test Specification

Testing AG-405 compliance requires verifying that artefact integrity is maintained across all transport paths, that verification failures are detected and blocked, and that chain-of-custody records are structurally complete.

Test 8.1: Transport Encryption Enforcement

• Stimulus: Attempt to initiate an artefact transfer between environments using an unencrypted channel (plaintext HTTP, unencrypted FTP, or a TLS connection with a cipher suite that does not provide forward secrecy). Additionally, attempt a transfer using TLS 1.0 or TLS 1.1.
• Expected behaviour: The transfer is refused at the transport layer. No artefact data is transmitted over the non-compliant channel.
• Pass criteria: All transfer attempts over non-compliant channels are rejected before any artefact data is transmitted. Only TLS 1.2+ with forward-secrecy cipher suites are accepted.
• Fail criteria: Any artefact data is transmitted over an unencrypted or non-compliant channel, or a downgrade attack succeeds in negotiating a weaker protocol.

Test 8.2: Origin Signature Generation and Key Isolation

• Stimulus: Trigger an artefact promotion from a build or staging environment to a downstream environment. Inspect the resulting artefact package for a cryptographic signature. Attempt to access the signing key from within the build pipeline environment (via environment variables, file system, service account credentials, or metadata service).
• Expected behaviour: The artefact is signed with a valid cryptographic signature. The signing key is not accessible from within the build pipeline environment.
• Pass criteria: The artefact carries a valid signature generated by the signing authority's HSM-held key. No method of accessing the signing key from the build pipeline environment succeeds.
• Fail criteria: The artefact is unsigned, or the signing key is accessible from within the build pipeline environment through any method.

Test 8.3: Destination Signature Verification and Rejection

• Stimulus: Deliver three artefacts to the destination environment: (a) a correctly signed artefact, (b) an artefact with a corrupted signature (one bit flipped in the signature block), and (c) an artefact with no signature. Monitor whether each artefact is loaded, activated, or made available to any agent runtime. Monitor alerting for rejected artefacts.
• Expected behaviour: Artefact (a) passes verification and is available for activation. Artefacts (b) and (c) are rejected before any agent runtime can access them. Security alerts are generated within 60 seconds for both rejections.
• Pass criteria: Only the correctly signed artefact is activatable. Both invalid artefacts are rejected and alerts are generated within 60 seconds.
• Fail criteria: An unsigned or incorrectly signed artefact is loaded, activated, or accessible to any agent runtime, or alerts are not generated within 60 seconds of rejection.

Test 8.4: Version Binding and Replay Prevention

• Stimulus: Obtain a legitimately signed artefact from a previous version (v-1). Attempt to deploy it to the current environment by presenting it as the current version. Separately, obtain a legitimately signed artefact bound to environment A and attempt to deploy it to environment B. Finally, obtain a legitimately signed artefact and attempt to deploy it after its validity window has expired.
• Expected behaviour: All three attempts are rejected. The version mismatch, environment mismatch, and expired validity window are each detected during signature verification.
• Pass criteria: All three replay or misdirection attempts are rejected with specific error codes identifying the nature of the binding failure (version mismatch, environment mismatch, validity expired).
• Fail criteria: Any artefact with a mismatched version, environment, or expired validity window passes verification and is accepted for activation.

Test 8.5: Chain-of-Custody Log Completeness Enforcement

• Stimulus: Execute a valid artefact transfer but intercept the chain-of-custody log write (simulate a logging service failure) so that the log entry is incomplete or missing. Attempt to activate the artefact in the destination environment.
• Expected behaviour: The artefact is not activatable because the chain-of-custody log entry is incomplete. The system blocks activation and generates an alert indicating the missing log entry.
• Pass criteria: Artefact activation is blocked when the chain-of-custody log entry is incomplete or missing. No agent runtime can access the artefact until the log entry is resolved.
• Fail criteria: The artefact is activated despite an incomplete or missing chain-of-custody log entry.

Test 8.6: Artefact Substitution Mid-Transit

• Stimulus: Initiate a legitimate artefact transfer. During transit, intercept the data stream (using a network proxy or test harness) and substitute a different artefact of the same size with different content. Allow the modified stream to arrive at the destination.
• Expected behaviour: The destination environment detects the substitution during signature verification (the substituted content does not match the signed hash). The artefact is rejected and an alert is generated.
• Pass criteria: The substituted artefact fails signature verification and is rejected. An alert is generated within 60 seconds.
• Fail criteria: The substituted artefact passes verification, or the substitution is not detected.

Test 8.7: Alert Timeliness on Verification Failure

• Stimulus: Deliver an artefact with an invalid signature to the destination environment. Measure the time between the verification failure and the arrival of the alert at the security operations function.
• Expected behaviour: The alert arrives within 60 seconds of the verification failure, containing the artefact identifier, the nature of the failure, and the source of the transfer.
• Pass criteria: Alert is received within 60 seconds with complete diagnostic information.
• Fail criteria: Alert is not received within 60 seconds, or the alert lacks sufficient information to identify the artefact, the failure type, or the transfer source.

Conformance Scoring

• Score 0: No artefact integrity controls — model files and policy bundles are transferred between environments without encryption, signing, or verification.
• Score 1: Transport encryption is in place (TLS), and artefact hashes are checked at the destination, but artefacts are not cryptographically signed and there is no chain-of-custody log.
• Score 2: Artefacts are cryptographically signed at the origin with HSM-held keys, verified at the destination with version and environment binding, and chain-of-custody logs are maintained with structural enforcement.
• Score 3: Verified by independent adversarial testing — red-team exercises specifically targeting artefact transport have been conducted, transparency logging is operational, and all identified attack vectors (substitution, replay, downgrade, key compromise) are mitigated.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 15 (Accuracy, Robustness and Cybersecurity)	Direct requirement
EU AI Act	Article 9 (Risk Management System)	Supports compliance
SOX	Section 404 (Internal Controls Over Financial Reporting)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Supports compliance
NIST AI RMF	MANAGE 2.4, MAP 3.5	Supports compliance
ISO 42001	Clause 8.4 (AI System Lifecycle Processes)	Supports compliance
DORA	Article 9 (ICT Risk Management Framework)	Direct requirement

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

Article 15(1) requires that high-risk AI systems achieve "an appropriate level of accuracy, robustness and cybersecurity" and that they be "designed and developed in such a way that they achieve those levels." Article 15(4) specifically addresses cybersecurity, requiring that "the technical solutions aimed at ensuring the cybersecurity of high-risk AI systems shall be appropriate to the relevant circumstances and the risks." For AI agents deployed in high-risk domains, the transport of model artefacts between environments is a cybersecurity surface that must be addressed. An artefact substitution attack during transport directly undermines the accuracy and robustness of the deployed system because the deployed model is no longer the model that was evaluated and approved. AG-405 implements the technical solution for this specific threat vector.

EU AI Act — Article 9 (Risk Management System)

Article 9 requires a continuous risk management process that identifies and mitigates risks. Artefact tampering during transport is an identified risk that must be addressed within the risk management system. The chain-of-custody log required by AG-405 provides the evidentiary basis for demonstrating that this risk is managed.

SOX — Section 404 (Internal Controls Over Financial Reporting)

For AI agents involved in financial operations — pricing, trading, credit decisions, or reporting — the integrity of the deployed model directly affects financial reporting accuracy. If a model artefact is substituted during transport, the financial outputs produced by the substituted model are unreliable. SOX Section 404 requires management to assess the effectiveness of internal controls, which for AI-driven financial processes must include controls over the integrity of the model artefact from approval through deployment. An auditor evaluating AI-related controls will ask how the organisation ensures that the model in production is the model that was approved. AG-405 provides the structural answer.

FCA SYSC — 6.1.1R (Systems and Controls)

SYSC 6.1.1R requires firms to maintain adequate systems and controls. For firms deploying AI agents, the transport of model artefacts is a system boundary that must be controlled. The FCA's SS1/23 on model risk management expects firms to demonstrate control over model deployment processes. Cryptographic signing and chain-of-custody logging provide the auditable controls that the FCA expects to see during supervisory assessments.

NIST AI RMF — MANAGE 2.4, MAP 3.5

MANAGE 2.4 addresses mechanisms for tracking and managing identified AI risks over time. MAP 3.5 addresses the AI system's deployment environment and associated risks. AG-405 implements risk management for the deployment environment by ensuring that the artefact integrity is maintained during the deployment process. The chain-of-custody log provides the tracking mechanism referenced in MANAGE 2.4.

ISO 42001 — Clause 8.4 (AI System Lifecycle Processes)

Clause 8.4 requires organisations to establish processes for managing AI systems throughout their lifecycle, including deployment. Artefact transport integrity is a deployment-phase control that ensures the AI system deployed into production is consistent with the AI system that was evaluated and approved. The signing, verification, and chain-of-custody requirements of AG-405 directly implement the lifecycle integrity requirements of Clause 8.4.

DORA — Article 9 (ICT Risk Management Framework)

Article 9 requires financial entities to have an ICT risk management framework that includes policies and procedures for managing ICT-related risks. The transport of AI model artefacts between environments is an ICT process that must be protected against unauthorised modification. DORA's emphasis on digital operational resilience requires that artefact transport failures (including integrity failures) be detected and managed, which AG-405 addresses through mandatory verification, alerting, and chain-of-custody logging.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Full deployment scope — every agent runtime that loads the compromised artefact is affected; cross-organisational where artefacts are shared with partners, customers, or edge deployments

Consequence chain: A failure of artefact transport governance allows an adversary — or an accidental corruption event — to replace a validated, approved model or policy with an unvalidated, unapproved, or maliciously modified version. The immediate technical impact is that the deployed agent operates with different capabilities, constraints, or behaviours than what was approved. For model artefact substitution, the agent may produce subtly incorrect outputs (affecting financial decisions, clinical recommendations, or safety assessments) or contain backdoors that activate under specific conditions. For policy bundle substitution, the agent may operate with relaxed governance constraints — higher transaction limits, broader counterparty access, disabled escalation triggers — that the organisation has not approved. The operational impact depends on the scope of deployment: a single production instance affects one environment, but a compromised artefact that propagates through a distribution network (e.g., to 2,400 edge devices or across three geographic regions) amplifies the impact proportionally. The business consequence includes: material financial loss from operations conducted under compromised governance constraints; regulatory enforcement action for failure to maintain model integrity and adequate systems and controls; data protection violations if a substituted model exfiltrates data; personal liability for senior managers who certified the adequacy of deployment controls; and the cost of incident response, forensic investigation, model re-validation, and re-deployment across all affected environments, which can extend into weeks and millions in direct costs. The reputational consequence is severe because artefact substitution attacks undermine trust in the entire AI deployment pipeline, not just the specific instance that was compromised.