Delegated authorization for AI agents decides what your support agent can read in Zendesk, change in Shopify and refund through Stripe — and what ends that power. Microsoft made it doctrine on 19 October 2026: every agent gets its own identity and starts with no authority.
TL;DR: An AI agent's risk lives in its grants, not its prompts; machine identities already outnumber humans 109:1 according to Palo Alto Networks, so give support agents the narrowest scope per action and a named way for each grant to die.
Methodology & sources
- Scopes from Zendesk, Shopify and Stripe developer documentation; incidents from BleepingComputer, The Record and Invariant Labs.
- Aissist's own grants come from its public setup documentation.
- Statistics from Palo Alto Networks (2026 Identity Security Landscape) and SailPoint/Dimensional Research (353 respondents, May 2025).
- All sources verified November 2026. Disclosure: this is Aissist's blog; Aissist sells AI agents that act inside helpdesks and connected systems.

What is delegated authorization for an AI agent?
Delegated authorization is an owner granting an AI agent a limited, revocable subset of their access so it can act in named systems.
The important word is subset. The agent should never hold everything the admin who installed it holds. It holds a slice, sized to the job, with an expiry and an off switch. That slice is the agent's authorization surface: the total set of things it could do if it were fooled, hijacked or simply wrong.
This is also why AI agent identity matters. If the agent acts under a person's login, every refund it issues looks like that person issued it, and every audit trail lies a little.
"Every agent should have a first-class identity distinct from the person using or sponsoring it." — Nadim Abdo, CVP, Identity and Network Access, Microsoft
Palo Alto Networks' 2026 Identity Security Landscape reports that machine identities, including AI agents, now outnumber human identities 109:1. SailPoint's survey found 96% of tech professionals see AI agents as a growing security risk, while 98% of organizations plan to expand them.
A non-human identity in customer service is unusually exposed, because support systems hold what attackers want: customer records, order history and, too often, secrets pasted into tickets.
Which OAuth scopes does a customer service AI agent actually need?
A support agent needs a handful of narrow scopes per action class, and the riskiest one — raw payment data — it should not hold at all.
| Action class | System | Scope required | Who authorises | What revokes it |
|---|---|---|---|---|
| Read ticket | Zendesk | tickets:read | Zendesk admin, at OAuth consent | Refresh-token expiry (default 30 days) or deleting the OAuth client |
| Write ticket (reply, tag, note) | Zendesk | tickets:write | Zendesk admin, at OAuth consent | Same as above |
| Read customer record | Shopify | read_customers, read_orders (last 60 days by default) | Store owner or staff allowed to install apps | Uninstalling the app |
| Issue refund | Shopify / Stripe | write_orders / restricted key with Refunds: Write | Finance owner; a per-refund cap above which a human approves | Removing the permission or rolling the key |
| Cancel order | Shopify | write_orders | Store owner | Uninstalling the app |
| Change subscription | Stripe | Restricted key with Subscriptions: Write | Billing owner | Rolling or expiring the key |
| Access payment data | Stripe | Payment Methods: None | Nobody, by default | Never granted |
Three details in that table do most of the work.
First, Zendesk only became precise recently. Its granular OAuth scopes, announced 6 August 2026, let an admin cap a client at tickets:read and tickets:write instead of global read write. Requests outside the allowed list fail with invalid_scope.
Second, some scopes are coarser than the action. Shopify's refundCreate and orderCancel both sit behind order-write access: an agent allowed to refund is also allowed to cancel. The cap has to live in policy code, because the platform won't draw that line for you.
Third, Stripe is the most granular. Stripe's restricted keys set None, Read or Write per resource, default to None, and are what Stripe recommends for any key handed to an AI agent.
What are the four ways delegated authorization fails?
Delegated authorization fails in four recognisable ways, and each has already happened in public.
-
The confused deputy. A trusted agent is tricked into using its legitimate access for someone else. In May 2025, Invariant Labs showed a malicious public GitHub issue steering an agent into copying private-repository data into a public pull request. Nothing was hacked; the agent simply obeyed the wrong text.
"LLMs are unable to reliably distinguish the importance of instructions based on where they came from." — Simon Willison, developer and writer, The lethal trifecta
-
The over-broad token. Between 8 and 18 August 2025, attackers used stolen Drift OAuth and refresh tokens to query customers' Salesforce instances, per BleepingComputer's account of Salesloft's and Google's findings. The target was support cases, mined for AWS keys, passwords and Snowflake tokens. A chat integration's token became a credential harvester.
-
The orphaned credential. In October 2024, an attacker used the Internet Archive's unrotated tokens to answer its Zendesk tickets, The Record reported; the source-code breach behind it traced to a GitLab token exposed for almost two years. Chris Freeland, the Archive's director of library services, said the attacker sent emails to patrons "by exploiting a 3rd party helpdesk system."
-
The agent acting after the human's access ended. No public breach has been pinned on this one yet, which is not the same as it not happening. The pattern: a support lead connects the agent with a personal OAuth grant, leaves the company, and their account is disabled — but the refresh token keeps minting access. Fix it structurally: grant to a service identity owned by a role, not a person.

