Security and CSP

Allowed origins

Tiketo registers exact production/staging origins and agreed localhost patterns for each client ID. The browser sends its Origin when requesting config. A disallowed origin receives 403; configuration responses never use wildcard CORS. Tiketo can enable an exact localhost or 127.0.0.1 origin for your staging ID on request; it is not automatic.

The client ID is intentionally public and does not authenticate a user. Keep authorization for sensitive host actions in your application/backend.

Content Security Policy

The loader, widget JavaScript, widget stylesheet, and widget fonts come from the selected Tiketo embed origin. Conversations use the Voiceflow runtime configured by the loader. For production, merge these values into your existing policy:

Content-Security-Policy:
  script-src 'self' https://chatbot.tiketo.cloud;
  style-src 'self' 'unsafe-inline' https://chatbot.tiketo.cloud;
  font-src 'self' https://chatbot.tiketo.cloud;
  connect-src 'self' https://chatbot.tiketo.cloud https://general-runtime.voiceflow.com;
  img-src 'self' data: https:;

Use https://staging.chatbot.tiketo.cloud while testing staging. The vendored widget derives voiceflow.css from its self-hosted voiceflow.js; it does not load a Voiceflow CDN script or stylesheet. style-src 'unsafe-inline' is needed because the widget applies runtime styles inside its shadow DOM. img-src must also include any HTTPS image hosts explicitly configured for your agent/components if your policy does not already allow https:.

With a nonce-based policy, nonce your inline queue snippet, but retain the selected Tiketo origin in script-src: the loader creates the self-hosted widget <script> dynamically and does not copy your nonce. The loader does not currently publish Subresource Integrity metadata or require crossorigin; pin an immutable version and rely on HTTPS plus your CSP instead of adding an SRI attribute that cannot cover the loader’s nested assets.

If voice mode is enabled for your chatbot, ask Tiketo for its configured voice socket origin before tightening connect-src; the standard text integration shown here uses https://general-runtime.voiceflow.com.

Treat data as untrusted

The embed validates action inputs/outputs and component payloads/replies against versioned schemas, but host code still must:

• use textContent or framework escaping, never interpolate payload data into innerHTML;
• authorize sensitive operations and validate again at its trust boundary;
• keep context free of secrets and PII;
• use only the allowed image/link forms and consider a narrower site CSP;
• make state-changing handlers idempotent.

MCP credentials and transcripts

The optional MCP integration sends host-supplied authentication headers directly from the browser to the client’s configured MCP endpoint. Header providers run for each request; their values are not persisted, logged, included in action results, or sent to Tiketo’s Worker or Voiceflow. The MCP endpoint remains responsible for authenticating and authorizing the logged-in user.

MCP tool arguments and results are agent data, not credentials. They are processed by the agent and can appear in conversation transcripts. Enable only the tools and data fields that are appropriate for that processing, and keep the allowlist minimal. Write tools require an in-chat user confirmation before the first network request.

Tool results can contain untrusted third-party instructions. They cannot expand the configured tool allowlist, and result text alone cannot execute a write: every write tool call still requires an explicit user confirmation in the UI. MCP requests carry opaque conversation and per-call correlation identifiers so the MCP server can correlate its audit log with the relevant transcript without copying host credentials into logs.

For retention, region, and subprocessor details in the data path, contact Tiketo for the applicable data and privacy documentation.