What Zendesk AI agents are in 2026, and which parts can move money
Zendesk sells three AI products that people lump together as "Zendesk AI agents", and they carry very different authority.
AI agents (Essential) are included in every Suite and Support plan. They answer from your help center and hand off to a human. They do not touch money.
AI Agents Advanced is the former Ultimate product Zendesk acquired in 2024. It adds generative procedures, scripted dialogues, authorized actions and API integrations. A procedure is written in plain language, and you can insert actions, API integrations, parameters and links to other procedures into it. That is how an AI agent looks up an order, cancels it and refunds it without a person in the conversation. Zendesk opened a new actions experience to customers who bought AI Agents Advanced on or after 10 March 2026.
Copilot with auto assist sits beside your human agents at 50 dollars per agent per month. It suggests the next step, including actions, and the human clicks accept. The distinction matters: auto assist has a person in the loop by design, and the customer-facing AI agent does not.
For refunds specifically, Zendesk ships prebuilt Shopify actions that look up an order, cancel and refund an entire order, or refund selected items. Anything else, such as a Stripe refund, a store credit in your own billing system or a goodwill payout, is a custom action pointed at an API you choose.
How we measured the Zendesk MCP server
On 29 September 2026 we probed Zendesk with no account and no credentials, the same way anyone can repeat it. Zendesk does not run a shared MCP host. Each account gets its own server at https://<subdomain>.zendesk.com/api/mcp, so we tested three subdomains, including Zendesk's own help center at support.zendesk.com, and one subdomain made of random characters that belongs to nobody.
For each we requested the MCP endpoint itself, sent a real JSON-RPC initialize call, fetched the OAuth protected resource document at /.well-known/oauth-protected-resource/api/mcp, fetched the authorization server metadata, and sent randomly generated control paths under /.well-known/. The control paths are what keep a probe honest: several payment companies we measured earlier run catch-all servers that answer 200 to anything.
The MCP endpoint returned 401 with a JSON error body on every subdomain. The response carried a zendesk-service: zendesk-end-user-mcp header and no WWW-Authenticate header, so a client has to know the protected resource location in advance rather than being pointed to it. The protected resource document returned 200 with scopes_supported set to exactly ["read", "write"]. Random control paths returned 404, so the server is not a catch-all.
One result needs care. The random, unregistered subdomain returned the same protected resource document with its own hostname filled in. The document is generated from the hostname, so its existence proves nothing about whether an account exists. We only report what it says, not who it belongs to.
Two scopes, read and write, and what that means for an AI agent
The Zendesk MCP server publishes two scopes. read covers what an assistant can see. write covers everything it can change. There is no separate scope for updating a ticket versus deleting one, for editing help center articles, or for anything that touches an order. The authorization server supports dynamic client registration, PKCE with S256, the authorization code and refresh token grants, and token_endpoint_auth_methods_supported of none, which means public clients such as Claude Desktop, ChatGPT or Cursor can register themselves.
That is a reasonable design for a helpdesk. The MCP server itself does not issue refunds, because Zendesk does not hold your money: Shopify, Stripe or your billing system does. The practical point is narrower. When a support lead asks "can we give the assistant write access but only for tagging tickets?", the answer at the scope level is no. Write is one switch.
The money risk arrives from the other direction. Zendesk announced an MCP client at Relate in May 2026 and opened early access in June. It lets Zendesk's own AI agents call out to other MCP servers, and Zendesk names Stripe among them. In our measurement of payment MCP servers the Stripe MCP tool surface is one generic stripe_api_write that covers any POST, including refunds. Connect those two and a customer-facing AI agent has a path to your payment processor that no Zendesk setting caps by amount.
Where the refund limit lives in Zendesk AI agents
We read Zendesk's documentation on actions for auto assist and action flows, actions in AI agents, generative procedures, and the Shopify cancel and refund recipe. Here is what governs an AI refund today.
Approval in auto assist. Zendesk says actions that write data, "such as an action that refunds an order, should be marked as agent-approved so that an agent can validate the action before it's executed." Pre-approved actions run with no approval. If the same action appears twice in a procedure with mixed settings, it defaults to agent-approved. This is a real control, and it only exists because a human agent is in the conversation.
No amount field. The Shopify recipe tells the procedure to "cancel the order and calculate refund costs" and to refund shipping on a full cancellation. It contains no dollar threshold. The action settings we read offer pre-approved or agent-approved, not "approved below 100 dollars".
Customer-facing AI agents. The AI agents actions documentation describes adding actions to dialogues and procedures and notes that action flows in AI agents do not consume action credits. It describes no approval step and no amount limit. In practice a ceiling is either a sentence in the procedure ("only refund orders under 150 dollars"), which is an instruction to a language model, or a check you build into the API the custom action calls.
Rate, not value. Custom actions allow bursts of up to 280 executions, then 6 per second. That is a throughput limit on your API, not a refund budget.
The gap is the same one we found at Salesforce Agentforce and AWS AgentCore: the platform governs which actions an agent may take, and leaves how much money those actions move to you.
Zendesk automated resolutions, and the cost Zendesk does not bill
Zendesk bills AI agents per automated resolution: a request the AI agent resolved with no escalation to a human, confirmed by a separate language model check. Zendesk's billing article lists included resolutions of 5 per agent per month on Team plans, 10 on Growth and 15 on Professional and Enterprise. The allocation expires annually. When it runs out you choose between allowing overage, billed monthly, or pausing the AI agent. Zendesk says the overage rate is higher than the committed rate. Its pricing page, read 29 September 2026, lists Suite Team at 55 dollars and Suite Professional at 115 dollars per agent per month billed yearly, but prints no per-resolution rate. Third-party reviews widely report about 1.50 dollars committed and 2.00 dollars pay-as-you-go. We break the math down in our Zendesk AI agent pricing guide.
Notice what the meter counts. A resolution that ends in a 400 dollar refund costs about 2 dollars on the Zendesk invoice. The 400 dollars never appears there. And a refund is the quickest way to close a refund request without a human, which is exactly what the meter rewards. None of that makes Zendesk wrong. It means the resolution fee is the small, capped number, and the refund value is the large, uncapped one. Our AI agent cost breakdown shows the same pattern across vendors.
Zendesk is retiring API tokens, so plan the refund integration on OAuth
Zendesk is removing API tokens as an authentication method. The 30-day inactivity rule started on 28 July 2026. From 27 October 2026 accounts can no longer create new API tokens, and on 30 April 2027 the remaining tokens stop working. Any custom action, middleware or script that an AI refund flow depends on should be built on OAuth from the start.
That change is a good moment to separate duties. The OAuth client your AI agent uses to read tickets should not be the same credential that can move money in Shopify or Stripe. Put the refund behind its own service with its own policy, and let the agent ask that service rather than hold the payment key.
A rollout checklist for Zendesk AI agents that issue refunds
- Start refunds in auto assist, not the customer-facing agent. Mark every refund action agent-approved. Watch a month of suggestions before you let anything run unattended.
- Write the ceiling into the API, not only the procedure. A procedure sentence is guidance to a model. A check in the service the action calls is a rule.
- Set a per-refund cap and a daily total. A per-refund cap alone allows an unlimited number of small refunds, which is how a looping or manipulated agent leaks money.
- Refund only to the original payment method and never above the order total. That keeps a refund from turning into a payout to a new destination.
- Route anything above your threshold to a person. Tie the number to your average order value, so routine refunds flow and the unusual ones surface.
- Keep write scopes narrow. Give MCP write access only to the people and assistants that need it, and do not connect a payment MCP server to a customer-facing agent without a policy layer in between.
- Log the decision with the ticket. Record the agent, ticket, order, amount, rule applied and approver, so a refund audit does not start from a processor export.
How AgentsPay fits alongside Zendesk
AgentsPay does not replace Zendesk, Shopify or Stripe. It sits between the AI agent's action and the money. Your Zendesk custom action calls AgentsPay instead of calling the refund API directly, and AgentsPay applies the policy you set for that agent: a per-refund ceiling, a daily and monthly total, a counterparty and order match, and an approval threshold that pauses larger refunds for a one-tap human decision. The agent's credentials cannot change that policy.
Every refund lands in an audit trail tied to the agent and the ticket. The same controls cover goodwill credits and store credit. For the general pattern, see our AI agent refunds use case, and for the approval mechanics, human approvals for agent payments. You keep Zendesk's resolution meter for what it measures well, and add a spend limit for the part it was never built to measure.