Every phase of every agent session lands in the agent_action_log table as an append-only row. The table is enforced by a database-level guard that refuses UPDATE and DELETE on persisted rows — the only column that ever mutates is merkle_anchored_at, and only the nightly anchor job is allowed to flip it.
The result: nobody (not Gopnik, not you, not a court order against Gopnik) can quietly edit the log.
The audit bundle
Any time you can download agent-audit-<YYYY-MM-DD>.json for a single UTC day. The bundle includes:
user_id— your accountutc_day— the day coveredmerkle_root— the SHA-256-based root of all rows that dayrows— the raw rows (already redacted of secrets)signature— ed25519 signature over everything above
A regulator (or you, or a forensic accountant) can verify the bundle by:
- Independently recomputing each row's leaf hash (SHA-256 with 0x00 prefix per RFC 6962)
- Folding leaves into a Merkle root with SHA-256(0x01 || left || right)
- Checking the computed root matches the bundle's
merkle_root - Verifying the ed25519 signature against the wallet's published audit pubkey
The hash function and tree construction are exactly the same as the academy's existing audit anchor (RFC-6962 style). The reasoning: regulators already understand the academy audit format from compliance reviews; not introducing a new shape was a deliberate decision.
The XRPL anchor
The Merkle root for each day is also committed to XRPL as a Memo on the wallet's audit-issuer account. This gives the system a third-party witness: a future you cannot make Gopnik's database lie because the root is published on-chain.
To check the anchor:
- Read the bundle's
merkle_root - Search XRPL for the issuer's transactions on that day
- Find a Memo of the form
agent-audit:<utc_day>:<merkle_root_hex> - Confirm the on-chain Memo matches the bundle's root
If they match, the bundle is provably what was anchored at the time. If they don't match, somebody tampered after the anchor — investigate.
Reading the action log
The action log UI shows the most recent 200 rows. Each row records:
- Phase:
plan/validate/execute/error - Session ID (8-char prefix shown; click to expand)
- Tool (executor phases only)
- Chain + tx hash (settlement phases only)
- Amount (financial actions only)
- Success / failure
Click a session to see every phase in detail, including the planner's input + plan output, the validator's verdict, and the executor's tool args + result. The raw JSON payload is in a collapsed <details> block.
What goes wrong, and what to look for
Unauthorised plans. The planner emitted a plan you didn't ask for. Disable the agent immediately and download the audit bundle. The planner's planner_input field shows the user prompt + context it saw; you'll see whether the prompt came from you or whether a script (e.g. a phishing site) is firing chat calls.
Validator-denied plans. Means the safety gate fired. Not a panic event — it's the architecture working. But look at why the planner is repeatedly emitting plans that get denied; that's a signal something is trying to coax the planner into misbehaviour.
Tx hashes you don't recognise. Cross-reference against your daily allowance. If the agent spent against your cap and you can't account for it in the action log, that's a critical incident — pull the audit bundle, file a support ticket, and disable the agent.
What you commit to with this certification
- The audit log is permanent; nothing the agent does is invisible to you
- The Merkle anchor is the cryptographic guarantee that the log can't be quietly edited
- You can independently verify any day's bundle using the published key + the hash function (RFC 6962 + SHA-256)
- Reviewing the action log occasionally is part of operating the agent
Congratulations — you've completed the AI Agents 101 curriculum. The exam follows. Pass threshold is 80% (higher than other 101 courses because this surface is genuinely riskier).