CUSTODY
The key stays on the operator's machine. Here is how.
The agent that runs on the Kestrel Ledger is an advisor, not a signer. It can propose actions; it cannot execute them. Signing requires a separate process — on the operator's machine, after human review — and the constraint is enforced by code, not policy.
FROM PROPOSAL TO RECEIPT
Every transaction passes through five steps before it reaches the chain
No step is optional. The agent cannot short-circuit the overseer or operator review.
- Agent proposes an action — it has no signing capability
- Overseer verifies the proposal against policy gates and runs a second-model critic
- Operator reviews the plan and the critic's output, then approves or vetoes
- Key never leaves the operator's machine — signing runs locally in the overseer process
- Chain an on-chain receipt, readable on any block explorer
THE MACHINE-CHECKED CONSTRAINT
The agent's inability to sign is a structural fact, not a convention
Every CI push to this system runs tests/boundaries.test.ts, which asserts
that createWalletClient and privateKeyToAccount are absent from
the agent package source. If either import appeared, the CI build would fail. The agent
cannot sign — not because a policy says so, but because the signing primitives are
structurally absent from its source and that absence is checked automatically on every push.
Signing occurs in the overseer process, which runs on the operator's machine. The key is never transmitted to any external service. The operator can inspect the overseer source and the boundaries test themselves — there is no closed-box claim to take on faith.