An audit control that the audited party can switch off is not a control
Shipped a Daml module that makes an asset impossible to move without writing a ledger record of the attempt.
One word on your signatory line and an interface instance.
MIT licensed. No dependencies beyond the standard library.
github.comcantor8_kya_rails/step-0-refusal at main · dominicrume/cantor8_kya_rails
Records what an AI agent was REFUSED, not only what it did. Spending rules enforced in a Daml choice body; every attempt, blocked ones included, becomes a hash-chained receipt an auditor can verify...
The problem it solves is one I had for six weeks without seeing it.
I was recording what an agent refused: a hash chain, a counter, and an attempt record.
Every one of them was written by the application, which is the party the evidence is about.
An auditor asking, “Can I trust this record?” was being answered with:
“If the application chose to write one.”
The fix is not cryptography.
It is authorization.
A consuming choice in Daml needs the authority of the contract’s signatories.
So put a second party on the asset:
template Wallet
with holder : Party
guard : Party
balance : Decimal
where
signatory holder, guard
interface instance Journalled for Wallet where
view = JournalledView with owner = holder; guardian = guard
perform = do ... -- your work, untouched
The guard is also a signatory of the journal, so its authority is reachable only from inside a journal entry.
An application trying to move that wallet any other way holds the owner’s authority and nothing else.
The ledger refuses it.
Not discouraged. Refused.
The limit, because you would find it in a minute.
Daml hands a submitter the authority of every party it submits as.
An operator who can submit as the guard reaches the asset directly, and no record is written.
There is a test that performs that bypass and shows the counter never moves.
So it is a control when the guard is operated by someone who is not the actor, and a convention when one person submits as both.
Segregation of duties does the work.
The code makes it enforceable.
156 Daml scripts.
Deleting any authorization check turns a named test red.
None of it has run on DevNet, because I have never had a credential.
So weigh it as a design until it does.
If you want the reasoning for why a self-written chain is not evidence:
Hearsay (arXiv:2609.32495) injected 28 omissions into deployed agent harnesses.
A log outside the harness caught all 28.
A hash chain over the harness’s own record caught none.
The question.
Without contract keys, is there a Daml 3 way to guarantee an asset cannot be acted on except through a particular contract, without depending on a second party being operated by somebody else?
If there is not, then segregation of duties is the floor for every on-ledger control.
And that is worth knowing before you design one.
