Don’t believe it, prove it.

9.1 Why traceability?

In classic development, the Git history answers many questions: Who changed what, and when? In agentic development that is no longer enough. The commit author is an agent or a neutral identity, and the interesting questions come earlier: Who gave the task? Which model did the work? Which rules applied? Was the code reviewed, and who approved it? Against which requirement was it built?

Four reasons make these questions pressing:

• Responsibility and liability: An agent cannot bear responsibility. People and organizations remain responsible. For responsibility to be attributable, it must be recorded who made which decision.
• Audit and internal review: Internal audit, external auditors and customers ask for evidence. A claim (“our code is always reviewed”) is not evidence. Evidence is a record that can be verified independently.
• Regulation: Various regulatory frameworks require records, human oversight and control of ICT and third-party risks. Which obligations specifically apply to your organization is a legal question. Technically, however, you can make sure that the necessary records are created and are reliable.
• Reproducibility and failure analysis: When a defect appears, you want to know under which conditions the code was created: model, context, rules, review results. Only then can you find the cause and improve the process.

9.2 Hash chains and signatures in five minutes

Hash functions

A cryptographic hash function such as SHA-256 maps arbitrary data to a value of fixed length. If even a single character of the input changes, the hash changes completely. And it is practically impossible to find two different inputs with the same hash. A hash is therefore a fingerprint of the content.

Chaining

In a hash chain, every entry contains the hash of its predecessor. The hash of an entry is computed over its content and the predecessor’s hash:

Open full-size graphicOpen full-size graphic

This makes every modification, deletion, insertion and reordering within the chain detectable, at least for anyone who recomputes it. The only thing that cannot be detected is truncating the most recent entries at the end; a signed chain head and a known reference state help against that (section 9.7). A consecutive sequence number additionally makes gaps visible.

Signatures

A hash chain alone does not protect against someone who recomputes all hashes. That is why each entry is additionally digitally signed: a private key produces a signature that anyone can verify with the corresponding public key. Without the private key, no valid signature can be created. A widely used, modern scheme is Ed25519.

What this does not achieve

• Whoever holds the private key can produce valid signatures, including for false content. Key protection is therefore part of the evidence.
• Whoever obtains the public key from the same source as the data verifies nothing: a forger swaps both. The trust anchor must arrive through a second channel.
• A chain proves that entries have not changed since they were created. It does not prove that the system that wrote them recorded the truth.

9.3 What to record? Decisions, not just results

A good audit log for agentic development does not record every keystroke but the decision-relevant events: task, rules, resources, checks, approvals. A useful question is which information an auditor would need a year from now to explain a specific state of the code.

• Lifecycle: created, started, paused, cancelled.
• Configuration at runtime: which model, from which source, which behavioral rules in which version.
• Rules: which policy was applied and which runs were rejected. A rejection is evidence too.
• Checks: gate result, SBOM, artifact signatures.
• Human decisions: approvals with person and timestamp.
• Requirement reference: against which requirement, in which version, the code was built.

A second principle: content only where necessary. Tool arguments may contain confidential data. Often a hash is enough to prove later that and what was passed, without storing the content in the log.

9.4 Policy-as-code: rules as a document

Rules such as “only these providers”, “quality gate blocking” or “approval before execution” can be managed in two ways: as scattered settings in a user interface, or as policy-as-code, i.e. as a structured document that is versioned, verified and evidenced.

The advantages of the second approach:

• Versioned: Every change creates a new version; the old one is retained. You can always say which rules applied at a given point in time.
• Signed: A signed version cannot be changed unnoticed.
• Unambiguously in effect: There is exactly one active version, no mixed states.
• Enforced rather than recommended: The system checks the rules at defined points and rejects violations.
• Layerable: A narrower level (such as a tenant) may tighten rules but not relax them.

An important detail is the point of enforcement. If a system only checks when a task is created, a task created before a rule change can bypass the new rule. A second check immediately before execution is more robust.

9.5 Human oversight and segregation of duties

Human oversight does not mean that a human types every line, but that a human must consent at the decisive points and that this consent is documented. In agentic development there are two natural checkpoints:

1. Before execution: May the agent start at all with this task, this model and these permissions?
2. Before adoption: May the reviewed result enter the shared state, i.e. be merged or opened as a pull request?

The second point is decisive. Without it, the code lands in the base branch before anyone has seen it. An “approval” after the fact would then be mere facade.

Segregation of duties means that the same person may not both trigger and approve. The classic four-eyes principle protects against mistakes and against abuse. With agents it also applies in a second form: the writing agent may not approve its own work. That role is taken by independent, read-only reviewers and a human.

A third principle is fail-closed: if a check cannot be performed, for example because a reviewer crashes or a policy cannot be read, this must never count as success.

9.6 Regulation: what technology can and cannot do

Many organizations must demonstrate that they control the risks of using software and AI. A few examples, without any claim to completeness and without constituting legal advice:

• The EU AI Act (Regulation (EU) 2024/1689) contains, among other things, requirements on record-keeping (Art. 12) and human oversight (Art. 14) for certain AI systems.
• In the financial sector, BaFin’s MaRisk, the BAIT (whose requirements overlap with DORA for institutions subject to DORA; current supervisory practice is decisive) and the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) set out requirements for ICT risk management, third-party risks and documentation of evidence.
• For the public sector, BSI IT-Grundschutz and the rules for classified information (VS-NfD) are relevant.

Whether and how these frameworks apply to your use case is for legal and compliance experts to determine. Technology can contribute two things: it can enforce the technically enforceable parts (approvals, mandatory signing, blocking checks, provider restrictions) and produce the necessary records in a tamper-evident way. It does not replace organizational obligations such as responsibilities, training, risk analyses and contracts with providers.

