Confidentiality
Requests are sealed to the TEE key. Evaluation is not yet attested, and the trace says so.
The request is sealed with HPKE to the live TEE key; the evaluation runs on the host; and the attestation string on every trace tells you which of those you are getting.
rialo:host-evaluated:1786788003:2418:b1946ac92492d2347c6235b4d2611184The claim, split honestly
| Concern | Status |
|---|---|
| The spec and credentials in transit to REX | Sealed. HPKE to the live TEE key, fetched from the node. |
| The evaluation itself | On the host. Not inside an attested enclave. |
| What the trace claims | rialo:host-evaluated:, never rialo:enclave:. |
If you need "the payload was never visible to the operator", that is not supported for the evaluation step today. The attestation prefix is how you tell, and it will change only when the fact changes. See REX.
Evidence is hashed, not hoarded
Raw third-party payloads are never stored in full. What evidence keeps is:
content_hash— a digest of the bytes fetchedredacted_preview— a trimmed extract for a person reading an escalationexpires_at— which retires the preview while the hash stays
The two lifetimes are the design. Months later you cannot re-read a supplier's response, but you can still prove whether bytes someone shows you are the bytes that were checked — which is the claim a dispute turns on. A system that retains every response it ever fetched is a data-retention problem wearing a verification system's clothes.
The public trace redacts a person
/t/:id is a receipt anyone can open without an account, so it is deliberately
narrow:
- only settled warrants resolve — a held warrant is live operational state
- the organisation is never named, and neither is any person
actor.idis stripped, because a public receipt naming who approved a payment would let anyone holding two links work out who approves what
payload_hash still covers the full unredacted record, and the response states
which fields were removed. The hash will therefore not match the redacted body
you can see — that is intended, and naming the removed fields is what makes it
checkable rather than mysterious.
Secrets never reach a browser
The console is a backend-for-frontend. The session is an httpOnly cookie on the
console's own origin, forwarded server-side; no token reaches client
JavaScript. Nothing sensitive is in localStorage, and NEXT_PUBLIC_ is
lint-enforced against anything that looks like a secret, because that prefix
inlines a value into the browser bundle permanently.
Notifications carry facts, not authority
A push or Telegram message about an escalation carries four things: amount, payee, which clause failed, and time remaining. Enough to decide from a lock screen.
It carries no ability to act. The Telegram bot cannot release funds — it can only hand off to the console, where a passkey signs the decision — and there is a test asserting no Telegram-scoped route can settle anything. The one-time approval link resolves only for the person it was minted for, and burns on first use, so a forwarded message is worth nothing.
What is not claimed
- No end-to-end encryption between you and a payee.
- No confidential compute for the evaluation, yet.
- No recipient screening.
- No onchain custody — see contracts.