Security & Policies

How Rover scopes browser work, owner actions, domains, identity, and site keys.

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).

Rover Agent 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.

Browser execution

Normal Rover page actions execute in the visitor's browser tab and use that tab's signed-in state. The browser lane has four important boundaries:

1.Rover does not copy the visitor's passwords, cookies, or browser credentials into model input. It acts through the existing page session.
2.Page actions operate on elements available to that visitor. They do not grant access beyond the page's own authorization.
3.Browser actions remain subject to the page's CORS, CSP, origin, and browser security rules.
4.The normal page representation is a bounded semantic accessibility structure, not raw DOM or a continuous screenshot feed. That semantic page context is sent to Rover services and models when needed to plan and perform the request.

Owner actions run on separate lanes

Customize can add actions that do more than page JavaScript: Rover's servers may call an owner webhook, and server code may run in Rover Code Sandbox. These actions use private server-side configuration, not the public embed bundle.

Webhooks are signed, bounded server-to-server requests to the endpoint the owner configured.
Server code runs in the isolated Rover Code Sandbox with scoped secrets and bounded time and output.
Browser and server-code actions always require visitor confirmation. Support-like or account-like actions are also forced through confirmation.
Page scopes decide where an action is available; backend authorization still decides whether it may run.

Rover Analytics Owner Access

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

1.Site-tag Rover Analytics writes are authenticated by signed Rover session claims, not by raw browser-supplied site IDs.
2.Rover 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.

A2W Commerce & Delegation

Agent-to-Web runs keep humans in control of money, credentials, and consequential writes.

Payment hard-stop — payment always parks the run as input_required with reason=payment_confirmation_required and an input.links.confirm URL. The human completes the charge (and any SCA challenge) on the payment rail itself; card data never passes through the agent or the A2W payload, and the merchant stays merchant of record.
Human delegation — rds_ delegation tokens are key-bound, scoped, spend-capped authorizations minted by the verify loop (input.links.verify) and carried as auth.mode=delegated_session. They are never a raw site credential, and subject / payment.maxAmount scope who the run acts for and how much it may spend.
Sign-in resume — when a merchant sign-in hits a magic-link or OTP wall (sign_in_link_required), the value the human pastes to POST /v2/a2w/runs/{id}/auth-input is AES-encrypted at rest, consumed one-shot to resume the run, and never echoed back to any model, payload, or event.
Sensitive-action gate — consequential non-commerce writes (deletes, sends, irreversible changes) park as action_confirmation_required with a confirm link for the human instead of executing silently.

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 Cloud sandboxes are enabled, Rover 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, 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, 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://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)

Rover 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

Loading Rover's SDK normally needs no CORS change on your server; Rover's CDN serves the required headers. Your own browser actions and APIs still follow their existing CORS policy.

Key Management

The current direct-site controls live under Install in the Workspace:

Rotate production key creates replacement install material, then stops the old key. Update every snippet you copied by hand.
Allowed domains and domain matching update the saved deployment policy without rotating the key.
Delete site removes the site and its access. This is destructive and requires confirmation.

Capability flags are enforced server-side for cloud APIs: roverEmbed for Rover 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/v2/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 ReferencePublic browser, A2W, Connect AI, and analytics contracts.ConfigurationThe install tag, supported SDK overrides, and runtime methods.

Security & Policies

How Rover scopes browser work, owner actions, domains, identity, and site keys.

Domain Scoping

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).

Browser execution

Normal Rover page actions execute in the visitor's browser tab and use that tab's signed-in state. The browser lane has four important boundaries:

1.Rover does not copy the visitor's passwords, cookies, or browser credentials into model input. It acts through the existing page session.
2.Page actions operate on elements available to that visitor. They do not grant access beyond the page's own authorization.
3.Browser actions remain subject to the page's CORS, CSP, origin, and browser security rules.
4.The normal page representation is a bounded semantic accessibility structure, not raw DOM or a continuous screenshot feed. That semantic page context is sent to Rover services and models when needed to plan and perform the request.

Owner actions run on separate lanes

Webhooks are signed, bounded server-to-server requests to the endpoint the owner configured.
Server code runs in the isolated Rover Code Sandbox with scoped secrets and bounded time and output.
Browser and server-code actions always require visitor confirmation. Support-like or account-like actions are also forced through confirmation.
Page scopes decide where an action is available; backend authorization still decides whether it may run.

Rover Analytics Owner Access

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

1.Site-tag Rover Analytics writes are authenticated by signed Rover session claims, not by raw browser-supplied site IDs.
2.Rover 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.

A2W Commerce & Delegation

Agent-to-Web runs keep humans in control of money, credentials, and consequential writes.

Payment hard-stop — payment always parks the run as input_required with reason=payment_confirmation_required and an input.links.confirm URL. The human completes the charge (and any SCA challenge) on the payment rail itself; card data never passes through the agent or the A2W payload, and the merchant stays merchant of record.
Human delegation — rds_ delegation tokens are key-bound, scoped, spend-capped authorizations minted by the verify loop (input.links.verify) and carried as auth.mode=delegated_session. They are never a raw site credential, and subject / payment.maxAmount scope who the run acts for and how much it may spend.
Sign-in resume — when a merchant sign-in hits a magic-link or OTP wall (sign_in_link_required), the value the human pastes to POST /v2/a2w/runs/{id}/auth-input is AES-encrypted at rest, consumed one-shot to resume the run, and never echoed back to any model, payload, or event.
Sensitive-action gate — consequential non-commerce writes (deletes, sends, irreversible changes) park as action_confirmation_required with a confirm link for the human instead of executing silently.

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 Cloud sandboxes are enabled, Rover 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.

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, 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://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)

Rover 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.

CORS

Loading Rover's SDK normally needs no CORS change on your server; Rover's CDN serves the required headers. Your own browser actions and APIs still follow their existing CORS policy.

Key Management

The current direct-site controls live under Install in the Workspace:

Rotate production key creates replacement install material, then stops the old key. Update every snippet you copied by hand.
Allowed domains and domain matching update the saved deployment policy without rotating the key.
Delete site removes the site and its access. This is destructive and requires confirmation.

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

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

API ReferencePublic browser, A2W, Connect AI, and analytics contracts.ConfigurationThe install tag, supported SDK overrides, and runtime methods.

Security & Policies

Domain Scoping

Navigation Behavior

Browser execution

Owner actions run on separate lanes

Rover Analytics Owner Access

Agent Attribution Trust Tiers

A2W Commerce & Delegation

External Tab Context

Content Security Policy (CSP)

Key Management

Security & Policies

Domain Scoping

Navigation Behavior

Browser execution

Owner actions run on separate lanes

Rover Analytics Owner Access

Agent Attribution Trust Tiers

A2W Commerce & Delegation

External Tab Context

Content Security Policy (CSP)

Key Management