9.7 Independent verification: handing evidence to outsiders

Evidence is only strong when someone who does not trust the system can verify it. This leads to requirements for an export:

• Deterministic: The same data yields the same bytes, regardless of library versions. Otherwise a hash cannot be recomputed.
• Self-contained: The export contains everything needed for verification, without access to the originating system.
• Data-minimal: Entries that are not part of the subject of the audit, such as other projects or tenants, appear only as hash placeholders. Their number is visible, their content is not.
• Independently verifiable: The verification tool does not come from the installation being verified; it is small, open source and reproducibly built.
• Trust anchor via a second channel: The fingerprint of the signing key arrives by letter, ticket or signed email, not in the same package as the data.

9.8 Requirements under governance: mandatory specs

So far, governance answers how code was created. One question remains: Was the right thing built? That requires approved, versioned requirements. The concept of the product spec with acceptance criteria is covered in Chapter 4. Here the focus is on how specs become part of governance.

Three building blocks interlock:

• Obligation: A build may only start if it references an approved requirement.
• Coverage: A result is only accepted if a minimum share of the bound acceptance criteria is covered by tests.
• Evidence: The export contains the requirement version itself, signed and with its approval, so that an auditor can independently trace which text the build was made against.

On top of this come metrics that show whether the process works: How many criteria are covered by tests? How often do approved requirements change during implementation? How many starts had an approved requirement at all?

9.9 Summary

• Evidence must be complete, unaltered and attributable. Hash chains make changes visible, signatures make entries attributable, and the trust anchor arrives through a second channel.
• Policy-as-code makes rules versioned, signed, unambiguously in effect and doubly enforced.
• Human oversight needs two checkpoints (before execution, before merge) and segregation of duties.
• Compliance profiles enforce technically enforceable parts, not organizational obligations.
• The audit export with the offline verifier lets third parties verify without trusting the factory.
• With mandatory specs, it also becomes provable against which approved requirement the code was built.

How costs, budgets, tenants and roles govern operations follows in Chapter 10.

Chapter questions

1. Which three properties does evidence need, and which technical building block provides each of them?

   Model answer

   Complete (gapless sequence seq and chaining via prev_hash, plus the signed head and the run manifest in the export), unaltered (entry_hash over content and predecessor) and attributable (Ed25519 signature with key_id, verified against a fingerprint transmitted through a second channel).

2. After a restore, the chain verification reports CHAIN_BREAK. What does that mean, and what is a likely cause?

   Model answer

   An entry is missing or was inserted; the chaining does not match at one point. After a restore, an incomplete backup is an obvious cause. This is exactly why the administration manual recommends running the chain verification after every restore: it doubles as an integrity check of the backup.

3. Why is it not enough to send the auditor the public key together with the export?

   Model answer

   Anyone who forges entries can also swap the enclosed key and re-sign everything. The trust anchor must come from an independent source. That is why the admin transmits the fingerprint from /attestierung through a second channel, and why the verifier never returns exit 0 without --schluessel.

4. Why does the factory enforce a policy twice, when a run is created and when it is executed?

   Model answer

   Otherwise a run created before a new policy was activated could bypass it. In addition, the why-trace and export should show the policy version that was actually enforced. The same pattern applies to the isolation proof: a CLI update between creation and start is detected this way.

5. A colleague suggests setting up only one approval point before execution: “that’s enough.” What do you reply?

   Model answer

   Without approval before the merge (approval policy or mandatory approval phase VALIDATION), the code lands in the base branch or in the PR before a human has seen the validated result. Approval before execution only assesses the task, not the result. For regulated profiles the second point is decisive; otherwise the signed commitment would be a facade.

6. A tenant admin wants to disable the MCP default ban in their policy, which is set in the global policy. Is that possible?

   Model answer

   No. Across multiple effective policies, the stricter one applies: a tenant policy can only tighten the global one, never undercut it (global policy floor). Correspondingly, for plugins and MCP servers the intersection applies.

7. Your management asks: “If we apply the EU AI Act profile, are we compliant?” How do you answer?

   Model answer

   No, not automatically. The profile enforces the technically enforceable parts (blocking gate, mandatory approval before EXECUTION, attestation) and produces tamper-evident records. It does not replace legal advice and does not cover organizational obligations. Whether and which obligations apply is for legal and compliance to determine; the factory provides reliable technical building blocks and evidence for this.

8. The offline verifier returns exit 2. What does that mean, and how do you get to exit 0?

   Model answer

   No violation was found, but not everything is provable, typically because --schluessel is missing or entries are unsigned or legacy. With the fingerprint confirmed through a second channel as --schluessel and active signing for the affected entries, exit 0 is achievable. Legacy entries from before attestation remain unverifiable.

9. In the target state per SPEC-005: a policy requires pflichtSpecFreigabe, but the project is in spec mode AUS. What happens when a build run is started?

   Model answer

   The policy wins as the stricter rule. The start is rejected, with an understandable reason and a RUN_POLICY_DENIED entry in the audit chain. Remedy: enable spec mode, create a spec and have it approved, and start the build from a backlog item with a spec reference.

10. Transfer: Six months after delivery, a customer wants to know against which requirement a particular state of the code was built. Which traces do you use, and what can the customer verify themselves?

    Model answer

    The factory commit carries the trailers Spec: SPEC-<nnn> and Implements: AC-…. Via the run, the why-trace shows spec ID, bound version, content hash and AC IDs from RUN_SPEC_GEBUNDEN, plus SPEC_APPROVED with the approval. The customer can verify the run export themselves with the offline verifier; in the target state per SPEC-005, export 2.1 contains the spec version including signature and approval, and the verifier matches the binding against the supplied version.