A customer-facing RAG assistant, answering questions using product documentation, knowledge base articles, or customer-specific records, sits directly reachable by adversaries in a way an internal tool never is. Assume every person interacting with it is capable of deliberately probing for weaknesses, and the priority ordering shifts compared to an internal deployment: per-customer data isolation and defense against deliberate manipulation jump to the top of the list.
Per-customer retrieval isolation is non-negotiable
If the assistant retrieves from customer-specific records, order history, account details, support tickets, isolation between customers needs to be structurally enforced, not riding on an application-level filter a bug or a manipulated request could bypass. Same principle covered for multi-tenant RAG systems generally, just with far more urgency, because a customer-facing assistant sits directly exposed to the very customers whose isolation from each other it's responsible for maintaining.
Public documentation is a poisoning target, not a safe default
Product documentation and public knowledge base articles feel like low-risk retrieval sources because they're already public, but if those sources allow external or lightly reviewed contributions, a community forum, a public wiki, user-submitted content, they're exactly the kind of writable source document poisoning techniques go after. Treat public-facing content sources with the same ingestion review discipline as any other retrieval source. Public visibility never implied safety from manipulation in the first place.
Every message is a potential injection attempt
Because the assistant is reachable by anyone, treat every incoming message as potentially adversarial, no matter how ordinary it reads, in line with the broader rule that public exposure means you can't safely assume good faith about any specific interaction. This affects how aggressively you scope any tool access the assistant has and how independently any resulting action gets authorized, since a customer-facing context hands attackers essentially unlimited attempts to find a manipulation technique that works.
Rate limiting and abuse prevention matter more here
A customer-facing assistant is also a target for volume-based abuse: automated scripts probing for successful injection techniques at scale, or just trying to exhaust resources through sheer query volume. Rate limiting per identity or session, and monitoring for volume patterns that don't match genuine customer usage, protects against this in a way that matters far less for an internal tool with a naturally bounded, identifiable user population.
Consider what an unauthenticated or lightly authenticated user can trigger
Some customer-facing assistants run with minimal authentication, a session cookie without a full login, for anonymous pre-purchase questions, say. Any retrieval or tool access available to these lightly authenticated sessions needs especially careful scoping, since the requesting "identity" here offers little real assurance about who's actually making the request, and an attacker can spin up plenty of these sessions cheaply to probe the system at scale.
Response content deserves review for what it might reveal externally
Because responses from a customer-facing assistant are visible to external parties, review sample outputs specifically for content that might reveal internal information never meant for external eyes, internal system names, unreleased feature references, details about internal processes that a knowledge source included without anyone anticipating it would eventually surface through a customer-facing retrieval system.
Incident response needs to account for external visibility
If something does go wrong, an incident touching a customer-facing assistant plays out differently than an internal one: affected customers might notice and start talking about it publicly before an internal investigation has even gotten started. Prepare for that with a communication plan sitting alongside the technical incident response plan, because in a customer-facing context, the speed and accuracy of external communication matters just as much as the speed of the technical fix.
Where TELEON fits
TELEON's policy enforcement, applied through the gateway or supported middleware, can apply strict, structural limits to any tool access a customer-facing assistant has, and its audit trail supports rapid investigation when speed matters most, given the external visibility risk described above.
Per-customer retrieval isolation, public-source content review, and authentication-level scoping for lightly authenticated sessions remain application and data architecture decisions specific to the assistant's integration.
A short checklist
- Enforce per-customer retrieval isolation structurally, not through an
application-level filter alone.
- Apply the same ingestion review discipline to public-facing content
sources as to any other retrieval source.
- Treat every incoming message as a potential injection attempt.
- Apply rate limiting and volume anomaly monitoring specific to external
exposure.
- Scope retrieval and tool access carefully for lightly authenticated
sessions.
- Review response content for internal information that should not
surface externally.
- Prepare a communication plan alongside a technical incident response
plan.
Customer-facing RAG assistants face direct, sustained adversarial attention in a way internal tools generally do not, which is why per-customer isolation and defense against deliberate manipulation need to be treated as first priorities rather than secondary concerns layered on afterward.