Build Pipeline Attestation Governance

2. Summary

Build Pipeline Attestation Governance requires that every software delivery pipeline producing artefacts deployed into AI agent environments generates cryptographically signed attestations proving the provenance, integrity, and policy compliance of each build step. The pipeline is the boundary between source code — which is reviewed, version-controlled, and auditable — and runtime artefacts that actually execute in production. Without attestation of what happened inside the pipeline, an organisation cannot prove that the binary running in production was produced from the source code it claims, by the pipeline it claims, with the controls it claims. This dimension mandates that every material build step — source checkout, dependency resolution, compilation, testing, packaging, and signing — produces a verifiable attestation record, and that deployment is gated on the completeness and validity of the full attestation chain.

3. Example

Scenario A — Compromised Build Agent Injects Malicious Code: A financial-value AI agent processes trade execution decisions. The organisation maintains rigorous code review: every change requires two approvals before merge. However, the build pipeline runs on a shared build agent pool. An attacker compromises one build agent and modifies the compilation step to inject a 14-line function that exfiltrates model parameters and inference requests to an external endpoint. Because the pipeline produces only a final container image hash with no per-step attestation, the injected code is invisible — it does not appear in any reviewed source code, yet it executes in production. The compromise persists for 11 weeks. During that period, 2.3 million inference requests containing client portfolio data are exfiltrated. The breach is discovered only when a network monitoring tool flags unusual outbound traffic patterns.

What went wrong: The pipeline had no build-step attestation. The organisation could verify what source code was committed but could not verify what actually happened during the build. The gap between "reviewed source" and "deployed binary" was unattested and therefore unauditable. Consequence: 11 weeks of data exfiltration, regulatory notification to 14,000 affected clients, £2.8 million in remediation and legal costs, FCA enforcement action for inadequate systems and controls.

Scenario B — Dependency Substitution During Build: An enterprise workflow agent relies on a natural language processing library. During the build, the dependency resolution step fetches packages from an internal registry that mirrors a public repository. An attacker publishes a package with the same name but a higher version number on the public repository — a dependency confusion attack. The build pipeline, configured to prefer higher versions, fetches the attacker's package instead of the internal one. The substituted package contains a backdoor that modifies the agent's output formatting to include hidden instructions. Because the pipeline has no attestation verifying which dependencies were resolved and from which sources, the substitution is not detected. The compromised agent operates for 6 weeks, processing 47,000 enterprise workflow requests with subtly manipulated outputs.

What went wrong: The dependency resolution step produced no attestation recording the resolved dependency graph, package sources, and integrity hashes. A per-step attestation of the dependency resolution would have recorded the unexpected source registry and triggered a policy violation. Consequence: 6 weeks of compromised agent outputs, £890,000 in incident response costs, 47,000 potentially tainted workflow decisions requiring manual review.

Scenario C — Unauthorised Pipeline Modification Bypasses Testing: A safety-critical AI agent controlling industrial process parameters is built through a six-stage pipeline: source checkout, dependency resolution, compilation, unit testing, integration testing, and packaging. A developer with pipeline administrative access modifies the pipeline configuration to skip the integration testing stage — initially as a temporary measure to meet a deadline, but the modification is never reverted. Subsequent builds skip integration tests for 4 months. A regression in the agent's temperature-threshold logic is introduced and deployed to production without detection. The agent permits a 23-degree-Celsius exceedance of a safe operating parameter, causing equipment damage estimated at £1.4 million and a 9-day production shutdown.

What went wrong: The pipeline configuration change was not attested or audited. No deployment gate verified that all required pipeline stages had executed and attested their completion. The absence of the integration testing attestation should have blocked deployment. Consequence: Equipment damage of £1.4 million, 9-day production shutdown with £3.2 million in lost output, regulatory investigation by the safety authority.

4. Requirement Statement

