Secure Embeddable Widget

Dual-Key Design

A secure widget deployment separates:

• —A public key or identifier used in browser-side initialization
• —A server-protected secret hash used for validation and privileged operations

The public identifier is not treated as a secret. Sensitive authorization decisions remain server-side.

Domain Whitelisting

Each organization can approve the websites or subdomains allowed to initialize its widget. Requests from unapproved origins can be rejected.

Domain restrictions help prevent a copied script from being embedded on another website and consuming the customer’s AI quota or impersonating its support experience.

Tenant-Specific Configuration

• —Branding and approved colors
• —Feature entitlements
• —Knowledge and AI settings
• —Allowed domains
• —Authentication requirements
• —Voice and model configuration
• —Customer-facing source behavior

Zero-Dependency Architecture

Rumbe-Widget-V3 is compiled as a lightweight, framework-independent script. Avoiding a runtime dependency on React or another host framework reduces the risk of version conflicts with the customer’s website.

A zero-dependency bundle does not eliminate security review. Content security policy, script integrity, update processes, origin validation, and backend authorization remain important.

Authenticated Widget Sessions

With the applicable authenticated-widget capability, a host application can provide a verified user profile to Rumbe. The host should generate signed, short-lived assertions server-side. Sensitive identity data should never be trusted solely because it was supplied by browser JavaScript.

Protection of Attachments and Conversation Data

Widget uploads and conversations must remain associated with the active tenant and authenticated or anonymous session. File access URLs should be time-limited or authorization-protected, and unsupported file types should be rejected.

Voice Security

Real-time voice sessions use WebRTC or supported WebSocket connections to configured model providers. Microphone access requires explicit browser permission. Customers should disclose recording and processing practices and apply consent requirements appropriate to their jurisdiction.