DEV Community

Quinn
Quinn

Posted on Originally published at pinkwallet.com

An n8n AI Agent That Pays Invoices Only Inside Rules You Set

Short answer: in n8n, you don't give the AI Agent node a spending limit in its prompt. You attach an MCP Client Tool node pointed at a payments server that enforces the limit itself, so the workflow's "pay this invoice" step always resolves to one of three states it didn't decide on its own: allowed, waiting on a person, or blocked. Pink Agentic AI Payments checks each payment an agent requests against per-agent budgets and rules before it executes, and routes the rest to a human. That is what the MCP server is doing underneath the n8n node.

Disclosure: I work on Pink Agentic AI Payments at PinkWallet; it's used as the worked example below.

The workflow, step by step

This follows Pink's own n8n connect guide, which walks through five steps:

  1. Create a sandbox workspace. Open agentic-sandbox.pinkwallet.com, enter a company name, pick a template, and create the workspace. You get back, per the guide, "an admin key for the console and one key per AI agent."
  2. Copy an agent key from the workspace page or the console.
  3. Add the MCP Client tool to the AI Agent node. The guide's exact instruction: set the endpoint to https://agentic-sandbox.pinkwallet.com/mcp, the server transport to HTTP Streamable, and authentication to Bearer Auth with a credential holding the agent key.
  4. Run the workflow. Give the agent the purchase as input; the execution log shows each Pink tool call (pink.check_policy, pink.request_payment, etc.) the same way any other n8n node's output would show.
  5. Watch approvals land. Open the sandbox console linked from the workspace page. Requests that cleared, asked a person, or were blocked are all listed there with the rule that decided it.

That's the whole integration surface: n8n's AI Agent node calls tools the same way it would call any other MCP server, and the policy decision happens entirely on the other side of that call, not in the agent's instructions.

The three outcomes, verified against the live sandbox

I didn't run n8n itself for this. I verified the same MCP/REST calls the n8n workflow above would make, directly against the live sandbox on 2026-10-02, using the "coffee" template's Purchasing AI agent. These are the exact HTTP responses, trimmed:

Invoice under the small-order threshold: clears immediately:

curl -X POST https://agentic-sandbox.pinkwallet.com/v1/payments \
  -H "Authorization: Bearer $AGENT_KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: n8n-demo-1" \
  -d '{"payee_id":"p_sysco","amount":80,"purpose":"Invoice INV-2201 weekly syrup top-up","local_hour":14}'
Enter fullscreen mode Exit fullscreen mode
{
  "decision": "allowed",
  "payee": "Sysco",
  "amount": 80,
  "rule": "Small supply orders go through",
  "credential": {
    "type": "virtual_card",
    "sandbox": true,
    "max_amount": 80,
    "locked_to": "Sysco",
    "single_use": true,
    "expires_at": "2026-10-02T17:59:33.265Z"
  }
}
Enter fullscreen mode Exit fullscreen mode

A single-use test card, locked to that payee and amount, expiring in 15 minutes. In an n8n workflow this is the value you'd pass to whatever actually charges it (in the sandbox, nothing further: the credential is the point being demonstrated, not a real charge).

Invoice above the agent's own-judgment ceiling: waits for a person:

curl -X POST https://agentic-sandbox.pinkwallet.com/v1/payments \
  -H "Authorization: Bearer $AGENT_KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: n8n-demo-2" \
  -d '{"payee_id":"p_uline","amount":900,"purpose":"Invoice INV-5541 bulk cup and lid order","local_hour":14}'
Enter fullscreen mode Exit fullscreen mode
{
  "decision": "pending_human",
  "payee": "Uline",
  "amount": 900,
  "rule": "Bigger supply orders: store manager checks",
  "hold_id": "pay_bedb514cf3f2",
  "approvers_needed": 1,
  "who": "Luis Ortega (Store manager)",
  "expires_at": "2026-10-02T18:14:33.458Z",
  "poll": "pink.get_credential(hold_id) · or GET /v1/payments/{id}"
}
Enter fullscreen mode Exit fullscreen mode

The workflow doesn't need to build its own approval UI. It polls pink.get_credential(hold_id) (or GET /v1/payments/{id}) until the hold resolves, or just stops here and lets the console be where a human acts. If the approval window times out before anyone responds, the hold expires and the n8n run gets back expired, not a silent approval.

A category the policy never allows: blocked outright, no approval path:

curl -X POST https://agentic-sandbox.pinkwallet.com/v1/payments \
  -H "Authorization: Bearer $AGENT_KEY" -H "Content-Type: application/json" \
  -H "Idempotency-Key: n8n-demo-3" \
  -d '{"payee_name":"Quick Gift Cards LLC","amount":50,"purpose":"Gift cards for staff appreciation","local_hour":14}'
Enter fullscreen mode Exit fullscreen mode
{
  "decision": "blocked",
  "payee": "Quick Gift Cards LLC",
  "amount": 50,
  "rule": "Never: gift cards, cash-like, crypto",
  "credential": null,
  "why": "matched · block"
}
Enter fullscreen mode Exit fullscreen mode

No hold, no escalation path. This is a circuit breaker, not a rule waiting on a person. The agent gets told no and that's the end of the branch.

What this buys an n8n workflow specifically

n8n workflows that touch money usually end up with one of two shapes today: a human approves every step in the workflow builder (which defeats the point of automating it), or the workflow has an API key with a blank check and a hope that the prompt behaves. The MCP-server pattern above gives you a third shape: the AI Agent node can run unattended for the cases the policy already covers, and the workflow naturally branches on the decision field for the cases it doesn't. pending_human and blocked are just different outputs from the same tool call, not different code paths you have to build yourself.

One thing worth being precise about: in the sandbox, the evidence an agent attaches to a request (like a matching purchase order or an invoice number) is self-asserted by whatever calls the tool, not independently checked against a connected accounting system. If your n8n workflow is pulling invoice data from an actual accounting tool, you still want that cross-check to happen somewhere before the payment request is made, not assumed by the policy engine.

Try it

Sandbox only: test credentials, no real money moves, production not available yet. The full setup is in Pink's n8n connect guide; the MCP endpoint, OAuth and a 5-minute quickstart are on the developer docs page; the sandbox itself is free to spin up at agentic-sandbox.pinkwallet.com. Want to draft the rules first? The spending-policy generator turns six answers into Pink rules and runs them against the sandbox.


Pink Agentic AI Payments (by PinkWallet) is the approval layer between AI agents and company money: plain-language rules, per-agent budgets, and human approvals decide each payment before a single-use payment credential is issued.

Top comments (0)