DEV Community

Cover image for How Dify Can Safely Call Enterprise Internal APIs
ZYM
ZYM

Posted on

How Dify Can Safely Call Enterprise Internal APIs

#ai

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

  1. Create an Agent in ATG and get its one-time Agent API key.
  2. Register an HTTP Tool in ATG, such as refund_order.
  3. Configure Dify's HTTP Tool to call /api/v1/invoke/{tool_name}.
  4. ATG authenticates the Agent API key.
  5. ATG evaluates policy: allow, deny, approve, or redact.
  6. If approval is required, ATG creates an approval record and does not call the target API yet.
  7. If execution is allowed, ATG calls the business API.
  8. ATG redacts the response and writes invocation/audit records.
  9. 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
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)