Scope: This dimension applies to every software delivery pipeline that produces artefacts deployed into AI agent runtime environments — including but not limited to application binaries, container images, model weight packages, configuration bundles, inference service deployments, and infrastructure-as-code templates. It covers the full pipeline lifecycle from source material ingestion to artefact publication. Organisations that use third-party or managed build services are not exempted: they must obtain attestations from the service provider or implement verification controls that provide equivalent assurance. The dimension applies regardless of whether the pipeline is triggered manually, on a schedule, or by an event such as a code commit. Pipelines that produce artefacts consumed only in development or testing environments are subject to the attestation requirements at SHOULD level; pipelines producing production artefacts are subject at MUST level.

4.1. A conforming system MUST generate a cryptographically signed attestation for every material build step in the pipeline, recording at minimum: the step identifier, the inputs consumed (with cryptographic hashes), the outputs produced (with cryptographic hashes), the build environment identity, the timestamp, and the policy version governing the step.

4.2. A conforming system MUST maintain a tamper-evident attestation chain linking all build steps from source material ingestion through to the final published artefact, such that the integrity of the full chain can be verified in a single operation.

4.3. A conforming system MUST gate deployment on successful verification of the complete attestation chain — no artefact may be deployed to a production environment unless every required build step has a valid, unexpired, policy-compliant attestation.

4.4. A conforming system MUST record the identity and integrity state of the build environment for each step, including the builder identity (machine, container, or serverless function), its software version, and any configuration parameters that could influence the build output.

4.5. A conforming system MUST detect and reject attestation gaps — missing attestations for required steps — before artefact publication. An artefact with an incomplete attestation chain MUST NOT be published to any artefact registry serving production environments.

4.6. A conforming system MUST protect attestation signing keys using hardware security modules, key management services, or equivalent tamper-resistant key storage, and MUST rotate signing keys on a defined schedule not exceeding 12 months.

4.7. A conforming system MUST log all pipeline configuration changes as auditable events, with the identity of the change author, the before and after states, and the approval reference (where applicable).

4.8. A conforming system SHOULD implement attestation verification at multiple enforcement points: at artefact publication, at deployment initiation, and at runtime admission.

4.9. A conforming system SHOULD generate a human-readable attestation summary for each build, enabling governance reviewers to verify pipeline compliance without specialised tooling.

4.10. A conforming system MAY implement real-time attestation streaming, publishing attestation events to a governance event bus as they are generated, enabling concurrent monitoring during long-running builds.

5. Rationale

The software delivery pipeline is the most consequential transformation boundary in the entire AI agent lifecycle. Source code is reviewed by humans; configuration is governed by policy; model weights are validated by evaluation harnesses. But the pipeline is where all of these governed inputs are transformed into the actual running artefact. If the pipeline is not attested, the chain of trust is broken at the most critical link.

Three classes of risk motivate this dimension. First, supply-chain attacks that inject malicious code during the build process — without modifying any reviewed source code. The SolarWinds incident demonstrated that a compromised build pipeline can distribute malicious code to thousands of organisations through a trusted update mechanism. AI agent pipelines face the same risk: an attacker who compromises the build environment can inject code that manipulates agent reasoning, exfiltrates training data, or creates backdoors — all invisible in source code review. Second, pipeline configuration drift — gradual or deliberate modification of pipeline stages that weakens quality gates, as illustrated in Scenario C. Without attestation that each stage executed, the absence of a testing stage is invisible. Third, dependency substitution and confusion attacks that exploit the build's dependency resolution mechanism to introduce untrusted packages, as illustrated in Scenario B.

Regulatory frameworks increasingly recognise the supply-chain risk. The EU AI Act Article 15 requires robustness against manipulation; a pipeline without attestation cannot demonstrate robustness against build-time manipulation. The EU Cyber Resilience Act mandates software bill of materials and vulnerability handling throughout the product lifecycle — attestation is the mechanism by which build-time integrity is evidenced. DORA Article 9 requires ICT risk management including third-party dependencies and supply-chain controls. SOX Section 404 requires internal controls over systems producing financial outputs — an unattested pipeline is an uncontrolled system. NIST SSDF (Secure Software Development Framework) and SLSA (Supply-chain Levels for Software Artifacts) both establish build attestation as a foundational supply-chain security practice, with SLSA defining four levels of increasing assurance that map directly to the maturity model in this dimension.

