LatticeGuard: Post-Quantum Audit Trails for Detecting and Reproducing Collusion in Multi-Agent AI Systems

The paper argues that collusion audits need more than detectors. They also need evidence that is tamper-evident, reproducible and privacy-preserving: proof of what a monitor saw, which version of the detector ran, and that logs weren’t altered afterwards. That reframing is reasonable, and the paper is clearly organized. The event and verdict schemas and the four-configuration comparison are sensible starting points. But the submission is a proposal, not a research result, and several design choices need more justification.

No implementation or results. “Code and Data: Not yet available.” Section 4 describes a prototype that should be built and findings that are expected. The appendix lays out a 12-hour plan (Merkle log, signature abstraction, one detector, tampered runs, replay verifier) that would fit in a hackathon. Even a minimal version would have turned this into an evaluable contribution. As it stands, none of the claims can be checked.

The novelty claim is overstated. Append-only Merkle logs with signed checkpoints and independent witnesses are an established way to make logs tamper-evident, from secure-logging work in the late 1990s to Certificate Transparency (RFC 6962), Trillian and Sigstore/Rekor. Applying them to AI agent events is a sensible engineering step, but it isn’t a “new research direction.” Related work should cover this literature, along with C2PA-style provenance, TEE attestation and zkML, and explain what is specific to collusion auditing.

The post-quantum layer is mostly branding. The part of the design that actually ensures tamper evidence is the hash-based Merkle log with witnesses, and hash functions are already only modestly affected by quantum attacks. For signatures, the quantum threat is forging signatures in the future. Timestamped checkpoints, hash-based anchors or periodic re-signing already handle that for archived evidence. Swapping ECDSA for ML-DSA is close to a library change. The paper should explain why post-quantum signatures change the security of collusion audits in a meaningful way, or present them as an optional hardening step.

The threat model is unclear, and the main trust problem goes unaddressed. Colluding agents usually can’t edit host logs. The party who can is the operator, and the operator holds the signing keys and controls what gets instrumented. A Merkle log only shows that records weren’t changed after they were committed. It can’t show that the records were complete or truthful when they were written, or that agents didn’t act through channels outside the instrumentation. That is acknowledged in the limitations, but it is the central issue for “proving what happened” and needs to be part of the design itself, e.g. via TEE attestation of the capture runtime or a capture layer independent of the operator.

Selective disclosure conflicts with reproducibility. For an auditor to reproduce a detector score, they need all of the detector’s inputs. Revealing only a subset works only if there is a zero-knowledge proof that the score was computed correctly. For LLM judges or activation probes, that means zkML, which is currently impractical at that scale. Lattice-based ZK is also an unusual choice compared with hash-based STARKs, which are already plausibly post-quantum. This is the hardest part of the proposal and the most hand-waved.

Several proposed metrics would pass automatically. A correctly implemented Merkle log detects any deletion, insertion or reordering after a checkpoint, so “≥99% tamper detection” can’t fail. “No reduction in detection quality” from logging is likewise expected by construction. More useful measurements would be overhead under realistic agent workloads, and what fraction of collusion-relevant activity (side channels, timing, external tools) the instrumentation actually captures.

Suggestions: Build the appendix prototype around an existing benchmark (e.g. Colosseum or a steganography task). Show a full end-to-end example: an alert, an attempted tamper that gets detected, and a successful replay. Report the overhead. Narrow the claims to what tamper-evident logging adds for collusion audits specifically.