# Governance records

> How Agent Stream produces a signed, tamper-evident Verifiable Credential for every interaction on a surface, and how a per-surface hash chain makes deletion or reordering detectable.

Logs can be edited or deleted, and a policy denial recorded only as a line in a log gives an auditor nothing to independently verify. That gap gets worse once a Surface configured with prompt guards, Judge, Jury, expert witness, or Decider routes material between multiple LLMs, some under your control, some external, such as a hyperscaler or expert witness provider.

Governance records answer a stronger question: they prove exactly what entered a surface, how it was processed, and what left, with the appliance itself vouching for the record. This gives auditors and compliance teams an independently verifiable trail for every interaction, rather than a log line they have to trust. [Observability →](/products/affinidi-trust-fabric/agent-stream/concepts/observability.md)

## Off by default, enabled per surface

Governance recording is not switched on globally. Enabling it on a surface is a single click plus your chosen configuration options; from that point, every interaction on that surface is recorded at each stage with all inputs and outputs, signed by the appliance as a Verifiable Credential (VC), with no change to the caller’s experience or latency.

- Storage. Records are kept on the appliance as a log.

- Optional export. Records can also be emitted to OpenTelemetry and to Integrations such as webhooks, email, or streaming buses like Kafka, Kinesis, Pulsar, and Redis Streams.

- Why it exists. This creates an overall, tamper-evident record of what happened, available to satisfy auditors or correlate LLM activity with suspicious agent behavior.

## Governance record contents

A governance record is a complete transcript of a single interaction, built from the same stage evidence described in [Pipeline and stages →](/products/affinidi-trust-fabric/agent-stream/concepts/pipeline-and-stages.md) and [Guardrails →](/products/affinidi-trust-fabric/agent-stream/concepts/guardrails.md):

| Section | Contents |
| Identity and correlation | A record ID, capture time, the surface name and ID, a trace ID, and a hashed caller identity, never the raw identifier. |
| Prompt | The caller’s full input prompt, when body capture is enabled. |
| Processing stages | An ordered list of every stage that ran, Prompt Guard, expert witnesses, the Decider, Judge, Jury, and the model call, each with its verdict (allow, block, flag, observed for a stage such as the model call that completed without needing a decision, or error) and, where applicable, the exact content that stage evaluated and the result it returned. |
| Completion | The model’s full output, when body capture is enabled. |
| Metrics | Tokens, cost, latency, provider, and model for the interaction. |
| Chain | A content hash of this record and a link to the previous record on the same surface. |

Because the surface name and ID are captured into the record itself, a record stays fully readable even after the surface it came from is deleted.

Recording covers every path a surface serves:

- Buffered and streamed responses alike, since a streamed completion is reassembled behind the scenes before it is recorded.

- Successful, blocked, and failed interactions, since a request stopped by a guardrail, a rate limit, or an upstream error is recorded with the stage that stopped it.

- Live traffic and sandbox test runs, with sandbox tests attributed to a built-in test identity so they stay separable from live traffic in the chain.

## How a record is trusted

Trust rests on two independent, layered mechanisms rather than one.

  Per-record signatureEvery record is wrapped in a W3C Verifiable Credential and signed with the appliance's own key, tied to its Decentralised Identifier. Anyone holding the appliance's public DID document can verify that the appliance issued the record and that it has not been altered since.
  Per-surface hash chainEach record embeds the content hash of the previous record on the same surface. Deleting or reordering a record breaks the chain, so gaps and tampering are both detectable, not just individual forged records.

  Record 1
hash: H1
  →
  Record 2
prev_hash: H1 · hash: H2
  →
  Record 3
prev_hash: H2 · hash: H3

A surface’s entire chain can be verified on demand from the dashboard. Verification recomputes every record’s content hash, walks the chain links, and returns a pass or fail result with the number of records checked.

Beyond the local, encrypted store, a surface can also export each signed record to operator-configured targets: OpenTelemetry, or an integration such as webhook, Slack, email, a Kafka/Kinesis/Pulsar/Redis stream, or Langfuse. Local retention is configurable per surface too, with rotation controlled by a retention window.

## How governance records protect sensitive data

Governance records can contain sensitive prompt and completion content, so they carry their own protections independent of the rest of the appliance:

- Body capture is a choice. Full prompt, completion, and per-stage bodies are stored only when body capture is enabled on the surface. With it off, the appliance keeps digests only: cryptographic fingerprints that still prove what content flowed and preserve tamper-evidence, without storing the raw text.

- Encrypted at rest. Every signed record is encrypted on disk with the appliance’s own encryption service, using AES-256-GCM with either a local key or an AWS KMS envelope.

- No raw caller identifiers. The caller identity is stored as a salted hash, consistent with the identity hashing described in [Security and access control →](/products/affinidi-trust-fabric/agent-stream/concepts/security-and-access-control.md).

Reading a governance record exposes the raw prompts and completions of recorded interactions, so access is gated by its own dedicated permission and restricted to administrators by default, distinct from the broader application-log permission.

## Why this matters

A governance record turns a governance decision from something you log into something you can prove:

- Regulatory and compliance evidence. A signed trail of exactly what data entered and left a surface.

- Incident investigation. A precise reconstruction of what a caller asked, how each guardrail and reviewer stage evaluated it, and what the model returned, including for interactions that were blocked outright.

- Dispute resolution. An independently verifiable credential proving the content and processing of a specific interaction.

- Model and policy assurance. Visibility into how Judge, Jury, and expert-witness stages are performing against real traffic, with the exact content each stage saw, not just an aggregate pass or fail count.

## Related

- [Guardrails](/products/affinidi-trust-fabric/agent-stream/concepts/guardrails.md): The stages whose verdicts and evidence a governance record captures.

- [Pipeline and stages](/products/affinidi-trust-fabric/agent-stream/concepts/pipeline-and-stages.md): The named stage order a governance record’s processing-stages section is built from.

- [Security and access control](/products/affinidi-trust-fabric/agent-stream/concepts/security-and-access-control.md): The encryption and identity-hashing model governance records rely on.

- [Observability](/products/affinidi-trust-fabric/agent-stream/concepts/observability.md): How governance records relate to the appliance’s other telemetry and dashboards.

- [PII protection](/products/affinidi-trust-fabric/agent-stream/concepts/pii-protection.md): How a PII detection stage is captured in a governance record without exposing the values it protected.