For AI agent systems specifically, the risk is amplified because the pipeline produces not just application logic but also model configurations, prompt templates, and governance policy bundles. A compromised pipeline that modifies a model's system prompt or safety constraints can undermine the entire governance framework without triggering any of the application-layer controls. Build attestation is the foundation on which all other supply-chain controls depend.

6. Implementation Guidance

Build Pipeline Attestation Governance requires that every material transformation in the delivery pipeline produces a verifiable, tamper-evident record. The core principle is that the path from reviewed source to deployed artefact must be fully reconstructable from attestation evidence alone — an auditor should be able to verify, after the fact, exactly what happened during every build.

Recommended patterns:

• Per-step attestation with in-toto or equivalent metadata. Each build step produces a structured attestation document recording inputs, outputs, environment, and policy compliance. The attestation is signed by the build step's identity (not a shared pipeline key). The attestation format should follow an established standard (in-toto attestation framework, SLSA provenance predicate, or functionally equivalent format) to enable interoperability and third-party verification. Each attestation is stored in a tamper-evident log (per AG-006) immediately upon generation.
• Deployment admission controller. A dedicated admission controller at the deployment boundary verifies the complete attestation chain before permitting any artefact to enter the production environment. The controller checks: all required steps are attested, all attestation signatures are valid and from authorised signers, all attestation timestamps are within acceptable windows, and all policy constraints recorded in the attestations are satisfied. If any check fails, deployment is blocked. The controller operates independently of the build pipeline — it cannot be bypassed by pipeline administrators.
• Hermetic and reproducible builds. Build steps execute in hermetic environments with no network access except to verified, pre-approved dependency sources. The environment is provisioned from a verified base image and destroyed after each build. This limits the attack surface and ensures that the attested environment state is the actual environment state. Reproducible builds — where the same inputs always produce the same outputs — enable independent verification by re-executing the build and comparing outputs to attested hashes.
• Signing key isolation per build stage. Each build stage uses a distinct signing key, stored in a hardware security module or equivalent service. This prevents a compromise of one stage's key from enabling forgery of attestations for other stages. Key rotation follows a defined schedule (maximum 12 months per Requirement 4.6) and key revocation procedures ensure that compromised keys are invalidated across all verification points within 4 hours.
• Attestation chain visualisation. Generate a visual representation of the attestation chain for each build, showing each step, its inputs and outputs, the attestation status, and any policy violations. This visualisation is included in deployment approval workflows, enabling human reviewers to verify pipeline integrity at a glance. For automated deployments, the visualisation is archived with the build record.

Anti-patterns to avoid:

• Final-hash-only verification. Recording only the hash of the final artefact without attesting intermediate steps. This proves the artefact has not been modified after the build but provides no evidence about what happened during the build. An attacker who compromises the build process can produce a consistent final hash that matches an attested value while the build contents include injected code.
• Shared pipeline signing key. Using a single signing key for all build steps, all pipelines, or all environments. A single compromised key enables forgery of the entire attestation chain. Each stage, pipeline, and environment should have independent signing credentials.
• Self-attesting pipelines. A pipeline that generates and verifies its own attestations without independent verification. The verification must be performed by a system independent of the build pipeline — typically a deployment admission controller or a governance monitoring service. Self-attestation provides no protection against a compromised pipeline.
• Attestation without policy binding. Generating attestations that record what happened but not what was required. An attestation that says "unit tests ran" is less valuable than one that says "unit tests ran, 847 tests passed, 0 failed, coverage 94.2%, against policy requirement of 90% minimum coverage." Without policy binding, an attestation proves execution but not compliance.
• Opt-out mechanisms for attestation. Providing pipeline users with the ability to skip attestation steps for convenience, speed, or emergency deployments. Any opt-out mechanism will be used — and once used, becomes normalised. Emergency deployment procedures should have enhanced attestation, not reduced attestation.

Industry Considerations

Financial Services. Financial regulators (FCA, SEC, MAS) require demonstrable controls over systems that influence financial decisions. An AI agent executing trades, assessing credit risk, or processing payments must be built through an attested pipeline that can prove to regulators exactly what code is running in production and how it got there. The FCA's SYSC 6.1.1R requirement for adequate systems and controls directly encompasses build pipeline integrity. Firms should implement SLSA Level 3 equivalent attestation as a minimum.

