Testing an AI Refund Workflow: Allow, Deny, Modify, and Escalate

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.

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? Those questions become easier to evaluate when you can inspect both the authorization decision and what actually reached the receiving system. This walkthrough uses the ACR Control Plane reference implementation to exercise four outcomes: ALLOW, DENY, MODIFY, and ESCALATE . Four evaluated requests produce three downstream executions. I created ACR. This example gives developers a concrete workflow to inspect, reproduce and challenge. The 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. The 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. The 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. The lookup falls within the agent’s configured authority. The gateway returns ALLOW , and the request reaches the executor. That 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. The next request attempts delete customer . The policy prohibits it, and the gateway returns DENY . The 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. This observation applies to the route exercised in the recording. Alternate credentials and direct access to the underlying business API need separate investigation. The third request asks for a $50 refund and includes a synthetic email address in its reason field. The 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. There is an implementation detail here: MODIFY comes from filtering the parameters after an allow decision. The refund policy itself does not rewrite the request. Compare 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. The final request exceeds the example’s $100 approval threshold. The gateway returns ESCALATE and creates a pending approval. At this point, the downstream execution count stays at two: the lookup and the sanitized $50 refund. The pending $150 refund adds no execution. The 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. That single observed execution establishes the result of this run. Retry, timeout, and concurrency behavior need their own tests. Start 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 . The 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. Also 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. The 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. The next useful step is to challenge a boundary: For 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. The 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. The aim is to make each control decision verifiable against what the receiving system actually did.