Why did least privilege for AI agents become urgent in October 2026?
Least privilege became urgent because the doctrine and the cautionary tale landed in the same week.
The doctrine came first. Microsoft's 19 October post argues an agent should begin with no authority and receive only what the approved task needs, for as long as it lasts. Risk is scored continuously rather than once at onboarding, and enforcement is graduated: keep reads, block writes, shorten or revoke access, and let guardian agents contain the rest. That is a scope table with a pulse.
The cautionary tale arrived two days earlier. OpenCode disclosed on 17 October that attackers had taken provider API keys stored by 1.4% of its Console users; some reported unauthorized charges of more than $1,700 overnight. The lesson for CX buyers is simple: one central store of other people's credentials is one breach away from being everybody's problem.
The tooling followed. On 20 October, Asymptote Labs raised $5.5M to build on Beacon, its open-source logger for agent prompts, commands and file edits. The market is pricing in a simple assumption: you will need to prove what your agent did.
None of this is specific to coding agents. A support agent with refund rights is a coding agent with a wallet.
How does an overlay AI agent shrink the authorization surface?
An agent that runs on top of your existing helpdesk inherits an access model your team already reviewed, instead of asking for a new one.
A rip-and-replace platform becomes the system of record. It needs your customer data copied in, its own user roles, its own audit logs and its own review. An overlay agent asks for one consent, inside a helpdesk whose admin roles, audit log and offboarding process already exist. That surface is smaller, and you can check it.
We'll declare the bias plainly, then show our grants, because a least-privilege argument that hides its own scopes is marketing. According to Aissist's Zendesk setup documentation, the connection:
- is approved once by a Zendesk admin through OAuth sign-in, with no key copied;
- reads the tickets and chats routed to it, and writes replies, tags and an internal summary note on handover;
- moves tickets to your escalation group, or only unassigns itself if none is set;
- creates one webhook and four triggers at setup. In Zendesk's model that needs
triggers:writeandwebhooks:write— configuration-level grants your admin should scrutinise hardest.
Refunds, cancellations and subscription changes happen only through actions you add, using credentials you provision. Aissist's reliability guide enforces refund limits in code and escalates anything outside them. Read it against our AI agent security review and judge.
What should you ask your identity team before granting an AI agent access?
Ask six questions, and get the answers in writing before the consent screen.
If any answer is "we'll find out later," don't grant write scopes yet, because later is when the audit asks.
- Whose identity does the agent use? A dedicated service identity, never a named employee.
- Which exact scopes, per system? A list like the table above, not "admin."
- Where does the cap live? If the platform scope is coarse (Shopify order-write), which code enforces the refund limit?
- When does each grant expire? Refresh-token lifetime, key rotation date, and who owns renewal.
- What happens at offboarding? Which grants are tied to a person, and who revokes them.
- Can you replay what the agent did? Per-action logs that separate agent actions from human ones.
For the wider vendor review, use the 20-question AI agent security review; for injection defences, see prompt injection in a customer-support AI agent and AI agent guardrails.
The safest AI agent is the one with the fewest grants
Prompts can be argued with; scopes cannot. Every failure above was an access problem before it was an AI problem: a token too broad, a credential never rotated, an agent that trusted the wrong text while holding the right keys. Write the scope table first, attach an expiry and an owner to every row, and prefer agents that borrow your existing access model over agents that need a new one. Then check the vendor's own grants — including ours, on our security page. The governance control gap closes one row at a time.
Check the grants before you check the demo. Run any vendor, including us, through the 20-question review. Open the AI agent security review →
Frequently asked questions
What OAuth scopes should an AI agent have in Zendesk?
For most support work, tickets:read and tickets:write, using Zendesk's granular scopes announced in August 2026. Avoid global read write unless a setup step genuinely needs it, and restrict the OAuth client's allowed scopes in Admin Center.
What is the confused deputy problem for AI agents?
It is when an agent with legitimate access is manipulated by untrusted content into using that access for an attacker. Invariant Labs demonstrated it in May 2025 with a malicious GitHub issue that made an agent leak private-repository data.
Should an AI agent use its own identity or a user's?
Its own. Microsoft's October 2026 guidance says every agent needs an identity distinct from its sponsor, so audits separate what a person did from what an agent did, and offboarding a person doesn't break or orphan the agent.
Can an AI agent issue refunds safely?
Yes, if the refund scope is paired with a per-refund cap enforced in code and human approval above it. Stripe's restricted keys can limit an agent to refunds only; Shopify's refund access also permits cancellations, so the limit must live in policy.
How do you revoke an AI agent's access?
Delete or restrict the OAuth client, uninstall the app, or roll the API key. Zendesk refresh tokens expire after 30 days by default (configurable from 7 to 90), which caps how long a forgotten grant survives.




