Secure Your Assistant
Security is built from three layers that work together: the authentication mode, the allowed origins list, and — for API mode — the API key. How you combine them depends on who should be able to use the assistant.
Understanding What's Public
When an assistant is embedded on a website, the embed snippet — including the assistantId, the accessToken (API key), and the serviceURL — lives in the page's HTML source. Anyone who can view the page source can read these values. This is not a flaw; it's how client-side embeds work. Security doesn't come from hiding these values — it comes from what the server does when it receives them.
Security Scenarios
Public website — open access
Mode: None. Origins: your domains.
The assistant loads on any allowed origin without a key. This is the simplest setup and the right one for public help centers, product pages, and marketing sites where the content is already public. Restrict origins to your domains to prevent someone from embedding your assistant on an unrelated site.
Intranet or private site — soft-gated access
Mode: API. Origins: your internal domains. Key: generated.
The API key acts as a public identifier — it tells the server which assistant to load, but it's not a secret. Combined with restricted allowed origins, this prevents casual reuse: the assistant only loads on your domains, and only with the right key. Someone who copies the key still can't use the assistant from an unauthorized origin.
This is enough for internal tools, staging environments, and sites where the audience is controlled but formal authentication is overkill.
Authenticated application — identity-gated access
Mode: OIDC. Origins: your domains. Issuer + audience: your provider.
The embed passes a JWT from your identity provider (Firebase, Auth0, Azure AD, Okta, etc.) as the accessToken. Seekdown validates the token against the configured issuer and audience before allowing the assistant to respond. Only users who have signed in through your auth stack can use it.
This is the strongest protection and the right choice for logged-in dashboards, customer portals, and any scenario where usage should be tied to a user identity.
How the Layers Stack
| Layer | What it controls | Visible in page source? |
|---|---|---|
| Authentication mode | Whether a token is required and how it's validated. | The mode itself is a server-side setting — not exposed. |
| Allowed origins | Which domains can embed the assistant. | No — enforced server-side. |
| API key | Identifies the assistant in API mode. | Yes — it's in the embed snippet. |
| OIDC token | Proves the visitor's identity in OIDC mode. | The token is per-session, short-lived, and validated server-side. |
The API key identifies which assistant to load. The allowed origins control where it can load. The authentication mode controls who can use it. Together they form a practical security model for any scenario — from fully open to fully authenticated.