Skip to main content
The public Chatbot boundary is enforced by several independent controls. A single toggle does not make an internal Assistant configuration safe for anonymous website traffic.

​
Public safety layers

A production widget combines:
  1. Exact allowed origins
  2. Origin-bound publishable key
  3. Published widget version
  4. Chatbot-approved knowledge/resources
  5. Widget/Collection targeting
  6. Visitor identity tier where required
  7. Bounded public-source inputs and outputs
  8. Explicit public-action policy for mutations
  9. Visitor confirmation for public actions
  10. Idempotency, rate limits, timeouts, and audit
  11. Handoff behavior for cases the bot should not complete
These controls fail closed when required configuration is absent or invalid.

​
Exact origins

Allowed origins are exact scheme + host + port values. Production traffic must come from configured HTTPS origins. A valid publishable key used from an unapproved website is not enough to start the widget normally. Channels & origins →

​
Publishable key is not a secret

The browser key is designed to be visible in page source. Its safety comes from scope, versioning, origin enforcement, and server-side policy, not from pretending JavaScript can hide a credential from the browser running it. Never replace it with an organization API token.

​
Public resource approval

Procedures, Guidelines, documents, Gallery assets, Connections, MCP Servers, Updates, and authored articles must pass the Chatbot public-review boundary before they can be used publicly. Shared Knowledge →

​
Visitor identity

Anonymous, email-verified, and host-signed sessions have different access levels. Typed customer data is not verified identity. Host-signed identity is required for public WRITE actions. Visitor identity →

​
Public SOURCE tools

Public SOURCE access is limited by the resource’s approved policy, including matching widget, identity requirement, bounded input bindings, and bounded outputs. Internal SOURCE connections stay internal if no valid public policy/approval exists.

​
Public ACTION tools

Public actions use a different policy from SOURCE retrieval. WRITE actions require:
  • host-signed identity;
  • explicit visitor confirmation;
  • bounded declared inputs;
  • idempotency;
  • rate limiting;
  • timeout;
  • HTTPS/public-network destination safety; and
  • mandatory audit.
Public connections & actions →

​
Chatbot Simulation

Open Chatbot → Conversations → Simulate to start a private Chatbot conversation. Choose:
  • Widget; and
  • Language.
The available language list is normalized against the selected widget and the currently published widget locale catalog. Simulation follows the selected widget’s configuration, approved knowledge, Collection scope, language, and public policies.

​
What a Simulation shows

The simulator shows:
  • visitor/Assistant messages;
  • generation status;
  • failure code when a generation fails; and
  • intercepted public actions.
The session can be restarted whenever you need a clean test conversation.

​
Public actions cannot execute in Simulation

Public ACTION tools are always intercepted in Chatbot Simulation.
The simulator records proposed public actions but exposes no confirmation endpoint, so state-changing actions cannot execute. This is different from a production widget, where a valid public action still has to pass identity, confirmation, idempotency, rate-limit, input, approval, and audit checks.

​
Preview versus Simulation

Widget Preview tests presentation only. It does not create a conversation or send a message to AI. Chatbot Simulation tests the private conversation/AI pipeline without allowing public ACTION execution. A real allowed-origin test is still needed to test browser origin/CSP, live publishable-key behavior, actual handoff delivery, and production identity integration. For each production widget, test:
  • normal FAQ answer;
  • missing knowledge;
  • deliberately low-confidence case;
  • visitor asks for human support;
  • configured-intent handoff;
  • outside-business-hours handoff;
  • anonymous request for account-specific data;
  • email-verified SOURCE lookup;
  • host-signed SOURCE lookup;
  • proposed WRITE action in Simulation;
  • visitor cancellation/decline of a real action confirmation;
  • failed public action;
  • unsupported/oversized attachment;
  • each enabled language; and
  • content that should remain private.
The easy happy-path answer proves the chat bubble can talk. The tests above prove the product knows when it should not.