Customer Service AI Agent Security Guide

A customer service AI agent is the one AI system that anyone on the internet can talk to, and many are now allowed to issue refunds, change orders and update account details. That combination, anonymous untrusted input plus real actions on customer records, makes support agents built on platforms such as Zendesk AI agents, Intercom Fin and Sierra a fraud and account takeover surface, not just a content quality problem. This guide covers how to authenticate the customer outside the model, how to scope the agent's actions and the API credentials behind them, how to govern admin access, what to log, and a hardening baseline. It is vendor-neutral and uses documented platform features as examples. For phone-based agents and synthetic voice fraud, see the Voice AI Agent Security and Fraud Guide; this page focuses on chat, messaging and email agents.

Key takeaways

The model must never decide who the customer is. Identity comes from a signed token issued by your back end (for example a messenger JWT), and account ownership checks run in deterministic code the agent cannot override.
Every action needs a ceiling. Refund amounts, order changes and contact detail updates need limits, velocity checks and human approval above a threshold, enforced in the API the agent calls.
Changing an email or phone number is a credential change. The Meta AI support assistant case showed an AI agent sending account recovery codes to an attacker-supplied address for 20,225 people.
Integration credentials are NHIs with your customer data behind them. Use OAuth over legacy API tokens, scope them per action, and plan for the vendor being breached, as in the Salesloft Drift incident.
You own what the agent says. A tribunal held Air Canada liable for its chatbot's wrong bereavement fare answer. Ground answers in approved policy and keep transcripts.

How identity and access work in customer service AI agents

Three identities are involved in every conversation, and confusing them causes most of the serious failures.

Identity	Who or what it is	How it should be established	Common failure
The customer	The person chatting, anonymous until proven otherwise	Signed token from your logged-in session (messenger or widget JWT), or step-up through an existing verified factor	Agent accepts a name, email or order number typed in chat as proof of identity
The AI agent	The platform's agent runtime acting for the business	Its own service identity with scoped OAuth access to each back-end system	One broad admin API token shared by every action
Human support staff	Agents who receive handoffs and approve exceptions	SSO with MFA, role-based permissions in the help desk	Handoff staff trusting that the AI already verified the customer

Authenticating the customer

Intercom: Messenger security uses a JWT generated by your server from the user's user_id, an optional payload and the Messenger API secret key. Intercom warns that turning it off leaves workspace data open to unauthorised access or cross-user impersonation, and that it must be applied on every installation, including iOS and Android. HMAC identity verification remains only for backward compatibility; migrate to JWT. Keys are rotated under Workspace, Security, Messenger.
Zendesk: messaging end-user authentication uses a JWT signed with a key created in Admin Center under End user authentication. Tokens use HS256, must carry scope set to user and an external_id, and should have a short exp. Set email_verified to true only when you are certain the user owns the address. In AI agent dialogue flows, the Get User action returns whether the user is authenticated, the externalId and the verified authenticatedEmail, separately from any unverified email collected in chat.
Branch on the verified flag, not the conversation: design flows so that any account-specific action checks the platform's authenticated flag and verified identifiers. An email address the customer types is a claim, not an identity.
Sign out with your app: Zendesk advises signing the widget out when the user signs out and returning 401 or 403 from your JWT endpoint when no user is signed in. Shared devices otherwise carry the previous customer's session.

See the JWT Security Guide for key handling, and the Account Recovery and Help Desk Security Guide for recovery flows.

Admin roles and privileged access

The people who configure the agent are privileged even if they never touch customer data directly. They decide which knowledge the agent uses, which actions and procedures it can run, what guidance it follows and when it hands off.

Separate content editors from action builders: editing help articles changes what the agent says; building or connecting actions changes what it can do. Give action configuration and API connection rights to a small engineering-owned group.
Treat agent instructions as production code: guidance, procedures and system prompts should go through change review with a named approver and a test run before publishing.
Protect identity settings: the ability to disable messenger security, change JWT signing keys or edit end-user authentication settings is a route to cross-customer impersonation. Restrict it to administrators with phishing-resistant MFA and alert on changes.
Help desk SSO: require SSO and MFA for every staff account in the help desk and agent builder; local passwords on support platforms are a frequent entry point.
Insider risk applies to humans in the loop: support staff approving refunds or account changes are themselves a target, as the Coinbase Insider Breach 2025 shows. Approval workflows need segregation of duties and audit, not just a human click.

