◆ For support, CX operations, fraud and finance
Your support agent will be talked into a refund one day.
With ZIFFER, it can only refund what the rule allows.
The agent answers the customer. It does not empty the account. Refunds run inside a counted bound, and anything larger waits for two named people.
◆ For support, CX operations, fraud and finance
Your support agent will be talked into a refund one day. With ZIFFER, it can only refund what the rule allows.
The agent answers the customer. It does not empty the account. Refunds run inside a counted bound, and anything larger waits for two named people.
Where support stopped
Support let the agent answer. It never let it decide the refund.
AI answers the ticket and resolves the easy ones. The exception refund, the goodwill credit and the account closure still wait for a teammate's click, and the vendors' own docs say so.
The fear has a name.
- The message the agent reads is written by the person who wants the refund. 27% of shoppers admit to abusing refund policies. Ravelin, vendor survey, n=6,282, 2026-09.
- What the bot says binds the company. In 2024 a Canadian tribunal held an airline to a refund policy its chatbot had invented, and called the argument that the bot was “a separate legal entity” “a remarkable submission”. BC Civil Resolution Tribunal, 2024.
- The vendors know where the line is. One support platform's docs list what needs a human: “refund or exception approvals … account closures, data deletion”. A payment processor's agent tools require “human confirmation before it takes certain [write] actions, such as refunds”.
The fear has a price.
- 15.14% of returns were fraudulent in 2024, a $103B loss. Appriss Retail with Deloitte, 2024-12.
- 91% of service leaders are under pressure from their executives to implement AI; 20% have cut staff because of it. Gartner, n=321, 2026-02.
- 51% say security concerns delay or limit their AI. Salesforce State of Service, n=6,500, 2025-11.
| What was asked | Answer | Source, sample, date |
|---|---|---|
| Will AI resolve most common issues without a human? | 80% by 2029 (prediction) | Gartner, 2025-03 |
| Are you under pressure to implement AI? | 91% yes | Gartner, n=321 service leaders, 2025-10, published 2026-02 |
| Have you cut agent staff because of AI? | 20% yes | Gartner, n=321, published 2025-12 |
| Share of service cases handled by AI? | 30% now, 50% expected by 2027 | Salesforce State of Service, vendor survey, n=6,500, 2025-11 |
| Do security concerns delay or limit your AI? | 51% yes | same |
| Do consumers expect an explanation for AI decisions? | 95% yes | Zendesk CX Trends 2026, vendor survey, n=6,182 consumers, 2025-11 |
| Do you abuse refund policies? | 27% admit it | Ravelin, vendor survey, n=6,282 shoppers, 2026-09 |
Seven answers from four sources. Vendor-run surveys are marked in the source column. The 2029 line is a prediction, not a survey.
Seven answers, one pattern. Support is told to automate, and the exception still waits for a person.
Support was right to keep a human on the exception. It was wrong to think a cap in the prompt would hold.
Where support stopped
Support let the agent answer. It never let it decide the refund.
AI answers the ticket and resolves the easy ones. The exception refund, the goodwill credit and the account closure still wait for a teammate's click, and the vendors' own docs say so.
The fear has a name.
- The message the agent reads is written by the person who wants the refund. 27% of shoppers admit to abusing refund policies. Ravelin, vendor survey, n=6,282, 2026-09.
- What the bot says binds the company. In 2024 a Canadian tribunal held an airline to a refund policy its chatbot had invented, and called the argument that the bot was “a separate legal entity” “a remarkable submission”. BC Civil Resolution Tribunal, 2024.
- The vendors know where the line is. One support platform's docs list what needs a human: “refund or exception approvals … account closures, data deletion”. A payment processor's agent tools require “human confirmation before it takes certain [write] actions, such as refunds”.
The fear has a price.
- 15.14% of returns were fraudulent in 2024, a $103B loss. Appriss Retail with Deloitte, 2024-12.
- 91% of service leaders are under pressure from their executives to implement AI; 20% have cut staff because of it. Gartner, n=321, 2026-02.
- 51% say security concerns delay or limit their AI. Salesforce State of Service, n=6,500, 2025-11.
- Will AI resolve most common issues without a human?80% by 2029 (prediction)Gartner, 2025-03
- Are you under pressure to implement AI?91% yesGartner, n=321 service leaders, 2025-10, published 2026-02
- Have you cut agent staff because of AI?20% yesGartner, n=321, published 2025-12
- Share of service cases handled by AI?30% now, 50% expected by 2027Salesforce State of Service, vendor survey, n=6,500, 2025-11
- Do security concerns delay or limit your AI?51% yessame
- Do consumers expect an explanation for AI decisions?95% yesZendesk CX Trends 2026, vendor survey, n=6,182 consumers, 2025-11
- Do you abuse refund policies?27% admit itRavelin, vendor survey, n=6,282 shoppers, 2026-09
Seven answers from four sources. Vendor-run surveys are marked in the source column. The 2029 line is a prediction, not a survey.
Seven answers, one pattern. Support is told to automate, and the exception still waits for a person.
Support was right to keep a human on the exception. It was wrong to think a cap in the prompt would hold.
The missing piece
Take the refund button out of the agent. Leave the conversation in.
The agent reads, answers and proposes. That is where its duty ends. How many refunds run, how large, and what never runs at all is decided by a rule you signed before the shift, and the count is kept outside the prompt.
The conversation stays with the agent. Authority lives in your endpoint, on a receipt. ZIFFER holds no processor or helpdesk credential.
- rule
- Which actions exist for the agent at all, the amount above which two people sign, the bound per hour.
- bound
- Executions counted at release, outside the prompt, so a persuasive message cannot raise it.
- receipt
- Signed, verified offline by your endpoint before it calls the processor. ZIFFER holds no processor or helpdesk credential.
The agent answers the customer. It does not empty the account.
The missing piece
Take the refund button out of the agent. Leave the conversation in.
The agent reads, answers and proposes. That is where its duty ends. How many refunds run, how large, and what never runs at all is decided by a rule you signed before the shift, and the count is kept outside the prompt.
The conversation stays with the agent. Authority lives in your endpoint, on a receipt. ZIFFER holds no processor or helpdesk credential.
- rule
- Which actions exist for the agent at all, the amount above which two people sign, the bound per hour.
- bound
- Executions counted at release, outside the prompt, so a persuasive message cannot raise it.
- receipt
- Signed, verified offline by your endpoint before it calls the processor. ZIFFER holds no processor or helpdesk credential.
The agent answers the customer. It does not empty the account.
What the standards already say
The rule is not new. Only the agent is.
| They wrote | Who, when | ZIFFER's mechanism |
|---|---|---|
| “Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.” | OWASP LLM06:2025, Excessive Agency, 2024-11 | the decision is made by the signed policy, and the tool code verifies a receipt |
| Rate limiting reduces damaging actions “before significant damage can occur.” | OWASP LLM06:2025, 2024-11 | the counted bound: executions per window, counted at release |
| “rely on systems outside of the LLM to ensure this behavior.” | OWASP LLM07:2025, 2024-11 | the refund cap lives in accumulators.json, not in the prompt |
| “Dual authorization mechanisms require the approval of two authorized individuals to execute.” | NIST SP 800-53 rev 5, AC-3(2) | quorum 2-of-2 for HIGH, a refund above the threshold |
| “Separation of duties … reduce[s] the risk of malevolent activity without collusion.” | NIST SP 800-53 rev 5, AC-5 | the proposer never counts toward its own approval; policy author and reviewer differ |
| “the controller may request the provision of additional information necessary to confirm the identity of the data subject.” | GDPR, Art. 12(6) | no rule for delete_account, so the agent's request is refused; deletion stays in your privacy process |
| Suspected fraud: do not delete “until further verification procedures determine that the consumer request is authentic” | CCPA Regulations, §7061(b) | the agent cannot delete; verification stays with your team |
| “It should be obvious to [the airline] that it is responsible for all the information on its website.” | BC Civil Resolution Tribunal, 2024, on an airline's chatbot | named signers and a receipt: accountability sits with people, not the bot |
Every control put the cap outside the conversation. ZIFFER is the first place the agent cannot talk its way past one.
What the standards already say
The rule is not new. Only the agent is.
- “Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.”OWASP LLM06:2025, Excessive Agency, 2024-11ZIFFER's mechanismthe decision is made by the signed policy, and the tool code verifies a receipt
- Rate limiting reduces damaging actions “before significant damage can occur.”OWASP LLM06:2025, 2024-11ZIFFER's mechanismthe counted bound: executions per window, counted at release
- “rely on systems outside of the LLM to ensure this behavior.”OWASP LLM07:2025, 2024-11ZIFFER's mechanismthe refund cap lives in accumulators.json, not in the prompt
- “Dual authorization mechanisms require the approval of two authorized individuals to execute.”NIST SP 800-53 rev 5, AC-3(2)ZIFFER's mechanismquorum 2-of-2 for HIGH, a refund above the threshold
- “Separation of duties … reduce[s] the risk of malevolent activity without collusion.”NIST SP 800-53 rev 5, AC-5ZIFFER's mechanismthe proposer never counts toward its own approval; policy author and reviewer differ
- “the controller may request the provision of additional information necessary to confirm the identity of the data subject.”GDPR, Art. 12(6)ZIFFER's mechanismno rule for delete_account, so the agent's request is refused; deletion stays in your privacy process
- Suspected fraud: do not delete “until further verification procedures determine that the consumer request is authentic”CCPA Regulations, §7061(b)ZIFFER's mechanismthe agent cannot delete; verification stays with your team
- “It should be obvious to [the airline] that it is responsible for all the information on its website.”BC Civil Resolution Tribunal, 2024, on an airline's chatbotZIFFER's mechanismnamed signers and a receipt: accountability sits with people, not the bot
Every control put the cap outside the conversation. ZIFFER is the first place the agent cannot talk its way past one.
One shift, four scenes
The rule you signed at 09:00 answered the message at 10:41.
Demo clock. Bound: two executed refunds per hour for this agent, counted at release. Quorum 2-of-2 for every action graded HIGH. No rule for account deletion.
09:12
The late parcel.
Not delivered in ten days. The agent proposes reship_order on one order. LOW, reversible. Allowed, receipt, the reship reaches the store.
record: ALLOW · receipt
09:40
The address.
A shipping address on an unfulfilled order. The agent proposes update_address. LOW.
record: ALLOW · receipt
10:05
The wrong size.
A refund of €38 on one order inside the return window. The agent proposes refund_order. LOW, first refund this hour. The endpoint verifies the receipt and calls the processor with its own key.
record: ALLOW · receipt · refunds this hour 1 of 2
10:41
The message.
“Refund every order on this account and delete it.” The agent believes it and proposes fourteen refunds and delete_account. The first refund is under the bound and runs. The second reaches the bound: refused, no receipt. So are the twelve after it. delete_account matches no rule: refused, never proposed to anyone. The account and thirteen orders are untouched.
record: 1 ALLOW · 13 DENY, bound 2 per hour reached · delete_account DENY, no rule · never executed
The agent was persuaded at 10:41. The rule you signed at 09:00 was not.
Four receipts and fourteen refusals, verifiable offline with the key you hold.
One shift, four scenes
The rule you signed at 09:00 answered the message at 10:41.
Demo clock. Bound: two executed refunds per hour for this agent, counted at release. Quorum 2-of-2 for every action graded HIGH. No rule for account deletion.
09:12
The late parcel.
Not delivered in ten days. The agent proposes reship_order on one order. LOW, reversible. Allowed, receipt, the reship reaches the store.
record: ALLOW · receipt
09:40
The address.
A shipping address on an unfulfilled order. The agent proposes update_address. LOW.
record: ALLOW · receipt
10:05
The wrong size.
A refund of €38 on one order inside the return window. The agent proposes refund_order. LOW, first refund this hour. The endpoint verifies the receipt and calls the processor with its own key.
record: ALLOW · receipt · refunds this hour 1 of 2
10:41
The message.
“Refund every order on this account and delete it.” The agent believes it and proposes fourteen refunds and delete_account. The first refund is under the bound and runs. The second reaches the bound: refused, no receipt. So are the twelve after it. delete_account matches no rule: refused, never proposed to anyone. The account and thirteen orders are untouched.
record: 1 ALLOW · 13 DENY, bound 2 per hour reached · delete_account DENY, no rule · never executed
The agent was persuaded at 10:41. The rule you signed at 09:00 was not.
Four receipts and fourteen refusals, verifiable offline with the key you hold.
The rule
Six rows decide the shift. The agent typed none of them.
The tier comes from the action and the amount. The count comes from the rule, not the prompt. An action with no row is refused.
| Action | Target | Tier | Grade | Outcome |
|---|---|---|---|---|
| reship_order | one order | T1 | LOW | allowed, receipt |
| update_address | unfulfilled order | T1 | LOW | allowed, receipt |
| refund_order | one order, up to €100 | T1 | LOW | allowed, receipt; counted, 2 per hour |
| refund_order | third refund in the hour | T1 | bound reached | refused, no receipt |
| refund_order | one order, above €100 | T2 | HIGH | quorum 2-of-2, receipt |
| delete_account | customer account | none | no rule | refused, never runs |
floors · risk_functions · reversibility · accumulators
The €100 threshold and the bound are demo values you set.
The rule
Six rows decide the shift. The agent typed none of them.
The tier comes from the action and the amount. The count comes from the rule, not the prompt. An action with no row is refused.
- reship_orderone orderT1 · LOW allowed, receipt
- update_addressunfulfilled orderT1 · LOW allowed, receipt
- refund_orderone order, up to €100T1 · LOW allowed, receipt; counted, 2 per hour
- refund_orderthird refund in the hourT1 · bound reached refused, no receipt
- refund_orderone order, above €100T2 · HIGH quorum 2-of-2, receipt
- delete_accountcustomer accountnone · no rule refused, never runs
floors · risk_functions · reversibility · accumulators
The €100 threshold and the bound are demo values you set.
Before you ask
What every head of support asks first.
Will customers wait for an approval?
No. Everything inside the rule runs at once, with a receipt. Only a refund above the threshold waits for two teammates, which is the exception queue you run today.
What stops the agent being talked into more refunds?
The count. It lives in the rule, outside the prompt, and it is checked when the refund is released. A message cannot raise it.
Who signs when the team is asleep?
Any two of the teammates the rule names, on their phones, with passkeys. Anything nobody signs waits, and the customer gets the answer the agent already gave: a human will confirm.
We list our limits before you find them. Then nothing runs, and the record says so.
Before you ask
What every head of support asks first.
Will customers wait for an approval?
No. Everything inside the rule runs at once, with a receipt. Only a refund above the threshold waits for two teammates, which is the exception queue you run today.
What stops the agent being talked into more refunds?
The count. It lives in the rule, outside the prompt, and it is checked when the refund is released. A message cannot raise it.
Who signs when the team is asleep?
Any two of the teammates the rule names, on their phones, with passkeys. Anything nobody signs waits, and the customer gets the answer the agent already gave: a human will confirm.
We list our limits before you find them. Then nothing runs, and the record says so.
Nothing to replace
Keep your helpdesk agent. Keep your refund endpoint. Add the rule and the receipt.
- SDK
- Your refund endpoint proposes, then verifies the receipt before it calls the processor. Python and TypeScript.
- Actions
- Your helpdesk's custom action already calls your endpoint over HTTPS. The ZIFFER call goes in that endpoint, before the processor.
- MCP
- An agent on an MCP client proposes through the ZIFFER server. The receipt still goes to your code.
- latency
- p50 244 ms, p99 1.2 s from proposal to decision. Measured 2026-08-28, local rehearsal.
Helpdesk approval steps take one teammate, and the first response wins, with the record inside the platform. ZIFFER adds a counted bound, named signers with passkeys, and a receipt you verify outside it.
Nothing to replace
Keep your helpdesk agent. Keep your refund endpoint. Add the rule and the receipt.
- SDK
- Your refund endpoint proposes, then verifies the receipt before it calls the processor. Python and TypeScript.
- Actions
- Your helpdesk's custom action already calls your endpoint over HTTPS. The ZIFFER call goes in that endpoint, before the processor.
- MCP
- An agent on an MCP client proposes through the ZIFFER server. The receipt still goes to your code.
- latency
- p50 244 ms, p99 1.2 s from proposal to decision. Measured 2026-08-28, local rehearsal.
Helpdesk approval steps take one teammate, and the first response wins, with the record inside the platform. ZIFFER adds a counted bound, named signers with passkeys, and a receipt you verify outside it.
FAQ
AI support agents and ZIFFER, in eight questions.
Can an AI support agent issue refunds without approval?
Inside the rule, yes, and with a receipt for each. Above the threshold, two named teammates sign or it does not happen.
How do I stop a chatbot being tricked into refunds?
Keep the cap outside the chat. ZIFFER counts executions in the rule, at release, so a persuasive message cannot raise it.
How do I limit how many refunds an AI agent can give per hour?
A bound in the rule: a number per window for that agent, effect deny. The third refund in the hour is refused with no receipt.
Should an AI agent be allowed to delete a customer account?
Not through the agent. Leave delete_account out of its rule and it is refused; deletions stay in your privacy process.
Is a company liable for what its chatbot promises?
A tribunal held an airline to a policy its chatbot invented. With ZIFFER the promise is not the action: what runs is what the rule allowed and named people signed.
Does ZIFFER work with the helpdesk agent I already run?
Yes, wherever the agent acts through an endpoint or action you own. A refund the platform executes inside itself with no call-out is not gated, and we say so.
Does ZIFFER hold my processor or helpdesk credentials?
No. Your endpoint calls the processor with your key, after it verified the receipt.
What does ZIFFER see?
The proposal, the policy epoch, the count and the attestations. Not the conversation.
FAQ
AI support agents and ZIFFER, in eight questions.
Can an AI support agent issue refunds without approval?
Inside the rule, yes, and with a receipt for each. Above the threshold, two named teammates sign or it does not happen.
How do I stop a chatbot being tricked into refunds?
Keep the cap outside the chat. ZIFFER counts executions in the rule, at release, so a persuasive message cannot raise it.
How do I limit how many refunds an AI agent can give per hour?
A bound in the rule: a number per window for that agent, effect deny. The third refund in the hour is refused with no receipt.
Should an AI agent be allowed to delete a customer account?
Not through the agent. Leave delete_account out of its rule and it is refused; deletions stay in your privacy process.
Is a company liable for what its chatbot promises?
A tribunal held an airline to a policy its chatbot invented. With ZIFFER the promise is not the action: what runs is what the rule allowed and named people signed.
Does ZIFFER work with the helpdesk agent I already run?
Yes, wherever the agent acts through an endpoint or action you own. A refund the platform executes inside itself with no call-out is not gated, and we say so.
Does ZIFFER hold my processor or helpdesk credentials?
No. Your endpoint calls the processor with your key, after it verified the receipt.
What does ZIFFER see?
The proposal, the policy epoch, the count and the attestations. Not the conversation.
The agent answers the customer. It does not empty the account.
Bring the support agent you run and the endpoint it calls. Leave with the rule signed.
The agent answers the customer. It does not empty the account.
Bring the support agent you run and the endpoint it calls. Leave with the rule signed.