intake

Overview ¶

Command intake shows the approval intake: an application mounts approvals.Handler so approvers decide on a gated call over HTTP, and the application stays the only writer of its journal and the only signer of its audit log.

The application runs a refund agent whose "refund" tool waits at a 2-of-3 gate (ops, finance, risk) with separation of duties: ops started the run, so ops never counts. The intake is approvals.New with

• WithGatePolicy: the policy the tool was built with, so the handler counts a gate as the agent does (required);
• WithAuth: a hook that authenticates the caller from a bearer token and, once the body names the approver, binds the token to that approver (required when the browser page or CORS is on, and the way to keep arguments away from callers who should not see them);
• WithPage: the browser approve page, served from the application at /approvals/page/ (the page says it is in this mode: the stronger setup hosts the page on the approver's own origin, see docs/guides/hitl-approval.md#approving-in-the-browser);
• OnRecorded: the application's rule for continuing a run once its gate is decided.

Each approver's client does what bide approve -to does: it fetches the pending call, signs the decision over the arguments it showed (agent.ApprovalDecisionBytes), and posts it. The intake verifies the signature against the recorded call and the approver's enrolled key, and records the decision through the application's journal, which an audit.AuditedStore signs as it is written. The example ends by checking, from the receipt the intake returned, that a signed tree head of the journal commits to the decision.

It runs with no API key and no network beyond a loopback listener:

go run ./examples/intake