Healthcare and Life Sciences. Medical device regulations (MDR, FDA 21 CFR Part 820) require design controls including verification and validation evidence. AI agents used in clinical decision support must have complete build attestation chains that serve as design verification records. The build attestation becomes part of the device design history file.

Safety-Critical and Cyber-Physical Systems. IEC 61508 and related functional safety standards require traceability from requirements through to the deployed executable. Build attestation provides the evidence that the deployed artefact was produced from the verified source through a controlled process. Pipeline compromise in safety-critical environments can have lethal consequences, making attestation a life-safety control.

Crypto and Web3. Smart contract and decentralised agent deployments are particularly vulnerable to supply-chain attacks because deployed code is often immutable or expensive to update. Build attestation for Web3 agent pipelines must be especially rigorous because post-deployment remediation may be impossible. Organisations should implement deterministic builds with independently reproducible outputs.

Maturity Model

Basic Implementation — The pipeline generates a signed provenance attestation for the final artefact, recording the source repository, commit hash, builder identity, and build timestamp. Deployment is gated on the presence and validity of this attestation. Pipeline configuration changes are logged. Signing keys are stored in a key management service. This meets the minimum mandatory requirements.

Intermediate Implementation — All basic capabilities plus: per-step attestation is generated for every material build stage (source checkout, dependency resolution, compilation, testing, packaging). Each attestation records inputs, outputs, and policy compliance. A deployment admission controller verifies the complete attestation chain. Hermetic build environments prevent network-based supply-chain attacks. Signing keys are stage-specific and stored in hardware security modules. Attestation gaps are detected and block artefact publication.

Advanced Implementation — All intermediate capabilities plus: reproducible builds enable independent verification by re-executing builds and comparing outputs. Real-time attestation streaming enables concurrent governance monitoring. Attestation chain visualisation is integrated into deployment approval workflows. The organisation can demonstrate through independent audit that no build artefact can reach production without a complete, valid attestation chain. Cross-organisational attestation verification enables verification of third-party build pipeline integrity.

7. Evidence Requirements

Required artefacts:

• Attestation chain records. Complete attestation chains for all production builds, including per-step attestation documents, signatures, and verification results. Each attestation must include: step identifier, input hashes, output hashes, environment identity, timestamp, and policy version.
• Signing key management records. Key lifecycle records including creation, rotation, revocation, and storage configuration for all attestation signing keys. Must demonstrate hardware-backed storage and rotation within the 12-month maximum.
• Deployment gate verification logs. Logs from the deployment admission controller showing verification decisions (approved or rejected) for every deployment attempt, with the verification results that informed each decision.
• Pipeline configuration audit trail. Tamper-evident log of all pipeline configuration changes, including the change author, before/after states, timestamps, and approval references.
• Build environment inventory. Current inventory of all build environments, their software versions, configuration parameters, and integrity verification status.

Retention requirements:

• Attestation chain records: minimum 7 years for regulated financial services; minimum 5 years for safety-critical systems; minimum 3 years otherwise.
• Signing key records: retained for the lifetime of any artefact signed with the key, plus 2 years.
• Pipeline configuration audit trail: same retention as attestation chain records.

Access requirements:

• Producible to regulators or auditors within 48 hours of request.
• Attestation verification must be possible without access to the build pipeline itself — all evidence must be independently stored and verifiable.

8. Test Specification

Test 8.1: Per-Step Attestation Generation

• Stimulus: Execute a full pipeline build. After completion, retrieve the attestation record for each material build step: source checkout, dependency resolution, compilation, testing, and packaging.
• Expected behaviour: Each step has a cryptographically signed attestation containing the required fields: step identifier, input hashes, output hashes, environment identity, timestamp, and policy version.
• Pass criteria: 100% of material build steps have valid, complete attestations. All signatures verify against authorised signing keys. All required fields are present and non-empty.
• Fail criteria: Any material build step lacks an attestation, any attestation has an invalid signature, or any required field is missing.

