← Atlas

Atlas

Tamper-Evident Accountability

Evidence integrity is a system property of the composition, not a property of any single control. Five Helmwart mitigations each attest to a different dimension of an agentic-AI action record: who acted, what the output was, what code ran, what dependencies existed, and how long the record was preserved. An attacker who compromises one mitigation faces independent attestation from the other four. Independent operation increases the cost and detectability of forgery, while the failure cases below identify combinations of compromised controls that still undermine parts of the record.

The five controls

m-actor-recorder-split
Who acted

Audit records are written by a separate identity from the agent that acted. An attacker who controls the acting agent cannot alter the record because the recorder is a distinct, independently-credentialed process. Addresses T8 (Repudiation).

m-output-provenance
What the output was

Every claim is tagged with the source that produced it. Provenance metadata travels with the output through downstream processing and into audit storage. Addresses T1 (Memory Poisoning attribution), T5 (Cascading Hallucinations), T8 (Repudiation).

m-sigstore
What code ran

Keyless signing via Sigstore's Rekor transparency log gives a third-party-verifiable record of which artifact versions were active at the time of the action. Addresses T8 (Repudiation and Untraceability) and T17 (supply-chain provenance).

m-sbom
What dependencies existed

A cryptographically signed AIBOM/SBOM (AI Bill of Materials / Software Bill of Materials) declares the model version, plugin set, and dependency tree active during the session. Addresses T17 (Agent Supply Chain) by enabling post-incident verification that the declared components match what ran.

m-legal-hold
How long it was preserved

WORM (write-once-read-many) storage with retention locks prevents deletion or modification of audit records within the retention window, even by an administrator who also operates the acting agent. Addresses T8 (Financial Transaction Obfuscation, Compliance Violation Concealment).

How they compose

The five mitigations address distinct, non-overlapping dimensions of a complete action record. Together they form a chain where each link is independently verifiable.

  1. actor-recorder split · who acted

    The split establishes that the identity in the audit record is not the same identity as the agent that invoked the action. An attacker who impersonates or compromises the acting agent cannot rewrite this field because the recorder process holds independent credentials it never shares. If this link is broken (the actor also controls the recorder), Sigstore catches the inconsistency: the code-signing artifact identifies the deployed recorder version, and forensic analysis can establish whether that version would permit self-write.

  2. output provenance · what the output was

    Each output claim carries a source tag. This tag links the claim to the RAG (Retrieval-Augmented Generation) corpus entry, retrieval timestamp, and agent context window at the moment of generation. If an attacker modifies the stored output (removing a harmful claim, inserting a benign one), the provenance metadata diverges from what the transparency log recorded for that session. If this link is broken (provenance metadata is stripped or spoofed), actor-recorder split preserves the raw audit record, and forensic analysis can reconstruct what the recorder saw at emission time even without claim-level tags.

  3. Sigstore · what code ran

    Sigstore's Rekor transparency log provides an append-only, publicly verifiable record of the artifact's signing event, bound to an ephemeral OIDC (OpenID Connect) identity from Fulcio. An attacker who modifies the running code after signing must produce a new, valid log entry, which is detectable by any verifier querying Rekor. If this link is broken (the signing pipeline is compromised), the SBOM still declares the expected component tree, giving a second check that the artifact version in the transparency log matches the declared dependency manifest.

  4. SBOM · what dependencies existed

    The signed AIBOM/SBOM is produced at build time and pinned to the deployment. Post-incident, an investigator can verify the SBOM hash against the artifact recorded in the Sigstore log. A supply-chain substitution (swapping a tool plugin or model version after SBOM generation) creates a hash mismatch detectable by this comparison. If this link is broken (the SBOM itself is forged), Sigstore provides the independent transparency-log entry to compare against.

  5. legal hold · how long it was preserved

    WORM retention locks the audit record in place for the declared retention period. An attacker who has modified or fabricated content in the other four links must still contend with the retention-locked original record, which cannot be overwritten or deleted within the window. If this link is broken (the storage vendor or administrator is compromised), the distributed records in the Sigstore transparency log and the SBOM manifest are not under the same storage operator's control, giving external verifiers an independent ground truth.

Where this fails

The composition provides meaningful resistance only when each mitigation is independently operated and independently credentialed. Several conditions collapse the chain.