Skip to main content
When a policy rule evaluates to require_approval, Memproof pauses the operation and waits for an explicit approve or deny decision before persisting the memory. This guide covers the full lifecycle.

When Approval is Triggered

An operation enters the approval flow when:
  1. A policy rule with action: require_approval matches the operation.
  2. The operation is a mutation (remember, update, or forget).
The response will have status: "pending_approval" and the operation will not be written to the backend adapter until resolved.

The ApprovalBroker

The ApprovalBroker is the component that manages pending approvals. It supports two modes:

Manual Approval (Default)

When Attesta is not configured, the broker queues the operation and returns None from request_approval(), signaling the orchestrator to set status to pending_approval.

Attesta Integration

When enabled, the broker sends an action context to the Attesta /v1/actions/evaluate endpoint. Attesta returns a synchronous verdict (approved, modified, or denied).
If Attesta is unreachable, the broker returns approved=False with a note explaining the failure. The operation is denied rather than silently approved.

Resolving Pending Operations

1

Check operation status

Use the operation ID from the original response to check current status.
2

Approve the operation

Call approve() with an actor ID identifying who approved it.
3

Or deny the operation

Call deny() to permanently block the operation.

Action Context

The broker builds an Attesta-compatible action context for each pending operation:
Content is truncated to 200 characters in the action context preview. The full content is never sent to external approval services.

End-to-End Example

In a web application, expose the approve() and deny() methods behind authenticated admin endpoints. The operation_id serves as the stable reference between the request path and the review UI.