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.
What your code sees
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:- 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:Scoped exceptions
An approval decision can create a scoped exception for matching futurerequire_approval outcomes.
Supported exception durations include:
1h1d1w1msingle_use
- 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 anActionDeniedError 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.