Integrations, API tokens and service accounts

Actions are where an AI agent becomes dangerous. Each action is an API call to an order system, payments provider, CRM or identity platform, made with a credential the agent platform holds.

Action	Risk if abused	Required control (enforced in the API, not the prompt)
Order status, tracking	Data disclosure to the wrong person	Authenticated customer only; return data only for orders bound to the verified `external_id`
Refund or credit	Direct financial loss, refund fraud at scale	Per-transaction and per-customer caps, velocity limits, eligibility rules in code, human approval above threshold
Cancel or change order, address change	Goods diverted, service disruption	Authenticated customer, confirmation to existing verified contact, cooling-off for address changes before dispatch
Update email or phone	Account takeover through recovery	Treat as credential change: proof from an existing verified factor, notification to the old contact, no agent-only path
Password reset or MFA reset	Account takeover	Never let the AI agent perform it; route to the standard self-service recovery flow
Look up other customers, bulk export	Mass data leakage	Not exposed to the agent at all

The Meta AI support assistant could link a new email address to an Instagram account on request without checking it against the account, and sent reset codes to that address. Meta's filing with the Maine Attorney General lists 20,225 affected people; accounts with two-factor authentication were not taken over. No prompt injection was needed. See the Meta AI Instagram Account Takeover 2026 analysis.

Credentials behind the actions

Prefer OAuth to legacy tokens: Zendesk recommends OAuth access tokens and describes API tokens as deprecated, noting that an API token works like a password and can be used to impersonate any user in the account, including admins. Migrate, delete unused tokens, and remember the account limit of 256 tokens is not a reason to keep old ones.
One credential per back-end system and purpose: a refund action should not share a token with a CRM lookup. Scope each to the minimum endpoints.
Put business rules behind your own API: instead of giving the agent platform a payments provider key, expose a narrow internal endpoint (for example "issue refund up to the cap for this verified customer and order") that enforces the rules.
Plan for vendor compromise: in the Salesloft Drift breach, attackers used OAuth tokens held by a chatbot integration to export data from Salesforce tenants at more than 700 potentially affected organisations, according to Google Threat Intelligence Group. Know which tokens your agent vendor holds and how to revoke them in minutes. See the Salesloft Drift Breach 2025 analysis and the SaaS and OAuth App Governance Guide.
Keep secrets out of tickets: agents read ticket history; customers and staff paste credentials into tickets. Redact them on ingest so the agent cannot repeat them and an attacker cannot mine them.

Logging and detection

Customer-facing agents need two kinds of monitoring: security monitoring of actions and quality monitoring of what the agent says.

Signal	Source	What it catches
Actions by authenticated status	Agent platform action logs, back-end API logs	Account-specific actions attempted by unauthenticated sessions
Contact detail changes via the agent	Identity platform and CRM audit logs	Recovery-path takeover attempts, the Meta pattern
Refund volume and value per customer, per hour	Payments and order system	Refund fraud, scripted abuse
Injection and manipulation attempts	Conversation transcripts, guardrail decisions	Customers trying to override instructions or extract the system prompt
Answers contradicting policy	Sampled transcript review, automated evaluation	Misinformation that creates liability
Integration token use	SaaS and CRM API logs	Bulk reads, access from unexpected IP ranges

Keep full transcripts with the authentication state and every action call and result, under a retention period your privacy team approves. In the Air Canada case, the British Columbia Civil Resolution Tribunal found the airline liable for negligent misrepresentation after its chatbot told a customer he could claim a bereavement fare retroactively, and rejected the argument that the chatbot was responsible for its own statements. Transcripts are your evidence either way. See the Air Canada Chatbot Ruling 2024 analysis.

Metrics

Authentication coverage: percentage of account-specific actions performed for sessions with a verified identity token. Target 100%.
Refund exception rate: refunds above cap or outside policy that reached human approval, and the share approved.
Contact-change takeovers: confirmed account takeovers following an agent-initiated contact detail change. Target zero.
Injection resistance: pass rate on a standing adversarial test suite, rerun after every guidance or model change.
Policy accuracy: percentage of sampled answers consistent with approved policy sources.
Token hygiene: number of legacy API tokens and integration credentials older than your rotation period.

