{"slug": "testing-an-ai-refund-workflow-allow-deny-modify-and-escalate", "title": "Testing an AI Refund Workflow: Allow, Deny, Modify, and Escalate", "summary": "Adam DiStefano built the ACR Control Plane, a reference implementation that governs AI agent actions through four outcomes: ALLOW, DENY, MODIFY, and ESCALATE. In a recorded run using synthetic customer data and a mock business executor, four evaluated refund requests produced three downstream executions, with a denied customer deletion never reaching the executor and a $50 refund sanitized by a PII filter before forwarding. The stack uses FastAPI, PostgreSQL, Redis, and Open Policy Agent, and DiStefano notes that retry, timeout, concurrency, and broader PII filter coverage still require separate testing.", "body_md": "A support agent handling a refund might need to look up a customer, submit an amount, and explain why the refund is appropriate. Each step raises a separate permissions question. Can it delete the customer? Can it refund any amount? Can it forward personal information from the conversation?\n\nThose questions become easier to evaluate when you can inspect both the authorization decision and what actually reached the receiving system.\n\nThis walkthrough uses the ACR Control Plane reference implementation to exercise four outcomes: **ALLOW, DENY, MODIFY, and ESCALATE**. Four evaluated requests produce three downstream executions.\n\nI created ACR. This example gives developers a concrete workflow to inspect, reproduce and challenge.\n\nThe recorded run uses synthetic customer data, a mock business executor, and an assistant-directed test harness calling running control-plane services. The harness submits predefined requests rather than relying on an independent language model to plan the workflow.\n\nThe approval step uses a distinct operator identity. It exercises the authorization mechanism; the recording includes no independent human assessment of whether the refund is justified.\n\nThe support agent has registered permissions and a declared purpose. Customer lookup is allowed, customer deletion is prohibited, and refunds above $100 require approval. A parameter filter removes recognized personal-information patterns before forwarding otherwise permitted requests.\n\nThe lookup falls within the agent’s configured authority. The gateway returns `ALLOW`, and the request reaches the executor.\n\nThat gives the run a baseline: a legitimate action can complete through the governed route. The decision and execution records should connect to the same request.\n\nThe next request attempts `delete_customer`. The policy prohibits it, and the gateway returns `DENY`.\n\nThe executor receives no deletion call. That is the result worth checking. A denial in a response or dashboard only helps if the protected operation also stops.\n\nThis observation applies to the route exercised in the recording. Alternate credentials and direct access to the underlying business API need separate investigation.\n\nThe third request asks for a $50 refund and includes a synthetic email address in its reason field.\n\nThe refund passes the policy check. The PII filter then replaces the email address with `[REDACTED]`, and the gateway returns `MODIFY`. The executor receives the sanitized reason while the amount remains $50.\n\nThere is an implementation detail here: `MODIFY` comes from filtering the parameters after an allow decision. The refund policy itself does not rewrite the request.\n\nCompare the submitted payload with the executor’s payload to verify this behavior. Filter coverage across other formats, nested structures, and less obvious personal information requires further testing.\n\nThe final request exceeds the example’s $100 approval threshold. The gateway returns `ESCALATE` and creates a pending approval.\n\nAt this point, the downstream execution count stays at two: the lookup and the sanitized $50 refund. The pending $150 refund adds no execution.\n\nThe harness submits approval through the approval API using an operator identity distinct from the requesting agent. The refund then reaches the executor, bringing the total to three.\n\nThat single observed execution establishes the result of this run. Retry, timeout, and concurrency behavior need their own tests.\n\nStart with the [implementation README](https://github.com/AdamDiStefanoAI/acr-standard/blob/main/implementations/acr-control-plane/README.md), then follow the [gateway code](https://github.com/AdamDiStefanoAI/acr-standard/tree/main/implementations/acr-control-plane/src/acr/gateway) from `POST /acr/evaluate`.\n\nThe stack uses FastAPI, PostgreSQL, Redis, and Open Policy Agent. The relevant path checks identity and runtime restrictions, evaluates policy, filters parameters, and either stops, queues approval, or forwards the action.\n\nAlso inspect the [protected executor example](https://github.com/AdamDiStefanoAI/acr-standard/blob/main/implementations/acr-control-plane/examples/protected_executor/README.md). It checks gateway-issued execution authorization, a brokered credential, and a signed payload hash.\n\nThe receiving service matters as much as the gateway. A deployment needs network and credential boundaries that prevent an agent from reaching the business system through an unrestricted route.\n\nThe next useful step is to challenge a boundary:\n\nFor each case, preserve the request, decision, approval state where relevant, and downstream result. An authorization, an attempted call, and a completed refund are separate events.\n\nThe [contribution guide](https://github.com/AdamDiStefanoAI/acr-standard/blob/main/CONTRIBUTING.md) covers setup and validation. Check the [open issues](https://github.com/AdamDiStefanoAI/acr-standard/issues) for related work. A useful contribution can be a focused reproduction, a regression test, or a correction to an instruction that failed on a fresh installation.\n\nThe aim is to make each control decision verifiable against what the receiving system actually did.`", "url": "https://wpnews.pro/news/testing-an-ai-refund-workflow-allow-deny-modify-and-escalate", "canonical_source": "https://dev.to/adamdistefanoai/testing-an-ai-refund-workflow-allow-deny-modify-and-escalate-4b70", "published_at": "2026-10-18 02:27:31+00:00", "updated_at": "2026-10-18 02:40:06.878769+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-tools", "developer-tools"], "entities": ["ACR Control Plane", "Adam DiStefano", "FastAPI", "PostgreSQL", "Redis", "Open Policy Agent"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/testing-an-ai-refund-workflow-allow-deny-modify-and-escalate", "markdown": "https://wpnews.pro/news/testing-an-ai-refund-workflow-allow-deny-modify-and-escalate.md", "text": "https://wpnews.pro/news/testing-an-ai-refund-workflow-allow-deny-modify-and-escalate.txt", "jsonld": "https://wpnews.pro/news/testing-an-ai-refund-workflow-allow-deny-modify-and-escalate.jsonld"}}