Test 8.2: Attestation Chain Integrity Verification

• Stimulus: Retrieve the complete attestation chain for a production artefact. Verify that the chain is continuous — the outputs of each step (by hash) match the inputs of the subsequent step — from source checkout through to the published artefact.
• Expected behaviour: The attestation chain is continuous with no gaps. Every output hash from step N appears as an input hash in step N+1. The final attested output hash matches the published artefact hash.
• Pass criteria: Complete chain continuity with zero hash mismatches. The artefact hash in the deployment environment matches the final attestation output hash.
• Fail criteria: Any hash discontinuity in the chain, or the deployed artefact hash does not match the attested output hash.

Test 8.3: Deployment Gate Enforcement — Missing Attestation

• Stimulus: Construct a build artefact with a valid attestation chain except for one deliberately omitted step (e.g., remove the testing stage attestation). Attempt to deploy the artefact to the production environment.
• Expected behaviour: The deployment admission controller detects the missing attestation and rejects the deployment. The rejection is logged with the specific reason (missing attestation for the testing stage).
• Pass criteria: Deployment is blocked. The rejection log identifies the specific missing attestation. The artefact does not reach any production runtime.
• Fail criteria: The artefact is deployed despite the missing attestation, or the rejection does not identify the missing step.

Test 8.4: Deployment Gate Enforcement — Invalid Signature

• Stimulus: Construct a build artefact with a complete attestation chain, but tamper with one attestation (modify the output hash after signing, rendering the signature invalid). Attempt to deploy.
• Expected behaviour: The admission controller detects the invalid signature and rejects the deployment. The tampered attestation is identified.
• Pass criteria: Deployment is blocked. The specific tampered attestation is identified in the rejection log.
• Fail criteria: The artefact is deployed despite the tampered attestation, or the tampered step is not identified.

Test 8.5: Pipeline Configuration Change Logging

• Stimulus: Modify the pipeline configuration (e.g., change a build parameter, add or remove a stage, modify a policy threshold). Verify that the modification is captured in the audit trail.
• Expected behaviour: The audit trail records the change with: the author identity, a timestamp, the before and after states of the configuration, and the approval reference (if applicable).
• Pass criteria: The configuration change appears in the audit trail within 60 seconds. All required fields (author, timestamp, before/after, approval) are present.
• Fail criteria: The change does not appear in the audit trail, or any required field is missing.

Test 8.6: Signing Key Rotation and Revocation

• Stimulus: Initiate a signing key rotation for one build stage. Verify that: the new key is generated and stored in the hardware security module, the old key is marked as deprecated, subsequent builds use the new key, and attestations signed with the old key are still verifiable for previously built artefacts.
• Expected behaviour: Key rotation completes successfully. New builds are signed with the new key. Old attestations remain verifiable. The rotation event is logged.
• Pass criteria: Post-rotation builds use the new key exclusively. Pre-rotation attestations remain verifiable. The key management log records the rotation event.
• Fail criteria: Post-rotation builds use the old key, pre-rotation attestations become unverifiable, or the rotation is not logged.

Test 8.7: Build Environment Identity Attestation

• Stimulus: Execute a build and examine the build environment attestation for any step. Verify that the attestation records the builder identity (machine or container ID), the builder software version, and the builder configuration hash.
• Expected behaviour: The build environment identity is fully recorded in the attestation, including fields sufficient to reconstruct or verify the environment state.
• Pass criteria: Builder identity, software version, and configuration hash are all present and non-empty. The attested environment identity matches the actual build environment used.
• Fail criteria: Any environment identity field is missing, or the attested identity does not match the actual environment.

Conformance Scoring

