DocsPayload custody

Payload custody

The default is the strongest security answer there is: we cannot leak what we never see. Integrity stays fully provable either way, because the hashes are what chain.

Mode A — metadata + hashes (default)

Who acted, which tool, when, the outcome, the policy decision, token counts, and the SHA-256 of every input and output. Never the payload. Your DPIA shrinks accordingly, and GDPR erasure is a tombstone — destroy the payload wherever it lives, keep the hash, verification unaffected.

Mode B — payloads in YOUR bucket

python / typescript
auditant.init(api_key="ak_…", log_id="t_…/prod",
              payload_bucket="your-payload-bucket")     # your AWS creds

import { init, s3PayloadStore } from "auditant";
init({ apiKey: "ak_…", logId: "t_…/prod",
       payloadStore: s3PayloadStore("your-payload-bucket") });

Objects are content-addressed: the key is payloads/<sha256>, so the hash already on the chain event is the pointer into your bucket. No second index to drift, identical payloads dedupe themselves, and drill-down from any event is a one-line lookup in storage you control. The writer is SigV4 in the standard library — enabling custody adds zero dependencies. Custody is best-effort by construction: a dead bucket costs the payload copy, never the evidence.

drill-down, from any event's hash
aws s3 cp s3://your-payload-bucket/payloads/9c1a…f (their content, your custody)

What never gets held

Card numbers (scrub before emit — holding PAN would put the stack in PCI scope), voice recordings and voiceprints (audio stays customer-side, always), and anything a suppression flag marks. These are stated in the security page in the same words.