Skip to main content

Human approval

require_approval is one of Arclasp’s four backend policy outcomes. When it is returned for a governed action, the backend creates or reuses a pending Approval, moves the Chain into pending_approval, and the SDK waits for the approval to resolve. After approval, the SDK returns an allow-style decision. Denial or timeout raises instead.

Source-supported approval triggers

Current backend behavior includes approval gates for cases such as:
  • a single financial amount above the configured/default threshold;
  • a cumulative financial threshold crossing;
  • the first external communication;
  • impersonation, schema-change, or irreversible-action categories;
  • a governed action by a registered Critical-tier agent;
  • a high policy risk score;
  • unknown or unpriceable LLM cost where cost confidence is required;
  • crossing a configured monthly recorded LLM token-cost budget.
Not every trigger is exposed as a customer-configurable threshold. See Policies and Configuration for the controls that are actually customer-facing.

What your code sees

The customer-side action belongs after the governance call. Arclasp does not execute execute_customer_action(...) for you.

Dashboard approval

Authorized reviewers can resolve pending approvals from the authenticated dashboard: https://app.arclasp.com/dashboard/approvals The dashboard can present the approval in the context of its Chain and recorded governance evidence.

Email approval flow

Arclasp can notify approvers by email when configured. The email decision mechanism uses a signed token flow. A GET request is non-mutating so link scanners cannot decide an approval merely by opening a URL; the actual decision uses the protected decision path. Do not assume the email flow is just a redirect through Clerk to the dashboard. Dashboard-authenticated decisions and signed email-token decisions are distinct supported paths.

Approval timeout

The SDK accepts:
Two timeout cases can surface differently:
  • the backend marks the pending Approval as timed out, which can surface as an ActionDeniedError;
  • the SDK’s own local approval polling window expires first, which can raise ChainTimeoutError.

Fallback approvers

The SDK also accepts a fallback approver list:
The exact notification/escalation behavior is part of the approval service. Treat the current dashboard/API state as authoritative rather than assuming a custom per-Chain routing DSL exists. The current customer product does not expose a general policy rule editor that routes arbitrary workflows to arbitrary approver groups.

Scoped exceptions

An approval decision can create a scoped exception for matching future require_approval outcomes. Supported exception durations include:
  • 1h
  • 1d
  • 1w
  • 1m
  • single_use
The scope is derived from the triggering governed event rather than becoming an unrestricted bypass. Exceptions:
  • can bypass a matching approval gate;
  • do not bypass hard denies;
  • do not bypass the organization kill switch;
  • use atomic consumption for single-use grants.

Denial is terminal for new events on that Chain

Do not catch an ActionDeniedError and assume the same Chain can simply continue recording later actions. Denied and timed-out Chain states block new governed events. Move recovery, retry, or alternative work into an appropriate new workflow/Chain when your application needs to continue after a terminal denial.

Approval evidence

Approval resolution creates durable governance evidence. Approval certificate signing is part of the integrity path; if signing the complete approval evidence fails, the system should not commit a terminal approval or denial without the required evidence. Authenticated verification can later expose the supported approval integrity/status layers.