Hardening baseline

Map every action the agent can take, the system it calls, the credential used and the maximum damage per call.
Turn on customer authentication (messenger or widget JWT) on every channel and make account-specific actions conditional on the verified flag.
Move rules into code: refund caps, eligibility, velocity and ownership checks live in the back-end API, not in instructions. The OWASP Top 10 for LLM Applications 2025 lists excessive functionality, excessive permissions and excessive autonomy as the roots of LLM06 Excessive Agency; this step addresses all three.
Remove credential-changing actions from the agent; route password, MFA and contact changes to the standard recovery flow with step-up.
Replace legacy tokens with scoped OAuth credentials, one per action group, and record owners and rotation dates. See the NHI Ownership Guide.
Ground answers in approved, versioned policy content and restrict the agent from making commitments (prices, compensation, legal statements) outside that content.
Test before launch: run injection, social engineering and wrong-customer scenarios, including "please send the code to my new email". See the AI Agent Security Testing Checklist.
Pilot read-only first: launch with information and order status, add low-value refunds with caps, then raise limits based on measured fraud rates.
Keep a kill switch: a documented way to disable actions (or hand all conversations to humans) within minutes, tested quarterly. In Zendesk, once a conversation is handed off the AI agent stops responding to it, which makes handoff a safe fallback path.

Small vs large organisations: a small business using a hosted agent should keep it to answers and order status with authentication, and leave refunds to staff. A large retailer or bank running money-moving actions needs the full baseline, fraud team ownership of action limits, and integration of agent events into existing fraud models.

Common misconfigurations

Messenger security disabled or partial: web secured but mobile SDKs not, so customers can be impersonated through the unsecured channel.
Typed identifiers treated as proof: order number plus email as the only check lets anyone with a receipt act on an account.
Limits written only in instructions: "never refund more than 50" in guidance is a suggestion a manipulative customer can talk around. The Chevrolet Dealer Chatbot 2023 case is the familiar example of a bot agreeing to terms nobody intended.
One admin token for all actions: a single compromise or prompt-induced misuse reaches everything that token can do.
Agent can change contact details: the shortest path to account takeover, as the Meta case showed.
No transcript retention: disputes and fraud investigations cannot be resolved without the conversation and action log.

Framework mapping

Risk	Reference
Customers manipulating the agent directly	OWASP LLM01 Prompt Injection; MITRE ATLAS AML.T0051.000 Direct
Agent performing unauthorised or excessive actions	OWASP LLM06 Excessive Agency; ATLAS AML.T0053 AI Agent Tool Invocation; NIST SP 800-53 AC-6 Least Privilege
Disclosure of other customers' data	OWASP LLM02 Sensitive Information Disclosure; NIST SP 800-53 SI-15 Information Output Filtering
Wrong answers creating liability	OWASP LLM09 Misinformation
Customer authentication	NIST SP 800-53 IA-8 Identification and Authentication (Non-organizational Users); NIST CSF 2.0 PR.AA-03
Integration credentials	NIST SP 800-53 IA-5 Authenticator Management; NIST CSF 2.0 PR.AA-05
Conversation and action logging	NIST SP 800-53 AU-2 Event Logging; NIST CSF 2.0 DE.CM-09

See the OWASP LLM Top 10 LLM06 Excessive Agency Guide and the OWASP LLM Top 10 LLM01 Prompt Injection Guide.

Practitioner checklist

Inventory every agent action, the back-end system, the credential and the maximum impact per call.
Enable JWT-based customer authentication on all web and mobile channels and gate account actions on the verified flag.
Enforce refund caps, velocity limits and ownership checks in back-end APIs.
Remove password, MFA and contact detail changes from the agent's capabilities.
Replace legacy API tokens with scoped OAuth credentials with named owners.
Restrict agent configuration, action building and identity settings to a small group with phishing-resistant MFA.
Retain transcripts with authentication state and action calls for an approved period.
Run adversarial tests before launch and after every change to guidance, actions or model.
Document and test a kill switch that disables actions or hands all conversations to humans.

Customer Service AI Agents Security: customer authentication, action limits and integration credentials