Security

Security overview

AISwarmQA runs a real, autonomous browser against a target you provide. This page describes the technical controls that constrain what an audit is allowed to do, in plain terms, so security-conscious teams can evaluate the product before pointing it at a real site.

Scope of an audit

You only ever run AISwarmQA against sites you provide and are authorized to test. An audit is not a scanner that discovers or touches infrastructure you did not name: it launches a real Chromium browser against the target URL you submit, crawls a bounded set of same-origin pages, and runs a fixed set of deterministic checks plus, on some plans, an AI-planned exploration pass.

Network & target enforcement

Every audit target is validated before a browser ever navigates to it, and again on every single request the browser makes during the audit — not just the first one.

  • Hostnames are checked against a deny-list of loopback, link-local, private (RFC1918), CGNAT, multicast, and other non-public IP ranges, plus known metadata endpoints (e.g. metadata.google.internal).
  • The check does not stop at the hostname string: AISwarmQA resolves DNS for the target and rejects it if any resolved IP address lands in a forbidden range, which defeats DNS-rebinding attempts to reach internal services through a public-looking hostname.
  • A Playwright network guard is attached to every audit browser context and re-validates the destination of everyrequest — page navigations, redirects, XHR/fetch calls, and sub-resources — aborting anything that resolves to a forbidden target mid-audit.
  • Same-origin navigation policy: proposed navigations and clicks are resolved against the originally validated target and re-checked after every step. Non-http(s) protocols (javascript:, data:, file:, mailto:,tel:) are blocked outright for AI-driven navigation.

Destructive-action blocking

AI-planned browser missions (the Browser Agent and Browser Swarm) run under an explicit safety policy before any proposed action is executed, not as an afterthought. The policy validates the action schema, confirms the target element was actually observed in the current step (an agent cannot invent a selector), and rejects actions whose intent matches a blocked category: account deletion, subscription cancellation, logout, purchases and checkout, payment or billing changes, publishing or sending content, file upload/download, and edits to password or other sensitive fields.

This blocking is intentionally conservative. A legitimate action being blocked is an acceptable cost; a destructive action being allowed through is not. Agents cannot supply raw CSS selectors, XPath, arbitrary JavaScript, local file paths, or URLs that bypass the same-origin policy above — every action goes through the same structured, validated action schema.

What the AI providers see

When AI-assisted planning or exploration is used, the model only ever receives a sanitized snapshot of the page — never cookies, localStorage, authorization headers, submitted form values, or passwords. Before anything is sent to an AI provider, AISwarmQA strips email addresses, token-like strings, API keys, bearer/JWT values, credit-card-like number patterns, and sensitive query parameters (for example token, access_token, api_key, secret, password, session). The same redaction applies to the step-by-step observations an autonomous mission records while it runs, and to what gets persisted as the audit's planning snapshot.

Evidence privacy

Screenshots and other evidence captured during an audit are stored in private cloud storage and served only through application-controlled routes — never a raw, public storage URL.

  • Sharing a piece of evidence outside your workspace is opt-in per item, off by default.
  • A shared evidence link can be revoked at any time, which immediately invalidates it.
  • Shared links can carry an expiry and stop resolving once it passes.
  • Evidence itself follows your plan’s retention window and is deleted — including from storage, not just hidden in the UI — once that window closes. See Privacy Policy § Retention.

Bounded execution

Every audit runs under explicit, enforced ceilings rather than an open-ended loop: a maximum number of pages crawled per audit, a maximum number of steps/navigations/clicks/form-fills/screenshots per AI-driven mission, a maximum number of concurrent agents in a swarm run, and a maximum estimated cost per audit. Missions that exceed a bound stop rather than continue. External navigation away from the authorized target is disabled at the configuration level for AI-driven missions, not only by policy.

Infrastructure & sub-processors

The product is built on a small set of named infrastructure providers, listed here for transparency:

  • Supabase — authentication, the primary application database, and private evidence storage.
  • Anthropic — AI planning and autonomous browser exploration, under the data-minimization policy above.
  • Railway — application and worker hosting.
  • Stripe — billing. AISwarmQA never sees or stores raw card numbers; only Stripe-issued customer/subscription identifiers are stored.
  • Resend — transactional email delivery (account and billing notifications).
  • GitHub — optional, workspace-authorized export of findings to GitHub Issues via a GitHub App installation.

See the full list with purposes in the Privacy Policy.

Reporting a vulnerability

If you believe you have found a security issue in AISwarmQA, please report it privately rather than opening a public issue, and give us a reasonable window to investigate and respond before any public disclosure. See the contact page for how to reach us.