Chatbot Permissions: What a Support Bot Should Never Be Allowed to Do

Connecting an AI support agent to Stripe, Shopify or a helpdesk moves the worst case from a wrong answer to a wrong change: a plan cancelled for the wrong person, a ticket filed three times, a refund nobody approved. Which of those can happen is decided by the permissions you set, not by how clever the model is.

The guide below is for founders, support leads and developers deciding which actions to switch on. It sets out a four-tier permission model, maps common support actions to it, and ends with a ten-question checklist. For what action-taking agents can do in general, see agentic AI in customer service; this post is about what to allow.

Every source was read on 19 October 2026: OWASP's entry on excessive agency, NIST's AI Risk Management Framework and Stripe's documentation. The examples use PepoChat, the AI support agent we build, as its documentation and source code stood in October 2026, including where a control is only an instruction to the model.

Why do permissions matter more than the model?

Permissions set the worst case; the model only sets how often you reach it. A model that gets almost every request right still acts on the one it gets wrong, and a manipulated conversation can produce that one on purpose.

A permission, for an AI agent, is three settings you control: which tools it may call, what the credential behind each tool may do, and which checks must pass before a call goes out. None of them depends on the model behaving well.

The OWASP Top 10 for LLM Applications calls the failure excessive agency. OWASP's LLM06 entry, from the 2025 edition still current in October 2026, defines it as the weakness that lets damaging actions happen in response to unexpected, ambiguous or manipulated model output. Its three causes each have a support-desk version: excessive functionality is a cancel action you never needed, excessive permissions is a full secret key where a read-only key would do, and excessive autonomy is a write nobody confirms.

Permissions also cover words. A chatbot that promises a refund can commit money without touching a payment system: in Moffatt v. Air Canada (February 2024), a Canadian tribunal ordered the airline to pay damages after its chatbot misdescribed how to claim a bereavement refund, as covered in AI chatbot security risks. The money tier therefore covers promises as well as payments.

What are the four permission tiers for an AI support agent?

The four tiers sort every action by what it touches and whether it can be undone: reading public information, reading personal data, reversible writes, and irreversible writes and money. Each step up adds a check, and the top tier takes the bot out of the decision.

Tier 1 is what your website already publishes. The control is grounding: the agent answers from your knowledge base and hands off when it finds nothing.

Tier 2 begins when an action returns something about one customer. Its failure is quiet: one customer's order or plan read out to someone else, with nothing in the logs that looks wrong.

Tier 3 covers changes a person can undo in a minute: a merged ticket, a removed subscriber, a period-end cancellation reversed before the period ends. Duplicates are its common failure, covered in the retries section below.

Tier 4 is where the bot stops acting and starts preparing. Refunds, payments, credits, immediate cancellations and deletions move money or cannot be reversed, so a named person decides, using the details the agent collected.

A human checkpoint is a point where a person, not the model, decides whether an action happens. NIST's AI Risk Management Framework asks organisations to define, assess and document their processes for human oversight (subcategory MAP 3.5), and the NIST AI RMF Playbook suggests starting by identifying the system features and capabilities that require it. For a support bot, the tier table is that document.

Which actions should a support chatbot be allowed to take?

Allow tier 1 freely, tier 2 only behind verification and trimmed fields, most of tier 3 with a confirmation, and nothing in tier 4. The table maps common support actions to the tiers; the safeguard column is the minimum, not the whole design.

A Zapier action has no tier of its own: it inherits the tier of whatever the Zap does. PepoChat's Zapier template even offers "refund request" as an example event label, which is safe while the Zap only records the request and unsafe the day someone extends it to pay the refund.

Newsletter sign-ups are reversible but not harmless, because anyone can type someone else's address. PepoChat's Mailchimp action subscribes people straight away, and the Mailchimp documentation shows how to switch it to pending, so Mailchimp emails a confirmation first and only the inbox's owner can complete the sign-up.

Plan changes look like tier 3 but create prorated charges or credits, which makes them money, and address changes become a fraud route once an order ships. The full subscription flow is in cancelling Stripe subscriptions safely.

Does a chatbot need to verify identity before it reads customer data?

Yes, for anything personal, unless the lookup needs an identifier a stranger cannot guess and returns only harmless fields. Verification decides who may ask; the field list decides what a wrong person could learn if verification is skipped or fooled.

