All use-cases

Agent-operable, still governed

An AI agent drives the system over MCP with a scoped token — and is still stopped at the four-eyes gate. Operable is not trusted.

The whole flow, end to end

Mail = email sent Bell = in-app alert Amber diamond = automatic check Teal diamond = a human decides
2 · HUMAN FOUR-EYES GATE 1 · AGENT ACTS Admin mints scoped PAT SHA-256 stored · raw shown once · no bare * Agent calls MCP tool forwards to the same route() as the UI Valid token? requireActor · Bearer PAT Holds required scope? AND semantics Zod valid? typed body Action → pending request maker = agent · via=token · fail-closed audit Approver ≠ requester? decided_by <> requested_by Human approves + rationale different principal · own audit row Action committed agent + requester notified yes yes yes human checker 401 Unauthorized invalid / revoked token BLOCKED no 403 forbidden_scope token lacks required scope BLOCKED no 422 ValidationError Zod schema mismatch no Agent self-approval blocked GovernanceError 403 four_eyes DEAD END — by design agent = requester then

The agent gets exactly the human grant — no more. It passes auth, scope, and schema like anyone, performs the action, and writes an audited pending request. But the four-eyes gate treats the agent as a principal: it cannot approve its own work. A human still signs off.

Why agent-operable is safe

  • The agent holds a scoped PAT, not the keys — every route is scope-gated (AND), and a missing scope is a clean 403, never a silent allow.
  • The same four-eyes rule that stops a human self-approval stops the agent — decided_by <> requested_by, enforced in code and at the database.
  • Every agent action and every human decision is an immutable, fail-closed audit row — the agent is a named principal, not an anonymous script.