Customer support assistants combine two properties that make their security needs more pressing than many other AI features: they are exposed to external users who are not always acting in good faith, and they often have real access to customer data and, increasingly, the ability to take account-level actions like issuing refunds or updating records. This combination means both the attack surface and the potential consequence are higher than for an internal-only tool.
Cross-customer isolation is the first priority
The most damaging and most common failure mode for support assistants is one customer's session surfacing another customer's data, whether through a retrieval system that ranks by relevance without checking ownership, a prompt injection that convinces the assistant to look up a different account, or a bug that fails to scope a query to the current session's customer identity. Every data access the assistant performs should be explicitly scoped to the authenticated current customer, checked independently of what the model requests, not assumed to be correct because the model was only asked about the current customer.
Treat every message as a potential injection attempt
Because support assistants are reachable by anyone who can open a chat widget or send an email to a support address, every incoming message should be treated as untrusted content that could contain an injection attempt, regardless of how ordinary it reads. This is not about being suspicious of legitimate customers; it is about making sure the assistant's authorization and tool access do not depend on trusting that every message is what it appears to be.
Scope account-action tools tightly
If the assistant can issue refunds, modify account details, or perform similar actions, each of these tools needs its own limits: a maximum refund amount without approval, restrictions on which account fields can be changed without additional verification, and an audit record of every action taken. These limits should be enforced independently of the model's own judgment about whether an action seems reasonable, since a manipulated or simply mistaken model decision should not be able to exceed them.
Handle escalation and human handoff securely
Most support assistants are designed to escalate certain cases to a human agent. This handoff point deserves attention: the context passed to the human agent should be sanitized to avoid carrying forward any injected instructions embedded in the conversation, and the escalation criteria themselves should not be solely determined by the model's own assessment without any independent check, since an attacker aware of the escalation logic might try to manipulate whether or how an escalation happens.
Watch for social engineering aimed at the assistant itself
Support assistants are a natural target for social engineering attempts that try to extract information about internal processes, other customers, or the assistant's own configuration, sometimes as reconnaissance for a later, more targeted attack. Monitor for patterns consistent with this kind of probing, repeated attempts to ask about internal policy details, requests to reveal system instructions, or unusual patterns of account lookups, and treat a cluster of these as a signal worth investigating even if no single message looks alarming on its own.
Consider volume and abuse potential
A support assistant reachable by anyone can also become a target for abuse unrelated to data exposure: automated requests designed to consume API budget, generate excessive support tickets, or probe the assistant's limits at scale. Rate limiting per identity, and monitoring for volume anomalies that suggest automated rather than genuine customer traffic, protects against this category of risk alongside the more targeted concerns above.
Test with realistic customer-facing scenarios
Testing should include scenarios specific to this context: attempts to access a different customer's order or account details, attempts to trigger a refund above the approved limit through conversational persuasion rather than a direct request, and injection attempts planted in content the assistant might process, such as a forwarded email or an attached document a customer includes in a support request.
Where TELEON fits
TELEON's policy enforcement at the tool-call boundary is directly applicable to scoping refund and account-action tools, applied through the gateway or supported middleware, with an audit trail that supports investigating unusual account-lookup patterns or repeated probing attempts.
Cross-customer isolation in the retrieval and data-access layer, and the design of the escalation and handoff process, remain application-level work that has to be built into the specific support integration.
A short checklist
- Scope every data access explicitly to the authenticated current
customer, checked independently of the model's request.
- Treat every incoming message as a potential injection attempt.
- Set hard limits on refund amounts and account changes, enforced outside
the model.
- Sanitize context passed to human agents during escalation.
- Monitor for social engineering patterns aimed at the assistant itself.
- Rate limit and monitor for automated abuse at scale.
Customer support assistants sit at the intersection of high exposure and real authority, which makes cross-customer isolation and tightly scoped account-action tools the two priorities that matter most before anything else.