A verified visitor is someone who proved control of an email address during the current session, usually by typing a six-digit code sent to it. PepoChat's visitor verification codes expire after 10 minutes and allow 5 attempts, and the methods and their trade-offs are compared in chatbot identity verification.

In PepoChat, verification is checked in code before the agent recalls someone's meeting history or a transcript is emailed, but integration lookups are not gated: a Stripe or WooCommerce lookup by email runs for any address typed into the chat, as the Stripe integration documentation says plainly. A "verify first" line in an action's "when to use" text makes the agent ask for the code, but PepoChat does not pass the verification result to actions, so nothing in the request checks that it was entered.

Three settings close most of that gap. Trim the response fields until an unverified answer is harmless: PepoChat's Shopify action reads only the order name, date, payment status and fulfilment status, as the Shopify order status walkthrough shows, and a custom action passes only the fields you list (an empty list passes the whole response). Prefer identifiers that are hard to guess. And when the lookup hits your own API, make it require two facts that must match, such as the order number and the order's email, and return nothing when they do not.

OWASP calls that third habit complete mediation: authorization enforced in the downstream system instead of left to the model. A manipulated conversation can change what the model asks for, but not what your API agrees to return.

Why can a chatbot action run twice, and which writes are safe?

An action can run twice because systems that cannot tell whether a call landed try it again. A write is safe under those conditions when repeating it changes nothing that matters.

At-least-once execution is a delivery rule that prefers repeating a step to losing it: when the system cannot tell whether a step finished, it runs the step again, so a write can occasionally happen twice. PepoChat's integrations documentation says its actions work this way and warns against wiring refunds or payments as actions. The usual cause of a repeat is a step that fails after the provider call already succeeded and is then retried. A model can also repeat a call when a visitor asks whether something went through.

An operation is idempotent when running it twice leaves the same result as running it once. Reads are idempotent, and so is setting a flag: PepoChat's Stripe cancel action sends cancel_at_period_end=true, and a second identical request changes nothing. Creating something is not, because a retried "create ticket" files a second ticket.

Payment APIs handle this with an idempotency key, a unique value sent with a write so the server can recognise a retry. Stripe's idempotent requests documentation says the API returns the saved result of the first request to any retry with the same key, errors if the parameters differ, may prune keys once they are at least 24 hours old, and accepts keys on every POST, while GET and DELETE are idempotent by definition.

If your own API accepts such keys, a PepoChat custom action can send one, because its headers take the same {{input}} placeholders as the URL and body. Build the key from an order number, since Stripe advises against personal identifiers such as email addresses. Without keys, design the endpoint so a repeated request finds and returns the first result.

A confirmation step handles the other failure, a misunderstood request: the agent restates the exact change, waits for a plain yes, and reports the result from the provider's response rather than from its own expectation. PepoChat writes this into the instructions of its account-changing actions: the Stripe cancel action may run only when the customer explicitly asks and confirms, and the Mailchimp action only after the visitor asks and confirms the address.

Of PepoChat's 22 prebuilt actions across 13 tools, 11 only read, 11 write, and none moves money.

Checked against PepoChat's action templates on 19 October 2026. Every write listed is tier 3, unless the Zap behind the Zapier action does more.

Should a chatbot be allowed to process refunds?

No. A support chatbot should take a refund request, not grant one: money is hard to take back, retries can repeat it, and refund decisions need judgement about policy and fairness that customers expect a person to make.

Stripe's documentation on refunds and cancellations shows how little room there is to recover. You can issue more than one refund against a charge, up to the original amount, so a doubled full refund fails, but a doubled partial refund goes through whenever the two together stay within the charge. Stripe's processing fees on the original payment are not returned, and only some card refunds can be cancelled, for a short period and only from the Dashboard.

Draft for approval replaces the refund action: the agent prepares everything a person needs to decide, and the person carries out the decision in the payment system, in four steps:

1. The agent collects the facts. Order number, amount, reason and the customer's email, without promising an outcome.
2. The agent files the request. A ticket through a Zendesk, Freshdesk or Zoho Desk action, or a human handoff to the team inbox, which emails your team the reason and the last three messages.
3. A person decides. They check the order against your policy and issue the refund in the payment tool; Stripe's Dashboard asks for a reason and requires a note when the reason is Other.
4. The customer hears back. The person replies by email, so the answer comes from someone accountable for it.

