Policy and approvals

Agents operate Torno; humans keep judgment over actions that are irreversible, sensitive, or spend money. Policy is the single choke point where that line is enforced — with three possible answers and a complete paper trail.

One evaluator, three outcomes

Every governed action passes through the same policy evaluator before anything else happens. Torno never calls an external provider first and sorts out permission later. The evaluator sees the actual Principal and its context and returns a structured verdict: allow, deny, or require approval.

Rules are declarative. They match on action kind, Principal class and scopes, risk, traffic, spend, Metric contention, Property, and Environment. Shipped defaults protect the system before you write a single custom rule, every rule renders in plain language, and loosening one requires typed human confirmation.

Scopes and Principals

Every Principal — human, agent, or API token — carries scopes. Agent and token defaults deliberately exclude principal administration, policy administration, approval judgment, and sensitive Customer reads. Approving an Approval Request is not a scope an agent can hold; only a human can approve.

Agent mutations also require reasoning. It is stored as a quoted claim in the audit record — visible to the approving human, never executed as an instruction.

Approval Requests

An Approval Request is a first-class object, not a chat message that scrolls away. It stores an immutable snapshot of the proposed action, the requester and their reasoning, the policy basis, risk and spend figures, an expiry, and delivery status. Its lifecycle distinguishes pending, approved, executing, executed, rejected, expired, cancelled, and execution failure.

Approval does something precise: it atomically reserves budget and mints a single-use execution grant, and the original idempotent request replays under that grant. The caller is never told to retry a spending action and hope for the best — the operation runs exactly once or not at all. The same flow works from the API, CLI, and MCP, where a gated call returns a structured pending-approval outcome instead of an error.

Spend governance

Money gets its own bookkeeping. An append-only ledger records reservations, releases, settlements, and observed actuals per Principal, campaign, and period. Ceilings apply per Workspace, Principal, and campaign, and are checked at evaluation and approval time. Two shipped defaults are worth knowing: agents have a daily spend cap of $50, and ad publishing always requires human approval. If the ledger is unreachable, spending fails closed — Torno stops rather than guessing your remaining budget.

Delivery: inbox, Slack, and email

A pending approval only matters if a human sees it. Approval Requests fan out to the in-app inbox and, when configured, to Slack and email. Slack and email actions use short-lived, single-use signed tokens, and every surface races through the same policy judgment, so exactly one approval wins no matter where you click.

Delivery is tracked as its own concern: retries with backoff, recorded failures, and a visible flag when a request could not be delivered — the doorbell can fail without corrupting approval truth. Preferences cannot disable the last effective channel for a critical Approval Request, and urgent items such as guardrail breaches bypass digest batching.

Audit

Every allow, deny, and approval verdict retains its rule trace and context: who asked, as which Principal, under which rule, with what reasoning, and what happened next. That history is the raw material for granting well-behaved agents more autonomy over time; no automatic autonomy dial ships today, and we would rather say so than imply one.

For the vocabulary used here, see the Glossary; for driving approvals from a terminal, see The CLI.