AXR is a cryptographic accountability protocol. Its security model is designed to answer one question after the fact: did this workflow execution record get modified since it was produced?
AXR does not attempt to prevent malicious actions. It attempts to make them detectable.
Every receipt is signed with Ed25519. Changing any byte — a status field, a timestamp, an input hash — invalidates the signature. The verifier catches this immediately.
Receipts are linked by SHA-256 hashes. Modifying one receipt breaks the hash chain at that point. Even if the attacker re-signs the modified receipt, the next receipt’s previous_receipt_hash no longer matches.
Removing a receipt from the middle of a chain leaves the surrounding signatures intact, but the hash linkage breaks at the gap. The step_chain ID list on the workflow receipt also stops matching the step receipts actually present. Both mechanisms independently surface the deletion.
A receipt chain that contradicts the workflow’s external behavior — for example, a ZONE_INCOMPATIBLE rejection receipt alongside a success email — surfaces the contradiction. This is how three pre-existing bugs were discovered during the 0.2 pilot (see AXR-SPEC-0.2.md, section 8).
The verifier flags uniform input_hash values across steps in a 0.2 chain. In 0.2, each step hashes its own actual input. If all hashes are identical, the per-step marker convention has regressed to 0.1 behavior.
These are deliberate scope boundaries for the 0.x line. Each is acknowledged honestly — a credible security model states its own limits.
If the Ed25519 private key is exfiltrated, an attacker can forge valid receipts indistinguishable from genuine ones. AXR 0.2 stores the key as a PEM file (mode 600) on a bind-mounted host directory. This is operator-level protection, not hardware-grade.
Mitigation path (future): HSM integration, key rotation, threshold signatures (see ROADMAP.md, AXR 1.0).
An operator who controls the signing key can produce fraudulent receipts. AXR proves what the system recorded, not whether the operator acted in good faith. Cross-operator trust requires a higher layer (agent identity registry, transparency logs) that AXR 0.x deliberately excludes.
If the n8n container, the host OS, or the workflow engine itself is compromised, the attacker controls both the workflow and the receipt generator. AXR cannot detect this — it trusts its own runtime.
For generative (LLM) steps, AXR records the model identifier (step.model) and hashes the input and output. But it cannot guarantee that the same input would produce the same output on re-execution. Deterministic replay for generative steps is a 0.3 research area.
The receipt log is append-only by convention, not by mechanism. The operator’s filesystem enforces write access. A compromised operator could truncate or replace the log file entirely. External anchoring (transparency logs, remote witnesses) would address this; it is out of scope for 0.x.
crypto module)600, readable only by the container’s runtime user.gitignore excludes *.pem, *.key, and all files matching signing-key*.customer_ref fields). The .gitignore excludes *.jsonl and receipts-*.jsonl.If you discover a vulnerability in the AXR protocol specification, reference implementation, or verifier:
We will acknowledge receipt within 48 hours and aim to publish a fix or mitigation within 7 days for critical issues.
| Primitive | Algorithm | Purpose |
|---|---|---|
| Signing | Ed25519 | Receipt authentication |
| Hashing | SHA-256 | Content integrity, chain linkage |
| Serialization | Canonical JSON (lexicographic key sort) | Deterministic hash input |
| PII protection | SHA-256 one-way hash | customer_ref field — queryable, not leakable |
No external cryptographic libraries are used. All primitives come from Node.js built-in crypto module.