Security & Policies

Dayside is scoped by design. It can only do what your website can do — nothing more.

Domain Scoping

Every site key is locked to a set of allowed domains. When the embed script initializes, it checks the current hostname against the key's domain list. If there's no match, Dayside refuses to boot and logs a warning.

Boot config

allowedDomains: ['yourdomain.com']
domainScopeMode: 'registrable_domain'

registrable_domain (default) — a plain entry such as example.com allows the apex host and its subdomains.

Specific hosts still matter — a plain entry such as app.example.com in registrable_domain allows that host and its subdomains, not sibling hosts like www.example.com.

Wildcards — prefix with *. to match subdomains only. *.example.com does not match the apex host example.com.

host_only — makes plain entries exact-host only. Use this when you need strict per-subdomain control. Sibling subdomains are blocked unless you explicitly allow them with a wildcard or another exact host rule.

Exact and URL-shaped entries — use =app.example.com for exact host matching, or URL-shaped values like https://app.example.com/path (normalized to host).

Navigation Behavior

Standard installs do not expose owner-selected navigation policies. Dayside opens outside-domain pages in a new tab with notice, keeps same-host work in the current tab unless a link explicitly asks for a new tab, and chooses the right tab automatically for allowed-host hops.

First-Party Execution

Unlike screenshot-based agents that run in a remote VM, Dayside executes directly in the user's browser tab. This means:

No user credentials leave the browser. Dayside acts as the user, within the user's existing authenticated session.
Dayside can only interact with DOM elements that are visible and accessible to the current user.
All actions are subject to the same CORS, CSP, and browser security policies as your own JavaScript.
No screenshots or page content are sent to external servers — only the semantic DOM structure.

Analytics Owner Access

Analytics runtime writes and owner analytics do not share the same trust path.

Site-tag analytics writes are authenticated by signed session claims, not by raw browser-supplied site IDs.
Workspace analytics reads and launch/settings writes require owner Firebase auth plus site ownership checks.
Webhook secrets and auth material are stored privately by owner + site and are not returned in public site config.

Agent Attribution Trust Tiers

Dayside distinguishes between who owns a site and which agent visited it.

ownerUid is the authenticated site owner using Dayside Workspace.

agentKey is the visiting AI caller or attributed agent identity used for memory, revisit analytics, and discussion history.

Trust tiers are verified_signed, signed_directory_only, self_reported, heuristic, and anonymous. HTTP Message Signatures can land in verified_signed. Signature-Agent directory or signature-envelope evidence without full signed verification can land in signed_directory_only. The stored agentKey still comes from explicit agent key fields first, then clientId, then Signature-Agent. Loose headers without directory/signature-envelope evidence remain heuristic.

External Tab Context

External tabs are tracked with virtual tab IDs, URL, and title. Dayside cannot directly control live DOM outside the embedded domain.

If Cloud sandboxes are enabled, Dayside can request best-effort cloud text context or action support for approved external tabs. Access is still subject to domain allow/deny rules and account credits.

Navigation-only external steps use open-only handling (tracked via POST /command with type='TAB_EVENT' + placeholder tabs). Context/action fetches are routed through /v2/rover/context/external with read_context or act intent.

When cloud fetch fails or is blocked by allow/deny policy, Dayside falls back to placeholder context and continues.

Content Security Policy (CSP)

No CSP header on your site? No action needed — Dayside works out of the box. This section only applies if your site sets a Content-Security-Policy header or meta tag.

Dayside uses a Shadow DOM (not an iframe) to render its UI, which means it runs in your page's security context. If you have a strict CSP, add the following directives (the script origin keeps its wire name, https://rover.rtrvr.ai, for protocol compatibility):

Directive	Value	Why
`script-src`	`https://rover.rtrvr.ai blob:`	SDK script, page action bundles, and Web Worker blob creation
`worker-src`	`blob: https://rover.rtrvr.ai`	Web Worker execution
`connect-src`	`https://agent.rtrvr.ai`	API calls
`style-src`	`'unsafe-inline'`	Shadow DOM inline styles
`font-src`	`https://rover.rtrvr.ai`	Self-hosted Manrope font
`media-src`	`https://www.rtrvr.ai`	Mascot media (optional — Dayside can use the default video, a custom image, or custom MP4/WebM; disable with `ui.mascot.disabled`; mascot sound stays unavailable unless the owner enables `ui.mascot.soundEnabled: true`, and `ui.muted` only controls the initial mute state after that)

Page action bundles are served from https://rover.rtrvr.ai, the same origin as embed.js. If Workspace shows a fallback bundle script tag, your CSP must still allow this script origin.

For environments with strict CSP that cannot allow external script domains, you can self-host the SDK and worker files on your own domain and set workerUrl in your boot config. See the configuration guide or contact support for strict self-hosting requirements.

CORS:You do NOT need to configure CORS on your server. CORS headers are set on Dayside's CDN side. Your website simply loads the files — no server-side changes needed.

Key Management

Site keys can be rotated, disabled, and domain-scoped from the Workspace without redeploying your site:

Replace — generates a new key with the same configuration. Old key is immediately invalidated.
Disable/Enable — toggle key access without deleting it.
Update domains — change the allowed domain list in real time.
TTL — keys can be set to auto-expire after 30, 90, 180, or 365 days.

Capability flags are enforced server-side for cloud APIs: roverEmbed for embed runtime requests and cloudAgent and cloudScrape for cloud MCP/direct APIs.

Site owners get siteId, publicKey, and optional siteKeyId from Workspace for installation. External AI callers using POST https://agent.rtrvr.ai/v1/a2w/runs or chatbot GET execution do not need those values. Public GET targets must still be HTTPS, outside local/private host ranges, inside the site scope, and allowed by aiAccess.

Site keys require an active subscription with available credits. Check your credit balance in the Workspace.

API Reference Configuration