|
| 1 | +# Approval System |
| 2 | + |
| 3 | +## Overview |
| 4 | + |
| 5 | +The Approval System provides runtime enforcement of the `requires_approval` annotation. When a module declares `requires_approval=true` and an `ApprovalHandler` is configured on the Executor, the handler is invoked at **Step 4.5** of the execution pipeline — after ACL checks pass and before input validation begins. This allows human or automated review of sensitive operations before they execute. |
| 6 | + |
| 7 | +The Approval System is architecturally separate from the ACL System. ACL answers "who is allowed to call this module?" while Approval answers "does this particular invocation need sign-off before proceeding?" |
| 8 | + |
| 9 | +## Requirements |
| 10 | + |
| 11 | +- Provide a pluggable `ApprovalHandler` protocol that SDK implementations can satisfy with custom logic. |
| 12 | +- Enforce the approval gate at Executor Step 4.5, after ACL (Step 4) and before Input Validation (Step 5). |
| 13 | +- Skip the approval gate entirely when no `ApprovalHandler` is configured, or when the module does not declare `requires_approval=true`. |
| 14 | +- Support synchronous approval flows (Phase A) where `request_approval()` blocks until a decision is returned. |
| 15 | +- Optionally support asynchronous approval flows (Phase B) where a `pending` status is returned with an `approval_id`, and execution resumes when the client retries with an `_approval_token`. |
| 16 | +- Raise structured errors (`APPROVAL_DENIED`, `APPROVAL_TIMEOUT`, `APPROVAL_PENDING`) that map cleanly to protocol error codes. |
| 17 | +- Ship built-in handlers for common cases: `AlwaysDenyHandler` (safe default), `AutoApproveHandler` (testing), and `CallbackApprovalHandler` (custom function). |
| 18 | + |
| 19 | +## Technical Design |
| 20 | + |
| 21 | +### Approval Gate (Executor Step 4.5) |
| 22 | + |
| 23 | +The approval gate is inserted between ACL Enforcement (Step 4) and Input Validation (Step 5) in the Executor's pipeline. The algorithm: |
| 24 | + |
| 25 | +1. Check if `approval_handler` is configured on the Executor. |
| 26 | +2. If not configured, skip to Step 5. |
| 27 | +3. Check if the target module declares `requires_approval=true` in its annotations. |
| 28 | +4. If not, skip to Step 5. |
| 29 | +5. Build an `ApprovalRequest` containing `module_id`, `arguments`, `caller` identity, and the module's `annotations`. |
| 30 | +6. Call `approval_handler.request_approval(request)`. |
| 31 | +7. If `approved` → proceed to Step 5. |
| 32 | +8. If `denied` → raise `ApprovalDeniedError` with the handler's reason. |
| 33 | +9. If `timeout` → raise `ApprovalTimeoutError`. |
| 34 | +10. If `pending` (Phase B only) → raise `ApprovalPendingError` with `approval_id`. |
| 35 | + |
| 36 | +### ApprovalHandler Protocol |
| 37 | + |
| 38 | +```python |
| 39 | +class ApprovalHandler(Protocol): |
| 40 | + async def request_approval(self, request: ApprovalRequest) -> ApprovalResult: |
| 41 | + """Request approval for a module invocation. Returns the decision.""" |
| 42 | + ... |
| 43 | +``` |
| 44 | + |
| 45 | +Implementations receive an `ApprovalRequest` and return an `ApprovalResult`. The handler may block (waiting for human input via UI, Slack, etc.) or return immediately (auto-approve for testing). |
| 46 | + |
| 47 | +### Data Types |
| 48 | + |
| 49 | +**ApprovalRequest** carries the invocation context to the handler: |
| 50 | + |
| 51 | +| Field | Type | Description | |
| 52 | +|-------|------|-------------| |
| 53 | +| `module_id` | `str` | Canonical module ID | |
| 54 | +| `arguments` | `dict` | Input arguments for the call | |
| 55 | +| `caller` | `Identity \| None` | Caller identity from context | |
| 56 | +| `annotations` | `ModuleAnnotations` | Full annotation set of the module | |
| 57 | + |
| 58 | +**ApprovalResult** carries the handler's decision: |
| 59 | + |
| 60 | +| Field | Type | Description | |
| 61 | +|-------|------|-------------| |
| 62 | +| `status` | `str` | One of: `approved`, `denied`, `timeout`, `pending` | |
| 63 | +| `reason` | `str \| None` | Human-readable explanation | |
| 64 | +| `approval_id` | `str \| None` | Phase B: token for async resume | |
| 65 | + |
| 66 | +### Error Types |
| 67 | + |
| 68 | +| Error | Code | HTTP | When | |
| 69 | +|-------|------|------|------| |
| 70 | +| `ApprovalDeniedError` | `APPROVAL_DENIED` | 403 | Handler returns `denied` | |
| 71 | +| `ApprovalTimeoutError` | `APPROVAL_TIMEOUT` | 408 | Handler returns `timeout` | |
| 72 | +| `ApprovalPendingError` | `APPROVAL_PENDING` | 202 | Handler returns `pending` (Phase B) | |
| 73 | + |
| 74 | +All three extend the base `ApprovalError`, which extends `ModuleError`. |
| 75 | + |
| 76 | +### Built-in Handlers |
| 77 | + |
| 78 | +| Handler | Behavior | Use Case | |
| 79 | +|---------|----------|----------| |
| 80 | +| `AlwaysDenyHandler` | Always returns `denied` | Safe default when approval is required but no handler is configured | |
| 81 | +| `AutoApproveHandler` | Always returns `approved` | Testing and development | |
| 82 | +| `CallbackApprovalHandler` | Delegates to a user-provided callback function | Custom approval logic | |
| 83 | + |
| 84 | +### Protocol Bridge Handlers |
| 85 | + |
| 86 | +Protocol bridges (apcore-mcp, apcore-a2a) provide their own `ApprovalHandler` implementations that use protocol-native mechanisms: |
| 87 | + |
| 88 | +- **`ElicitationApprovalHandler`** (apcore-mcp) — Uses the MCP elicitation protocol to present an approval prompt to the AI client, which relays it to the human user. |
| 89 | +- **`A2AApprovalHandler`** (apcore-a2a, future) — Uses the A2A interaction protocol. |
| 90 | +- **`WebhookApprovalHandler`** — Sends approval requests to an HTTP endpoint and waits for a callback. |
| 91 | + |
| 92 | +### Phased Implementation |
| 93 | + |
| 94 | +| Phase | Scope | Requirement | |
| 95 | +|-------|-------|-------------| |
| 96 | +| **Phase A** | Synchronous approval: handler blocks until decision | **MUST** implement for conformance | |
| 97 | +| **Phase B** | Asynchronous approval: `pending` + `approval_id` + retry with `_approval_token` | **MAY** implement | |
| 98 | + |
| 99 | +## Key Files |
| 100 | + |
| 101 | +| File | Purpose | |
| 102 | +|------|---------| |
| 103 | +| `approval.py` | `ApprovalHandler` protocol, `ApprovalRequest`, `ApprovalResult`, built-in handlers | |
| 104 | +| `errors.py` | `ApprovalError`, `ApprovalDeniedError`, `ApprovalTimeoutError`, `ApprovalPendingError` | |
| 105 | +| `executor.py` | Step 4.5 integration in `call()`, `call_async()`, `stream()` | |
| 106 | + |
| 107 | +## Dependencies |
| 108 | + |
| 109 | +### Internal |
| 110 | +- **Executor** — The approval gate is embedded in the Executor pipeline at Step 4.5. |
| 111 | +- **Module Annotations** — The `requires_approval` field on `ModuleAnnotations` triggers the gate. |
| 112 | +- **Context / Identity** — Caller identity is passed to the handler for access-aware approval decisions. |
| 113 | + |
| 114 | +## Testing Strategy |
| 115 | + |
| 116 | +- **Unit tests** verify that the approval gate fires only when both an `ApprovalHandler` is configured and the module declares `requires_approval=true`. |
| 117 | +- **Handler tests** confirm each built-in handler returns the expected `ApprovalResult` status. |
| 118 | +- **Error mapping tests** verify that `denied` → `ApprovalDeniedError`, `timeout` → `ApprovalTimeoutError`, `pending` → `ApprovalPendingError`. |
| 119 | +- **Skip tests** confirm the gate is skipped when no handler is set, or when the module does not require approval. |
| 120 | +- **Integration tests** run a full pipeline execution with approval handlers to verify end-to-end behavior including error propagation to callers. |
| 121 | +- Test naming follows the `test_<unit>_<behavior>` convention. |
0 commit comments