Security & Policies
Rover is scoped by design. It can only do what your website can do — nothing more.
Domain Scoping
Every Rover 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, Rover refuses to boot and logs a warning.
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 Rover installs do not expose owner-selected navigation policies. Rover 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, Rover executes directly in the user's browser tab. This means:
- 1.No user credentials leave the browser. Rover acts as the user, within the user's existing authenticated session.
- 2.Rover can only interact with DOM elements that are visible and accessible to the current user.
- 3.All actions are subject to the same CORS, CSP, and browser security policies as your own JavaScript.
- 4.No screenshots or page content are sent to external servers — only the semantic DOM structure.
Agent Analytics Owner Access
Agent analytics runtime writes and owner analytics do not share the same trust path.
- 1.Site-tag Agent analytics writes are authenticated by signed Rover session claims, not by raw browser-supplied site IDs.
- 2.Agent analytics Workspace reads and launch/settings writes require owner Firebase auth plus site ownership checks.
- 3.Webhook secrets and auth material are stored privately by owner + site and are not returned in public site config.
Agent Attribution Trust Tiers
Rover distinguishes between who owns a site and which agent visited it.
ownerUid is the authenticated site owner using Rover 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. Rover cannot directly control live DOM outside the embedded domain.
If enabled, Rover can request best-effort cloud text context for external tabs usingtools.web.enableExternalWebContext. 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 withread_context or act intent.
When cloud fetch fails or is blocked by allow/deny policy, Rover falls back to placeholder context and continues.
Content Security Policy (CSP)
No CSP header on your site? No action needed — Rover works out of the box. This section only applies if your site sets a Content-Security-Policy header or meta tag.
Rover 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:
| Directive | Value | Why |
|---|---|---|
script-src | https://rover.rtrvr.ai blob: | SDK script + 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 — Rover 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) |
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 self-hosting guide for details.
CORS: You do NOT need to configure CORS on your server. CORS headers are set on Rover'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:roverEmbedfor Rover embed runtime requests andcloudAgentandcloudScrapefor 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.