Models, tools, capability, identity and authority
Five words carry most of this book. In everyday conversation they blur together. In these systems each one is enforced by a different component.
Model
A model call returns a sample: fluent, often right, sometimes wrong, never guaranteed. It has no access to your systems and no memory between calls. Running at temperature 0 narrows the variation but does not remove it. Every architecture in this book treats the model as an untrusted, probabilistic decision maker. It is good at interpreting ambiguous intent, choosing among tools, synthesising evidence and explaining. It is not a source of truth and not a holder of authority.
Tool
A tool is a typed function the model may request. The runtime, not the model, executes it. With native tool calling the request arrives as structured data rather than prose. A tool's description is effectively part of the prompt, and its granularity decides how many round trips, and how many failure points, a task needs.
Capability
A capability is what a component can cause at all. In these systems it is usually defined by a tool surface behind a protocol boundary:
- the template's MCP server and the agent's
include:list; - exactly four wallet tools in Arktos, none of which returns secret material;
- exactly eight reviewed Ash actions exposed over MCP in Tauros.
A capability says nothing about whether a particular use is allowed. That needs identity and authority.
Identity
Identity answers who is calling, and the rule across the book is that neither the model nor the browser decides it. In Part I a gateway authenticates the user and mints identity headers that downstream services accept only from it. In Part IV the wallet owner is the API key presented in a header, resolved by an HMAC lookup, and never a tool argument. In Part V humans and agents are different kinds of actor, and an agent's API key identifies an agent, never an approver.
Permission and authority
These two are easy to conflate, and the distinction matters most:
- Permission is what an actor may do under policy: an Ash policy, an authorisation check, a row-ownership rule.
- Authority is the standing to make a consequential decision bind: to approve this invoice, to record this investment decision, to sign with this key. In these systems authority is held by a human, or by deterministic code acting on a human's explicit, verifiable decision, or by a key held outside the model.
An agent can have the capability to call a tool and the permission to propose, and still have no authority over the outcome. Tauros states this directly: an AI's capability is not authority. The Capability, permission and authority chapter compares how each project enforces the difference.
The boundary that matters
Where authority matters, it is enforced outside the model.
"Outside the model" means in a place a prompt cannot reach:
- a type or a schema: a value the model can never construct;
- a policy: a check that runs for every interface, not just the chat;
- a transaction: re-derive the state under a lock, then apply and audit together;
- a cryptographic check: a signed approval token, an HMAC-looked-up key. Its strength depends on who holds the key: the model never does, but a trusted runtime component does, and that component must be protected in its own right;
- a human decision: one that names the exact thing being approved.
The rest of the book is about building those places and testing that they hold.