Part V — How can agents do financial work while humans keep the authority?
Reference implementation: cognokratos/tauros-revenue (Ταύρος), branch main, pinned in Source revisions.
Stack: Elixir 1.20 / Erlang 29, Phoenix LiveView, Ash, AshStateMachine, AshAI, PostgreSQL.
How do you let an AI take part in a financial workflow without giving it financial authority?
Tauros answers with architecture, one layer at a time:
identity → ownership → immutable financial intent → lifecycle constraints
→ idempotency → human authority → exact approval → concurrency → audit
→ narrow AI capability
By the end of the course you can point at the exact lines that stop an AI from approving an invoice, whether it tries through the UI, the REST API, MCP or a prompt it was tricked into following.
What is implemented
The course, the exercises and capstone, and the implementation they teach were
developed on a learning branch and are now merged into main. The merge
(a247cfc) is a squash merge whose tree is identical to the last learning
commit. The book follows main at the pinned revision:
Implemented and tested on main | Still roadmap |
|---|---|
| Humans and agents as distinct actors; generated, rotatable agent API keys | Database-enforced append-only audit (Epic 5) |
| Per-agent ownership of customers and invoices | Issuing, payments and reconciliation (Epic 6) |
| Payment destinations: public addresses or IBANs, checksummed, retired rather than edited | Data protection (Epic 7) |
| Immutable invoice revisions sealed with a SHA-256 payload hash | Semantic search and summaries (Epic 8) |
An AshStateMachine lifecycle with no writable state | An optional adapter to Arktos (Epic 9) |
| Idempotency keys per agent | A four-eyes rule: today an approver decides on their own agents' proposals |
| Exact-payload approval: the approver submits revision and hash | |
| Row locks and a unique index giving one decision per revision | |
An InvoiceEvent record of every command, append-only by application code | |
AshAI at /mcp, for agents only, with exactly eight reviewed tools (four reads, four proposals) |
Earlier editions of the CognoKratos organisation profile described the
pre-merge main, where the invoice lifecycle was "next" and AI tools were
"planned". The profile has since been updated.
The central guarantee
An agent cannot approve an invoice. There is no approve tool on the MCP
surface, the Invoice policy forbids decisions unless the actor is a human
approver who owns the proposing agent, and an Approval record can only be
created through that decision. Tests in
adversarial_test.exs
attack each layer and name the guard that stopped them. The
AI capability is not authority
chapter lists all the layers and carries a book note on which of them are
independently sufficient.
How this part is organised
The course is reproduced in its own order, in four sections:
- Identity and ownership, lessons 1–3: who may act, and on what?
- Financial intent, lessons 4–7: what exactly is proposed, and how does it move?
- Human authority, lessons 8–11: who decides, on exactly what, and can we prove it later?
- AI capability, lessons 12–16: how do we let a model in without letting authority out? It ends with the capstone.
Every lesson follows the same rhythm: Goal · Concept · Code to inspect · Run it · Break it · Why it fails · What to remember · Next. The runnable labs, including the capstone labs, are in Exercises. The longer explanations are in Concepts. Reference holds the authority argument, the MCP interface and the domain model.
The lessons mention roadmap epics by number. The Glossary lists them.
Running the labs
Erlang 29.1.1 and Elixir 1.20.4 (from .tool-versions), PostgreSQL 15 or newer
(the docs use 17) on localhost:5432, and curl and jq for the MCP lessons.
mix setup needs network access and seeds an approver, an agent and
proposals to review. mix test runs every lesson's guarantees as tests. The
MCP helper script builds curl headers in a way that may not work under zsh, so
start bash before sourcing it. See
Setting up each track.
Prerequisite. Reading Elixir. Ash is explained as it is used. Part I's human-in-the-loop concept and Part III's lesson A5 are useful background.