|
| 1 | +# Compliance & audit evidence |
| 2 | + |
| 3 | +Burnwall produces **local, metadata-only, tamper-evident** records of what an AI |
| 4 | +agent did and was blocked from — useful as *evidence* for AI-governance frameworks. |
| 5 | +It is **not** a compliance product and does not make you compliant on its own; it |
| 6 | +furnishes artifacts an auditor or underwriter can verify. |
| 7 | + |
| 8 | +## The artifacts |
| 9 | + |
| 10 | +- **Audit receipts** (`burnwall audit seal` / `verify`) — Ed25519-signed, |
| 11 | + hash-chained, metadata-only records of every forwarded/blocked action. Each |
| 12 | + receipt hashes the source row's contents, so `verify` detects edits to the |
| 13 | + underlying data, and the chain detects insertion/deletion/reordering. |
| 14 | +- **CycloneDX AI-BOM** (`burnwall audit aibom`) — machine-readable session bill of |
| 15 | + materials (models, MCP servers, security activity). |
| 16 | +- **SARIF** (`burnwall audit sarif`) — security blocks for GitHub code scanning. |
| 17 | +- **OWASP / EU-AI-Act mapping** — see `docs/SECURITY_FRAMEWORKS.md`. |
| 18 | + |
| 19 | +None of these contain prompt content. |
| 20 | + |
| 21 | +## Framework mapping (evidence, not certification) |
| 22 | + |
| 23 | +| Framework / control | What it asks for | Burnwall artifact | |
| 24 | +|---|---|---| |
| 25 | +| **EU AI Act, Art. 12** (record-keeping / automatic logging) | Automatic, traceable logs of system events over the lifecycle | Audit receipts (`seal`) — signed, chained, per-action | |
| 26 | +| **EU AI Act, Art. 19 / 26** (log retention) | Keep logs (≥6 months for deployers) | Retained receipt chain; `audit verify` reports count + oldest sealed date | |
| 27 | +| **ISO/IEC 42001, A.6.2.8** (AI event logging) | Immutable, attributable who/what/when records | Audit receipts + `verify` | |
| 28 | +| **SOC 2** (CC-series: logging, change/integrity) | Tamper-evident activity + control-enforcement evidence | Receipts (forward/block) + SARIF security events | |
| 29 | +| **NIST AI RMF** (Measure/Manage) | Evidence that runtime controls operated | Blocked-action receipts + security events | |
| 30 | + |
| 31 | +Honest caveat: Burnwall is a deployer-side control plane, so it provides |
| 32 | +*proof-of-controls evidence*, not full compliance with any framework. |
| 33 | + |
| 34 | +## Independent verification (no Burnwall required) |
| 35 | + |
| 36 | +`burnwall audit export --format json` emits a self-contained bundle: |
| 37 | + |
| 38 | +```json |
| 39 | +{ |
| 40 | + "public_key": "<hex Ed25519 verifying key>", |
| 41 | + "count": <n>, |
| 42 | + "receipts": [ |
| 43 | + { |
| 44 | + "seq": 1, "sealed_at": "...", "source": "request|security_event", |
| 45 | + "source_id": 1, "timestamp": "...", "action": "forward|block|security", |
| 46 | + "provider": "...", "model": "...", "detail": "...", |
| 47 | + "content_hash": "<sha256 hex of the source row>", |
| 48 | + "prev_hash": "<hex>", "hash": "<sha256(prev_hash \\n content_hash) hex>", |
| 49 | + "signature": "<ed25519(hash) hex>" |
| 50 | + } |
| 51 | + ] |
| 52 | +} |
| 53 | +``` |
| 54 | + |
| 55 | +A third party (auditor/underwriter) can re-walk the chain and verify every |
| 56 | +signature **without trusting the Burnwall binary** using `tools/verify_receipts.py`: |
| 57 | + |
| 58 | +``` |
| 59 | +burnwall audit export --format json > receipts.json |
| 60 | +python tools/verify_receipts.py receipts.json |
| 61 | +# → OK — N receipt(s) verified against <pubkey>… (or TAMPERED at seq X) |
| 62 | +``` |
| 63 | + |
| 64 | +The external verifier checks the chain links + signatures from the export alone |
| 65 | +(proving the exported receipts weren't forged, reordered, edited, or deleted after |
| 66 | +export). Re-deriving each `content_hash` from the *live* source rows — proving the |
| 67 | +underlying data hasn't changed — is what `burnwall audit verify` does locally. |
0 commit comments