PepoChat ships no action that moves money, and its documentation says not to connect refunds or payments. Nothing in the product blocks a custom action from calling a refund endpoint, so make the rule hold in the credential: a Stripe restricted key without write access to refunds or charges gets an error back from Stripe whatever the bot is told, and Stripe recommends restricted keys for any key given to an AI agent.

Add a refusal to the agent's instructions too, such as "Never promise a refund, credit or discount", because a promise in chat commits you as well. The agent instructions documentation explains how PepoChat's "Never do this" field makes the agent decline.

The full decision table, with Stripe, Shopify and WooCommerce specifics, is in can an AI chatbot process refunds?.

Which guardrails are enforced in code, and which are only instructions?

A guardrail enforced in code holds whatever the model is told; a guardrail written as an instruction holds only while the model follows it. Put every limit that protects money or personal data in the first group, and treat the second group as helpful defaults.

Checked against PepoChat's documentation and source code on 19 October 2026.

Read the table from the bottom. The last three rows depend on the model following instructions or on your own setup, so the rows above them should carry the weight: fewer actions, shorter field lists and the narrowest key each provider offers. The custom actions documentation lists the limits on every field.

Who can change these settings is part of the permission model too. In PepoChat any workspace member can connect, edit and test integrations, and the Test button runs the real request, so testing the cancel action schedules a real cancellation. Keep seats to people you would trust with the keys, and test on test records.

How do you log and audit what an AI agent did?

Keep three records for every action: the conversation, the connected tool's own log of the call, and, for anything in tier 4, the name of the person who approved it.

OWASP lists logging, monitoring and rate limiting as controls that do not prevent excessive agency but limit the damage: logs show where unwanted actions happen, and rate limits cap how many can happen before someone notices. A useful record of an action answers five questions: who asked, whether they were verified, what the agent restated, what it sent and what came back.

PepoChat's team inbox and its CSV export hold the conversation, including the agent's confirmation and its plain-language report of the result, but not the raw request and response. The record of the call lives in the tool you connected: Stripe keeps request logs for each restricted key, and a helpdesk keeps the ticket's history. Name each key after the bot so its calls are easy to find.

An audit also needs an off switch. NIST's AI RMF core asks for mechanisms to supersede, disengage or deactivate an AI system whose outcomes are inconsistent with its intended use (subcategory MANAGE 2.4). In PepoChat that means each action's switch, plus escalation: actions run only while the agent is answering, so moving a conversation to escalated stops them.

Review on a rhythm that matches the tier: every week, read a sample of conversations about orders, billing and tickets, where tier 2 and tier 3 actions run; every month, remove actions nobody used; and check how each tier 4 ticket ended. PepoChat allows up to 20 actions per workspace; fewer is safer.

Ten questions to answer before you switch on a new action

Answer these in writing before a new action goes live; if one has no answer yet, the action is not ready.

1. Which tier is it? If it moves money or cannot be undone, build the draft-for-approval route instead.
2. Could a stranger supply the inputs? Anyone can type an email address or a sequential number, so have your own API require a second fact that must match, and keep the returned fields harmless.
3. Which response fields does the answer need? List them and nothing else; the rest should never reach the model.
4. What else can the credential do? Restrict it to this action's resources, read-only wherever the action only reads.
5. What happens if it runs twice? "Nothing" and "a duplicate someone merges" are acceptable; anything else needs an idempotency key or a person.
6. Is the trigger explicit? The "when to use" text names the request that triggers the action and requires a restated confirmation for any write.
7. Who can undo it, and how fast? Name the person and the steps before the first mistake.
8. Who hears about it? Decide whether a run, a failure or both create a ticket, an alert or a handoff.
9. Where is the record? Point to the transcript and the provider log that will answer "who did this?" six months from now.
10. When will you review it? Put a date in the calendar, and remove the action if nobody has used it by then.

What to do next

• Write your current and planned actions into the tier table, then switch on the read-only lookups first, each with a trimmed field list.
• For the first write action, follow how to let a chatbot create tickets in Zendesk, Freshdesk or Zoho Desk; the same ticket route carries refund requests to a person.
• Every feature, actions included, is on the free plan, so you can create a free PepoChat workspace and test each action on test records before a real customer reaches it.