• Score 0: No build pipeline attestation exists. Artefacts are deployed without any verification of their provenance or build-time integrity.
• Score 1: A final provenance attestation is generated for the published artefact (recording source commit, builder, and timestamp), but per-step attestation is not implemented. Deployment may or may not be gated on the attestation.
• Score 2: Per-step attestation is generated for all material build stages. The attestation chain is continuous and verified. Deployment is gated on a complete, valid attestation chain. Signing keys are stored in hardware-backed key management. Pipeline configuration changes are logged.
• Score 3: All Score 2 capabilities verified through independent audit. Reproducible builds enable independent verification. Hermetic build environments prevent supply-chain injection. Real-time attestation monitoring detects anomalies during builds. The organisation can demonstrate that no artefact can reach production without a complete, valid, policy-compliant attestation chain.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 15 (Accuracy, Robustness and Cybersecurity)	Direct requirement
EU AI Act	Article 17 (Quality Management System)	Supports compliance
SOX	Section 404 (Internal Controls Over Financial Reporting)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Direct requirement
NIST AI RMF	GOVERN 1.4, MAP 3.4, MANAGE 2.2	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks), Clause 8.4 (AI System Lifecycle Processes)	Supports compliance
DORA	Article 9 (ICT Risk Management Framework), Article 12 (ICT Change Management)	Direct requirement

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

Article 15(4) requires that high-risk AI systems are resilient against unauthorised modification. A software delivery pipeline without attestation is the primary vector through which unauthorised modifications can reach production — modifications that bypass code review, testing, and all application-layer governance controls. Build attestation is the mechanism that demonstrates resilience against build-time manipulation. Without it, an organisation cannot credibly claim compliance with Article 15's robustness requirements for any AI system delivered through a software pipeline.

SOX — Section 404 (Internal Controls Over Financial Reporting)

For AI agents that influence financial reporting (trade execution, risk calculation, regulatory reporting), the build pipeline is part of the internal control environment. SOX auditors will assess whether the organisation can demonstrate that the software producing financial outputs was built through a controlled, auditable process. Build attestation provides the evidence that the deployed code matches reviewed source, was compiled in a controlled environment, and passed all required quality gates.

DORA — Article 9 and Article 12

DORA requires financial entities to implement ICT risk management frameworks that include change management controls. Article 12 specifically addresses ICT change management, requiring that all changes to ICT systems are recorded, tested, and assessed for risk. Build pipeline attestation directly supports these requirements by providing a tamper-evident record of every transformation applied to software artefacts. The attestation chain serves as the change verification record that DORA mandates.

FCA SYSC — 6.1.1R (Systems and Controls)

The FCA requires firms to have adequate systems and controls for managing risks. For AI-driven systems, the build pipeline is a critical control surface. The FCA will expect firms to demonstrate that the software running in production was produced through a controlled pipeline with verifiable integrity — particularly for systems making or influencing financial decisions. Build attestation provides this evidence.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Organisation-wide — a compromised pipeline can affect every artefact it produces, every agent it deploys, and every customer or system those agents interact with

Consequence chain: The build pipeline is modified or compromised without detection (due to absent or incomplete attestation), causing malicious, untested, or non-compliant code to reach production. The immediate technical failure is a break in the chain of trust: the deployed artefact is not what the organisation reviewed and approved. The operational impact depends on the nature of the injection — data exfiltration (Scenario A: £2.8 million remediation across 14,000 affected clients), supply-chain compromise through dependency substitution (Scenario B: £890,000 incident response and 47,000 tainted decisions), or safety control bypass through pipeline modification (Scenario C: £4.6 million combined equipment damage and lost production). The business consequence includes regulatory enforcement for inadequate systems and controls, loss of customer trust when the organisation cannot prove what software was running during an incident, and potential liability for decisions made by compromised agents. The failure is particularly dangerous because it undermines all other governance controls: an attacker who controls the build pipeline can remove safety constraints, disable audit logging, bypass access controls, and modify model behaviour — all without triggering any application-layer detection. Build attestation is therefore a foundational control: its failure undermines the entire governance framework.

Cross-references: AG-005 (Instruction Integrity Verification), AG-006 (Tamper-Evident Record Integrity), AG-007 (Governance Configuration Control), AG-370 (Runtime Environment Integrity Governance), AG-400 (Infrastructure Governance Taxonomy), AG-405 (Container Image Provenance Governance), AG-406 (Dependency Supply-Chain Governance), AG-408 (Infrastructure Drift Detection Governance).