Authentication & Approvals
Two boundaries, kept separate on purpose: scoped keys decide which agent can call which tools — and a human approval gate, out of band, decides what actually gets committed. The approval token never crosses the MCP boundary.
The token never crosses the MCP boundary.
Keys authenticate agents. They do not authorize decisions. Agents only propose — promoting a belief, approving a causal edge, or committing a medium-or-higher-risk decision requires a human approval, granted out of band (invariants I5 and I6).
The mechanism is plain: request_approval() creates a pending approval and returns instructions for the human — never the token. The human runs cascadian approve <short-id> in their own terminal; the token is generated there and verified server-side. Because no tool response ever contains it, no model output can contain it either — no prompt, however adversarial, can mint an approval. The boundary is architectural, not behavioral.
The server checks the approval requirement itself, computed from the decision row — not from tool arguments. An agent cannot lower a decision’s risk level to slip past the gate.