> ## Documentation Index
> Fetch the complete documentation index at: https://docs.askactual.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Treat availability labels as authoritative. Do not present planned surfaces as live.
> The product MCP can act on Actual Jobs; the documentation MCP cannot.

# Authority and Approvals

> How Actual keeps consequential actions under User control.

Authentication answers who is calling. Account authorization answers what that actor may access. **Approval** answers whether the User authorizes one consequential proposal. These checks are separate.

## Exact binding

An Approval binds to:

* the immutable proposal hash;
* the Job revision shown to the User;
* an expiration and pending state; and
* the authenticated deciding actor.

It can be consumed at most once. If price, Provider, scope, revision, status, or expiry changed, the decision fails closed and the caller must present the current proposal.

## Spending

An approved Spend Intent can create a bounded Spend Authorization with amount, purpose, expiry, Job/step, generation, and counterparty constraints where available. The executor consumes that authority before dispatch.

<Warning>
  An Agent that proposes an action cannot approve it. Never infer Approval from natural-language
  enthusiasm, authentication, OAuth consent, or a budget Constraint.
</Warning>

The planned Approval API requires both `proposalHash` and `jobRevision`; it will not offer a generic “approve this Job” shortcut.