Security
Your product, your logins, and your visitors, kept safe.
DemoPage runs every demo in an isolated browser on its own worker machines, never on the visitor's device. It opens only pages you approved, blocks payments, invites, API keys, and account changes in every mode, masks secrets on screen, stores sandbox logins encrypted with AES-256-GCM, and keeps data on Google Cloud in the United States.
The demo browser
- Each demo runs on a DemoPage browser worker, not on the visitor's device and not on the app server. Visitors get video and redacted screenshots, never cookies, tokens, or the browser's debugging port.
- Chrome runs with its sandbox on. Each session runs as its own unprivileged user with a private home and a work folder that is wiped afterwards, and every process it started is ended.
- The worker has no cloud service account, and its browsers are blocked from the cloud metadata server, private networks, and the worker's own port.
- It opens only https pages on the product's approved list. Anything else is refused before it loads.
What it can't click
- In every mode, it refuses payments, plan and billing changes, invites, API keys and tokens, logout, password and two-factor settings, and deleting an account or workspace.
- Outside sign-in, it keeps sign-up, trial, and booking pages out of the demo browser.
- A network guard backs this up: in a demo, delete and update requests, GraphQL mutations, and posts to write-shaped paths fail, and payment processors' pages never load.
- An action you approve for a sandbox runs only after a passing dry run and an owner's or admin's approval, and it only repeats that approved run.
Secrets on screen
- Before any page script runs, DemoPage blanks API keys, JWTs, and long tokens in the page text, and keeps doing it as the page changes.
- Password, card number, security code, bank account, and ID number fields are shown as dots, even if a page switches them to plain text. Card numbers in text are cut to their last four digits.
- Masked text also stays out of the narration, the recording, and what the AI model sees.
Your sandbox logins
- A sandbox or demo login you give DemoPage is sealed with AES-256-GCM on our servers and never shown in full, even to you. The AI model sees placeholders, not the password.
- Login values reach the demo browser over an authenticated connection and are never written to the worker's disk.
- A saved sign-in lasts at most 24 hours, and changing the login or the team password ends it.
Visitors and what they type
- Visitors' questions are treated as untrusted text. They never become navigation or tool calls, and an instruction hidden in a question becomes a follow-up for your team.
- Voice clips are sent for transcription and then discarded; the transcript is kept, not the audio.
- Rate limits count visitors by a salted hash of their address; the address itself isn't stored.
- In a guided setup, the customer signs in themselves. Their keystrokes pass through to the page and are never stored or logged, and setup sessions keep no video or page text.
Accounts and access
- Passwords are hashed with scrypt. Sessions are signed and end at once when a password is reset or a teammate is removed.
- Invite, reset, and confirmation links are single-use, expire, and are stored only as SHA-256 hashes.
- Each account reaches only its own product. A demo goes live without review only when the sign-up email is on the website's domain and has been confirmed.
- AI tools connect with OAuth 2.1 and PKCE (S256). Their tokens are stored as hashes and end when the password is reset.
Data, hosting, and retention
- Hosting, computing, and backups are on Google Cloud in the United States. Data moves over TLS.
- Service providers: Google Cloud (hosting), Anthropic, OpenAI, PyAI, and TypeSafe (AI features), and Resend (email).
- Demo sessions and recordings are kept while your account is active, up to the most recent 1,000 across DemoPage plus each link's 20 most recent and the recording it shows, and deleted when you ask. Backups roll off within 30 days.
- We sign a Data Processing Addendum where the GDPR, UK GDPR, or CCPA requires one.
Not available yet
Being built with early Scale customers. If your review needs one of these today, tell us before you start.
- ·Single sign-on (SSO) and audit export
- ·A private-network runner that reaches apps behind your firewall
- ·Data residency outside the United States
Keep these out
DemoPage's terms don't allow these in sandboxes, logins, or the pages you pick. Use made-up records instead.
- ×Protected health information
- ×Payment card data
- ×Government ID numbers
Questions
What security teams ask.
Found a vulnerability? Email legal@demopage.io with the steps to reproduce it, and give us a chance to fix it before you share it. Don't test against other customers' demos or data. Our security.txt has the same contact.
Can DemoPage change anything in our product?
+
Not by itself. Payments, billing, invites, API keys, logout, password settings, and deletions are blocked in every mode, and a network guard fails write requests during demos. A sandbox action runs only after a passing dry run and your approval.
Does the AI model see our sandbox password?
+
No. The login is stored encrypted and filled in by DemoPage's browser; the model sees placeholders, and secrets on screen are masked before it reads the page.
Where is our data stored?
+
On Google Cloud in the United States. Sessions and recordings are kept while your account is active, and each link always keeps its 20 most recent and the recording it shows. They're deleted when you ask.
Can we send a security questionnaire?
+
Yes. Send it to legal@demopage.io, along with any vulnerability report.