DEV Community: ZYM

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

ZYM — Fri, 03 Jul 2026 09:18:56 +0000

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

The Agent calls refund_order.
Policy checks args.amount > 100.
ATG returns pending_approval.
ATG creates an approval record.
The target refund API has not been called yet.
An approver uses the API or Web Console to approve the request.
ATG resumes the original tool call.
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

What Gateway Does An MCP Server Need Before Production?

ZYM — Fri, 03 Jul 2026 09:16:58 +0000

What Gateway Does An MCP Server Need Before Production?

MCP standardizes the connection between models and tools. But standardized connection does not automatically mean production readiness.

Once MCP tools touch real business systems, teams must answer practical governance questions:

Who is allowed to call this tool?
Should the call pause for approval?
Does the response contain sensitive data?
Where are the real tool credentials stored?
Can we audit what happened after an incident?

Agent Tool Gateway acts as the governance layer between MCP clients and enterprise HTTP tools.

MCP Client -> ATG /mcp -> Policy / Approval / Redaction / Audit -> HTTP Tool

Where MCP Production Risk Comes From

The risk is usually not the MCP protocol itself. The risk is the business action behind the tool.

For example:

data queries may leak customer information;
write operations may change orders, accounts, or permissions;
delete operations may be irreversible;
credentials scattered across multiple MCP servers or clients are hard to rotate and audit;
each tool implementing its own auth and logging makes incident review difficult.

When tools only read safe demo data, this may not matter. When they touch CRM, orders, refunds, tickets, permissions, or databases, enterprises need a shared control plane.

ATG's Minimal MCP Support

ATG v0.1 supports three MCP JSON-RPC methods:

initialize
tools/list
tools/call

tools/list exposes active tools from the ATG Tool Registry. tools/call does not bypass governance. It reuses the same control path as HTTP invoke:

authenticate the Agent API key;
find the Tool;
validate input schema;
evaluate policy;
create approval if needed;
call the target HTTP API;
redact the result;
write invocation and audit records.

Why MCP Should Not Hold Business Credentials Directly

If every MCP server or client stores business API tokens, three problems appear.

First, credentials are scattered and hard to rotate.

Second, permission and approval logic is duplicated.

Third, audit evidence is fragmented.

ATG keeps real business credentials inside the Tool Registry. Sensitive headers are encrypted at rest and shown as *** in management API responses.

Shared Gateway vs Per-Server Governance

Letting each MCP server implement governance may look simple at first, but it creates repeated work:

every server needs auth;
every server needs policy;
every server needs audit logs;
every server needs sensitive-data handling;
enterprise security teams must review many implementations.

A shared gateway keeps governance stable even as Agent frameworks and MCP tools change.

Local Verification

npm run install:local
npm run doctor:local
npm run dev:local
npm run mcp-client:local

You can also exercise MCP paths through the Python and TypeScript SDK checks:

npm run python-sdk:local
npm run typescript-sdk:local

These checks create isolated Agents and Tools, then verify REST invoke and MCP tools/call.

MVP Boundary

ATG v0.1 does not try to be a full MCP aggregator, marketplace, enterprise SSO system, or multi-tenant platform.

It proves one thing first:

MCP tool calls can reuse the same identity, policy, approval, redaction, credential isolation, and audit path.

Once that path is working, teams can decide whether they need SSO/RBAC, audit export, enterprise approval integrations, KMS/Vault, or Kubernetes deployment.

Who Should Try This

MCP server builders;
teams connecting MCP clients to internal tools;
enterprise AI platform teams;
private AI workflow integrators;
security and architecture teams.

Conclusion

MCP standardizes tool connection. ATG standardizes enterprise governance.

When tools reach real business systems, the protocol alone is not enough. Teams need a shared path for permission, approval, redaction, credential isolation, and audit evidence.

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

How Dify Can Safely Call Enterprise Internal APIs

ZYM — Fri, 03 Jul 2026 07:43:29 +0000

How Dify Can Safely Call Enterprise Internal APIs

Dify is great for building AI workflows quickly. But once a workflow starts calling internal enterprise APIs, the risk moves from "the answer may be wrong" to "the system may execute the wrong action."

Refunding an order, changing an account, querying CRM data, deleting a user, or creating a ticket should not be handled by giving an Agent direct access to business API credentials.

Agent Tool Gateway puts an independent governance gateway between Dify and enterprise APIs.

Dify -> ATG -> Policy / Approval / Redaction / Credential Isolation / Audit -> Business API

The Problem With Direct API Calls

When business APIs are configured directly inside an Agent workflow, several problems show up:

real business API credentials end up inside workflow tools;
each tool has its own permission boundary;
high-risk actions do not pause for human approval;
responses may contain phone numbers, emails, IDs, addresses, or other sensitive fields;
denied calls, approvals, failures, and audit evidence are hard to review;
governance logic has to be rebuilt when the Agent framework changes.

These issues may look small during a demo, but they become security and delivery problems in private enterprise deployments.

The ATG Boundary

Dify handles application orchestration. ATG handles tool-call governance.

The HTTP Tool exposed to Dify is only the ATG invoke endpoint:

POST http://localhost:8080/api/v1/invoke/refund_order
Authorization: Bearer {{ATG_API_KEY}}
Content-Type: application/json

Dify stores an ATG Agent API key. The real business API endpoint, business credentials, approval policy, redaction rules, and audit records stay inside ATG.

Minimal Flow

Create an Agent in ATG and get its one-time Agent API key.
Register an HTTP Tool in ATG, such as refund_order.
Configure Dify's HTTP Tool to call /api/v1/invoke/{tool_name}.
ATG authenticates the Agent API key.
ATG evaluates policy: allow, deny, approve, or redact.
If approval is required, ATG creates an approval record and does not call the target API yet.
If execution is allowed, ATG calls the business API.
ATG redacts the response and writes invocation/audit records.
Dify receives the governed result.

Three Demo Policies

1. Refund Approval

Small refunds execute immediately.
Large refunds return pending_approval.
An approver reviews the request in the ATG Web Console.
ATG calls the real refund API only after approval.

This validates that approval happens before execution, not as an after-the-fact note.

2. CRM Redaction

CRM returns phone numbers, emails, and ID-like values.
ATG redacts the response before returning it to Dify.
Audit records also store the redacted result.

The Agent can continue the task without receiving sensitive data it should not see.

3. Dangerous Operation Denial

delete_user matches a deny policy.
ATG does not call the target API.
Audit logs record the denied operation.

Local Verification

npm run install:local
npm run doctor:local
npm run dev:local
npm run demo:local
npm run dify:local

npm run dify:local reads examples/dify/http-tool.refund-order.json, calls ATG using the same HTTP shape that Dify uses, and verifies invocation plus audit records.

Why This Is Not Just A Dify Plugin

ATG should not be understood as a Dify plugin.

Dify is one entry point. MCP clients, LangChain, Python SDKs, TypeScript SDKs, and custom Agents can also enter the same gateway. What should be centralized is the enterprise control plane:

Agent identity;
Tool registry;
Policy;
Approval;
Redaction;
Credential isolation;
Audit.

Changing Agent frameworks should not require changing the governance model.

Who Should Try This

Dify private deployment users;
Dify integrators;
enterprise AI application teams;
backend teams exposing internal APIs to Agents;
security or architecture teams evaluating the risk of Agent actions.

Conclusion

Dify should orchestrate AI workflows. ATG should govern tool calls.

That boundary lets teams keep the Dify experience while centralizing permissions, approval, redaction, credential isolation, and audit evidence.

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