My auditor could read what I said it couldn't. Fixed, and you can test it

My README has said since 19 October that an allowed action stays hidden from the auditor. It did not.

I found this on 14 November. The auditor and the guard were sent the action, its details, and the secret meant to hide them. All of it in plain text. My tests could not catch it, because the Daml Script cannot see what a call is given.

It is fixed. This command shows what the auditor is sent now, and a control proves it would catch a leak:

File dominicrume/cantor8_kya_rails

tools/who_sees_the_attempt_arguments.py

#!/usr/bin/env python3
"""Does the auditor receive what an attempt is made of? Measured on a real ledger.

    python3 tools/who_sees_the_attempt_arguments.py

WHY THIS EXISTS. step-0-refusal says an auditor learns that an attempt
happened and, for a refusal, what it was. For an attempt that was ALLOWED it
says the auditor learns a count and nothing else. On 14 November 2026 a review
of the Daml pointed out that this was a claim about what the code does and
nobody had looked at what the auditor's participant is actually sent.

Daml Script cannot look. It has no primitive for reading the update stream, so
every test passed while the claim was false: `Open` took a salt, an action and
a detail as choice arguments, and the auditor and the guardian, who are
signatories of the journal, are informees of that exercise and were sent all
three in plain text. `Allow` took an action and discarded it, and that was
delivered too. `SettleAttempt` took them again. A scratch version of this
tool, run on a local sandbox against the code as committed that morning
(f49ac18), found the salt, the action and the detail all present in the
auditor's and the guardian's streams. This version measures the fixed API.

This file has been truncated. show original

One thing I cannot solve. Before, finishing an action proved it matched what was promised up front. Now it does not. How would you tie the two together without showing the auditor the secret?

Also built since: a test for Georgi Radev’s point of 27 October and a check for tonozzibeverley953’s topology idea of 13 November.

What is still weak:

File dominicrume/cantor8_kya_rails

docs/threat-model.md

# Threat model

What this system defends against, what it does not, and what an attacker gets
if each part fails. Written to be argued with.

**The asset:** a float held in one country, spent by an operator in another,
under a mandate issued by a principal who cannot be present.

**The trust boundary:** the operator is *not* trusted. Neither is the machine
it runs on, nor the messages it receives. The ledger is trusted. The
principal's key is trusted.

---

## T1 — The operator is persuaded to pay the wrong account

*"Change of account, send it here instead."* The commonest way money leaves a
business like this, and it does not require a dishonest operator — only a
convinced one. Against an AI operator this is prompt injection; the mechanism
differs, the outcome is identical.

This file has been truncated. show original