AI Agent Refund API Demo: Approval, Redaction, And Audit

Letting an AI Agent call a refund API is a good demo because it is simple and risky at the same time.

If an Agent can directly call a refund endpoint, several questions appear immediately:

• Who allowed this refund?
• Which amount should require approval?
• Was the refund API called before approval?
• Where are the execution result and approval evidence?
• Who is responsible if the Agent passes the wrong arguments?

ATG's refund demo proves that these questions can be handled in one governance path.

Agent -> ATG -> approve policy -> approval record -> approver -> refund API -> audit log

Demo Setup

After PostgreSQL, ATG Server, Mock API, and Web Console are running, execute:

npm run demo:local

The script creates isolated Agents, Tools, and Policies, then runs three scenarios:

• large refund approval;
• CRM response redaction;
• dangerous delete denial.

Refund approval is the easiest path to explain to business and security stakeholders.

Refund Approval Flow

1. The Agent calls refund_order.
2. Policy checks args.amount > 100.
3. ATG returns pending_approval.
4. ATG creates an approval record.
5. The target refund API has not been called yet.
6. An approver uses the API or Web Console to approve the request.
7. ATG resumes the original tool call.
8. ATG writes approval, invocation, and audit evidence.

The key point: when approval is required, the real API is not executed first.

What To Show In The Web Console

Focus on four views:

• Dashboard: pending approvals, successful calls, average latency.
• Approvals: status, reason, approver, comments.
• Invocations: request arguments, redacted response, policy decision, approval id.
• Audit Logs: tool.invoke.pending_approval and approval.approved.executed.

These views give security, business, and engineering teams a shared record of the same Agent action.

Why Approval Must Happen Before Execution

Many systems treat approval as an after-the-fact note: execute first, ask someone to approve later.

For refunds, user deletion, permission changes, or other business actions, that is not real approval.

ATG's approve policy stops target API execution when matched. It creates a pending invocation and approval record. Only after approval does ATG resume the original call.

Redaction And Credential Isolation

Refund approval is only one action-oriented demo. ATG also shows two common governance capabilities:

• CRM query results are redacted before returning to the Agent and before audit storage.
• Real business API credentials stay in the Tool Registry. Sensitive headers are encrypted at rest and shown as *** through management APIs.

The Agent cannot bypass approval and does not need to hold real business credentials.

Local Verification

npm run install:local
npm run doctor:local
npm run dev:local
npm run verify
npm run demo:local
npm run secret-header:local

If ADMIN_TOKEN is enabled:

ADMIN_TOKEN=local-admin-secret npm run demo:local

What This Demo Answers

This demo is not about proving that ATG can call an HTTP API.

It proves that:

• Agent calls can be authenticated centrally;
• high-risk actions can pause before execution;
• approved calls can resume the original request;
• results can be redacted;
• real credentials can stay outside Agent runtimes;
• calls and approvals can produce audit evidence.

PoC Extensions

This flow can be adapted to:

• refund approval;
• order cancellation;
• user permission changes;
• ticket closure;
• contract or invoice generation;
• CRM customer lookup;
• internal admin operations.

Conclusion

The refund demo is not valuable because of refunds alone. It is valuable because it makes the governance path concrete:

policy decision, human approval, credential isolation, response redaction, and audit evidence.

Once this path works, enterprises can start thinking seriously about letting Agents touch real systems.

GitHub: https://github.com/demonzym-hash/agent-tool-gateway