Approvals and Policy

Approvals let an automated workflow stop before a sensitive side effect, show a human or external policy system exactly what is being authorized, and resume the same operation after a verified decision.

This is stronger than returning “please approve” text from a tool. Approval is a first-class, durable protocol lifecycle.

When to Require Approval

Typical examples include:

• issuing a refund above a threshold;
• deleting customer or employee data;
• sending a legally significant message;
• changing credentials, roles, or identity records;
• committing a plan that has changed in value or scope;
• executing an operation outside normal policy.

Approval should follow risk and policy, not simply whether a human happens to be online.

The Lifecycle

stateDiagram-v2
    [*] --> Pending
    Pending --> Approved: authorized decision
    Pending --> Denied: authorized decision
    Pending --> Expired: TTL elapsed
    Approved --> Revoked: valid revocation
    Approved --> ActionResumed: policy and input still match
    ActionResumed --> [*]
    Denied --> [*]
    Expired --> [*]
    Revoked --> [*]

When policy blocks an action:

1. The runtime freezes the governed action and identity context.
2. It creates an ApprovalRequest with a policy snapshot and hash.
3. The action moves to pending_approval.
4. An authorized principal submits an ApprovalDecision.
5. The runtime verifies authority, TTL, separation of duties, constraints, evidence, and policy hash.
6. An approved decision resumes the original action. A denial, expiration, or revocation produces a terminal policy outcome.

Approval Rules

Policies can require:

• a specific principal;
• a member of a trusted role or group;
• a tenant-owned policy decision;
• a verified external approval system;
• all or any child rules;
• a quorum of distinct principals;
• a non-revoked delegated authority grant with risk or value limits.

minimum_distinct_principals and separation-of-duties controls prevent one identity from satisfying a workflow intended for independent review.

Evidence

An approval request may reference a reason, input snapshot hash, policy decision, external ticket, or attachment. Sensitive action input is not copied into ordinary approval, receipt, callback, or audit payloads.

An authorized approver can explicitly request the immutable approval evidence payload. That export requires both approval visibility and sensitive evidence scope. The exported hash must match the governed action.

Constraints

An approval may attach machine-readable constraints, such as a maximum refund amount or an exact destination account. The runtime and connector must enforce those constraints at execution time. A comment that is not evaluated by code is not a safety control.

Preventing Approver Spoofing

The approver field identifies the claimed decision maker. The runtime accepts it only when trusted authentication and authority resolution bind the request to that principal. Role names, tenant ids, and delegated grants supplied only by the caller are ignored.

For high-risk operations, also bind the decision to:

• the approval id;
• the action id and capability id;
• the policy hash and version;
• the governed input hash;
• an expiration time;
• a stable decision id for replay protection.

Approval Is Not Escalation

Approval asks whether a known operation may proceed. Escalation asks a human to provide input, take over, handle a policy exception, or choose among broader outcomes. Both are first-class states, but they solve different problems.

Operator Checklist

• Use server-owned authority membership data.
• Require a meaningful TTL.
• Keep requester, operator, and approver identities distinct where required.
• Store policy snapshots and hashes with the approval record.
• Emit policy and approval receipts.
• Resume the original action rather than accepting mutable replacement input.
• Make denial, expiration, and revocation visible in the operational read model.