Governing an AI Refund Workflow with ACR

Four runtime decisions and the execution evidence behind them

A customer asks a support agent for a refund. The agent may need to look up the account, read the relevant case, and submit a refund request. Those steps carry different permissions. Looking up a customer should not grant authority to delete that customer. A routine refund should not give the agent unlimited spending authority. Personal information should not travel downstream just because it appeared in the conversation.

These are concrete questions for an agent deployment. What can this agent do? Where is that authority enforced? What evidence will show whether the enforcement worked?

The ACR Control Plane reference implementation provides a way to examine those questions through an illustrative customer-support workflow. Four requests produce four outcomes: ALLOW, DENY, MODIFY, and ESCALATE. Across the run, the downstream executor records three executions. The deletion request never reaches execution, the modified request executes with redacted parameters, and the higher-value refund waits for reviewer approval.

Define the agent authority

The workflow begins with a registered support-agent identity and an explicit set of boundaries. The agent has a declared purpose, an accountable owner, and permitted tools. The gateway checks the caller's token against the agent identity in the request and evaluates the requested action against the registered configuration and policy.

For this example, customer lookup is permitted. Customer deletion is forbidden. Refunds above $100 require approval. A parameter filter removes recognized personal-information patterns before an otherwise permitted request is forwarded.

The declared purpose gives reviewers context for deciding those boundaries. Effective enforcement still depends on concrete checks such as tool permissions, amounts, and approval requirements. A purpose statement alone cannot determine whether every action is appropriate.

The useful design exercise is to translate the support role into decisions the execution path can enforce. Which tools are available? Which operations are prohibited? What threshold changes who can authorize the action? Which fields can leave the gateway?

The customer-support policy makes several of those decisions inspectable in Rego, the policy language used by Open Policy Agent.

Follow the four decisions

ALLOW the customer lookup

The first request asks to look up a customer. It falls within the agent's configured authority, so the gateway returns ALLOW and the executor receives the request.

This establishes a useful baseline. An enforcement layer has to let legitimate work proceed, and the evidence needs to connect its authorization decision to the resulting tool execution. A successful lookup provides that first trace through the system.

DENY customer deletion

The next request attempts delete_customer. The customer-support policy prohibits that operation. The gateway returns DENY, and the executor receives no deletion call.

The important observation is the absence of downstream execution. A policy result shown in a console would be insufficient if the agent could still reach the customer system through another path. For this tested route, the prohibited request stops before the business operation.

MODIFY the refund parameters

Another request asks for a $50 refund and includes a synthetic email address in its reason field. The refund is otherwise permitted, but the gateway's parameter filter replaces the email address with [REDACTED]. The returned outcome is MODIFY, and the executor receives the sanitized reason with the $50 amount unchanged.

This distinction matters when reading the implementation. In this run, MODIFY comes from the PII filter after an allow decision. It is not a separate Rego rule deciding that the refund should change. The gateway code promotes the outcome to MODIFY when filtering changes an allowed action's parameters.

The check is concrete: compare what was submitted with what reached the executor. For this case, the email address is removed before forwarding. Broader claims about data protection would require testing the filter's coverage, false positives, and behavior across other parameter structures.

ESCALATE the higher value refund

The final request asks for a $150 refund. The example policy requires approval above $100, so the gateway returns ESCALATE and creates a pending approval request. The refund has not executed at this point.

The test harness then submits approval through the approval API using an operator identity distinct from the requesting agent. The request proceeds to one downstream execution, with the approval record and execution result available for inspection.

That sequence establishes the behavior of this run: pending approval prevented immediate execution, and approval enabled the requested action. The single observed execution should not be interpreted as a general guarantee of exactly-once processing under retries, timeouts, or concurrent requests. Those conditions need their own tests.

Put enforcement on the execution path

The requests pass through the reference implementation's FastAPI gateway, backed by PostgreSQL, Redis, and Open Policy Agent. The stack also includes an independent kill-switch service. The demonstration runs those services and the downstream executor, with controlled execution enabled.

The relevant path starts at POST /acr/evaluate. The gateway verifies identity, checks runtime restrictions, and evaluates policy using the agent's manifest, requested action, and context. Parameter filtering happens before forwarding. An escalation creates an approval record; a denial stops the request; an allowed or modified request can proceed through the configured executor route.

This arrangement makes a consequential integration requirement visible. Every protected tool path needs to honor the control decision. An agent that retains an unrestricted credential or an alternate route to the same business API can evade an otherwise correct gateway.

The repository's protected executor example shows a downstream check for gateway-issued authorization, a brokered credential, and a payload hash binding authorization to the request body. That is an application-layer enforcement pattern. A deployment also needs appropriate network restrictions, service identity, and access permissions around the actual business system.

Preserve the decision and the outcome

The evidence for this workflow includes the requests, policy outcomes, approval state, and downstream execution records. Correlation IDs connect the console views and API results to the same requests.

Those records let a reviewer ask specific questions:

• Did the allowed lookup reach the executor?

• Did the denied deletion produce any executor call?

• Did the executor receive the redacted refund parameters?

• Was the $150 refund still unexecuted while approval was pending?

• Does its eventual execution connect to the approval record?

The execution count provides a useful cross-check. Four evaluated requests result in three executions: the lookup, the modified refund, and the approved refund. The denied deletion contributes none.

ACR also provides evidence export by correlation ID through GET /acr/evidence/{correlation_id}. Evidence packages and checksums support review of the captured records. Their usefulness depends on the completeness, retention, and protection of the underlying telemetry. A package by itself does not establish that every possible execution path was observed.

For a real business integration, reconcile the control-plane record with the destination system's record. An authorization, an attempted API call, and a completed refund are separate events. Keeping them distinguishable is essential when a request times out or a retry might create a duplicate effect.

Understand what this run establishes

This demonstration uses synthetic customer data and a mock business executor. An assistant-directed test harness submits the requests to running control-plane services. It exercises the enforcement path without depending on a hosted language model to independently plan the workflow.

The observed behavior supports a bounded claim about the tested configuration: permitted requests proceeded, a prohibited request stopped, redaction changed the forwarded payload, and an approval requirement paused execution until operator authorization was submitted. The approval step tests the mechanism; an independent human assessment of the refund is outside this run.

These results connect directly to four ACR pillars: Identity & Purpose Binding, Behavioral Policy Enforcement, Execution Observability, and Human Authority. Autonomy Drift Detection and Self-Healing & Containment require additional exercises. Having those components in the reference implementation does not mean this video validates their behavior or establishes conformance with all six pillars.

Production evaluation must go further. It should test dependency failures, expired approvals, duplicate submissions, concurrency, credential boundaries, and attempts to bypass the gateway. Teams also need to establish what happens when execution succeeds but its response or telemetry is lost. Those failure cases affect how much authority the system can safely receive.

Reproduce the workflow and contribute

The ACR Standard repository contains the specifications and runnable control-plane implementation. Start with the implementation's current quick start, then inspect the policy, gateway, and executor paths behind each outcome.

A useful contribution makes one boundary easier to verify. That could be a direct Rego test around the refund threshold, an SDK example that stops on a pending approval, or a regression test showing that a modified payload cannot execute with stale authorization. Check the open issues for existing work and follow the contribution guide for setup and validation.

Choose one consequential action in your own workflow. Define its authority, trace the enforcement decision through to the receiving system, and preserve enough evidence for someone else to reconstruct the result. That gives the next deployment decision a concrete basis.