Governance records

How Agent Stream produces a signed, tamper-evident Verifiable Credential for each recorded 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 recorded interaction, rather than a log line they have to trust. Observability →

Off by default, enabled per surface

Governance recording is off on a new surface. Enabling it on a surface means turning on Record signed governance records plus your chosen configuration options. From that point, each interaction the surface’s Record setting covers (Every interaction, the default, Blocked interactions only, or Blocked and failed interactions) is recorded at each stage and signed by the appliance as a Verifiable Credential (VC). Recording never blocks or fails the caller’s request.

  • 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 behaviour.

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 → and Guardrails →:

SectionContents
Identity and correlationA record ID, capture time, the surface name and ID, a trace ID, a hashed caller identity (never the raw identifier), and the member and teams the request was attributed to.
PromptThe caller’s full input prompt, when Keep prompt & completion bodies keeps bodies for that interaction.
Processing stagesAn 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.
CompletionThe model’s full output, when Keep prompt & completion bodies keeps bodies for that interaction.
MetricsTokens, cost, latency, provider, and model for the interaction.
ChainA content hash of this record and a link to the previous record on the same surface.
The Governance Records page, with a record selected from the list on the left and its expanded detail panel on the right showing the identity and chain section, the ordered processing stages with each stage's verdict, and the recorded prompt and completion

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. Turning off Record streamed interactions leaves streamed requests out.
  • Successful, blocked, and failed interactions, as the Record setting allows, since a request stopped by a guardrail, a rate limit, or an upstream error is recorded with the stage that stopped it.
  • Realtime voice sessions, with one signed record per turn and a blocked turn recorded as a block.
  • 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 checks every record’s signature and content hash, walks the chain links, and returns a pass or fail result with the number of records checked.

The Verify chain action on a surface's Governance Records page, showing a Chain valid result and the number of records checked

Beyond the local store, a surface can also export each signed record to operator-configured targets: OpenTelemetry, or an integration created in the LLM Governance category, such as webhook, Slack, email, or a Kafka/Kinesis/Pulsar/Redis stream. Local retention is configurable per surface too, with rotation controlled by a retention window. Records pruned by retention are replaced by a signed chain anchor, so the remaining chain still verifies.

How governance records protect sensitive data

Governance records can contain sensitive prompt and completion content, so they carry their own protections:

  • Body capture is a choice. Keep prompt & completion bodies keeps full prompt, completion, and per-stage bodies For every recorded interaction by default. It can instead keep them For blocked interactions only, or Never (digests only). Where bodies aren’t kept, 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. Signed records are stored encrypted at rest.
  • No raw caller identifiers. A record identifies the caller by a one-way hash of its identity, never the raw identifier, plus the member and teams the request was attributed to.

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.
  • Guardrails: The stages whose verdicts and evidence a governance record captures.
  • Pipeline and stages: The named stage order a governance record’s processing-stages section is built from.
  • Security and access control: How source authentication establishes the caller identity that a record stores as a one-way hash.
  • Observability: How governance records relate to the appliance’s other telemetry and dashboards.
  • PII protection: How a PII detection stage is captured in a governance record without exposing the values it protected.