Security, privacy & your data

No. We do not sell personal information and we do not share it for cross-context behavioural advertising, as those terms are defined by the California Consumer Privacy Act (CCPA/CPRA). Our public site loads no advertising or cross-site tracking tags at all, so there is no ad-tech pipeline to sell into. Because no sale or sharing takes place, there is no "Do Not Sell or Share My Personal Information" opt-out to offer.

No. We do not train any model on your content, and the providers we use do not either. Anthropic’s published policy is that by default it will not use inputs or outputs from its commercial products, including the API, to train its models; OpenAI states that data sent to its API is not used to train or improve its models unless you explicitly opt in. This is the default for every API customer — there is no flag to enable and nothing we had to negotiate, and we would rather say that than imply a bespoke contract we do not hold. It applies to API traffic, which is all Demoplex sends; the consumer chat products of both vendors have different terms. Worth separating from retention: providers keep short-lived abuse-monitoring logs (OpenAI’s default is 30 days). That is not training, but it does mean prompt content sits with the provider briefly. Stricter zero-retention arrangements exist and need the provider’s approval — ask us if your policy requires one.

You do. You retain ownership of everything you upload or create. You grant us only the limited licence needed to host, process and display that content in order to run the service, and that licence ends when the content is deleted.

No, and this is the single most useful thing to tell your security team. Demoplex is a demo platform: the content you capture is meant to be a demonstration of your product, not a copy of your production system. Use demo or sample data in the environment you capture from. Where a captured screen does show something real, redact it before you publish: the Demoplex capture extension lets you mark regions to redact at capture time, and a DOM capture stays text-editable afterwards, so you can replace names, figures or account numbers with sample values. Keeping real customer records out of demo content removes most of the risk surface before any of our controls have to do any work.

Account details you provide (name, work email, company), the content you create, and usage data needed to operate, secure and meter the service. Separately, when a prospect views a demo you have published behind an access gate, we record the identity they submit and their engagement with that demo — on your behalf, for your reporting.

In transit, yes — all traffic is served over TLS. At rest, the database volume is encrypted by our hosting provider, and on top of that we separately encrypt the highest-value secrets in the database with Fernet (AES-128-CBC with HMAC-SHA256): LLM and integration API keys, OAuth tokens, and MFA secrets. We are precise about the boundary: that covers credentials, not ordinary business content such as demo text or prospect contact details, which rely on volume-level encryption. We do not currently offer customer-managed encryption keys.

Passwords are never stored. We store a PBKDF2-HMAC-SHA256 hash with a unique random salt per user and 200,000 iterations, which is above the current OWASP minimum. Password reset uses a single-use, expiring token.

Yes. TOTP multi-factor authentication works with any standard authenticator app; the secret is stored encrypted and recovery codes are stored hashed. A platform administrator can require MFA across the platform. Google and LinkedIn sign-in are supported, and enterprise SSO can be enabled per workspace.

Every record carries a workspace identifier and every request is scoped to the caller’s workspace. This is enforced at the query level rather than in the interface — AI knowledge retrieval, for example, filters on the workspace inside the SQL itself, so a retrieval cannot return another customer’s content even in principle. To be precise: this is logical isolation on shared infrastructure, not a separate database per customer.

Sign-in, MFA and cost-bearing endpoints are rate-limited using a Redis-backed sliding window. Request and prompt sizes are bounded, and inbound webhooks are signature-verified. One trade-off worth stating: if the rate-limiting store itself becomes unreachable, limiting fails open rather than locking every customer out of sign-in. That is a deliberate availability choice. We do not currently lock an individual account after repeated failed sign-ins — brute-force protection comes from rate limiting plus, where you enable it, MFA.

Yes, for security. Each sign-in records the IP address, an approximate location derived from it (the country, plus region or city when our network edge supplies them) and the browser and operating system. We never send your address to a third-party geolocation service; when no location is available it is simply recorded as unknown, and location from an IP is approximate, so a VPN or mobile network can place you elsewhere. You can see every place your account is signed in and sign any session out from your profile. Workspace administrators see each member’s last sign-in time, location and device, not their IP address. We email you when your account is signed in to from a country it has not been used from before. Platform administrators see sign-in locations only as counts per country per week, not tied to any person or workspace. Sign-in records, including the full IP address, are deleted 30 days after sign-out or 90 days after last use; the audit log keeps the IP address and country for its retention period (2 years by default).

Yes. Every state-changing request (create, update, delete) is written to an audit log capturing the actor and their email, the action, the affected resource, the IP address (and the country it maps to, where our network edge supplies one), the user agent and a timestamp. Two honest limits: read access is not logged, so the trail shows what changed rather than what was viewed; and the log is an ordinary database table, not write-once tamper-evident storage. Entries are kept for a configurable period (2 years by default) and then removed by age; individual entries cannot be deleted, and every purge is itself recorded in the log. Workspace administrators can read their own audit trail directly, scoped to their workspace.

Prompts are built from your own workspace content plus the visitor’s message. Before any of it leaves our systems we run deterministic redaction that masks emails, phone numbers, card-like and account numbers, national IDs, IP addresses, labelled fields such as "Name:" or "Address:", and inline cues such as "my name is …". We are precise about what that means: it is pattern-based defence in depth that substantially reduces exposure, not a guarantee of complete de-identification. It is deliberately conservative and will sometimes mask a harmless string. It also applies to text: if your workspace enables live voice, the audio stream itself reaches the speech providers unredacted.

Knowledge retrieval is filtered by workspace inside the database query itself, not in application code above it, so a retrieval returns only your own content and a prompt is assembled only from it. To be precise about what that is: enforced isolation on shared infrastructure, the same logical boundary described in the workspace-isolation answer above — not physically separate storage per customer.

This is the right question to ask, and we will not claim it is solved. Captured page content is passed to the model as data inside an explicit fence, with instructions never to follow directives found inside it. That is a strong mitigation, not a proof — indirect prompt injection is an open problem across the industry and no fence is known to be perfect. What carries the weight is the layer underneath: actions the AI can take during a demo are validated server-side against the demo’s own steps, so even a model that were successfully misled cannot be steered to an action the author never defined, and it holds no credentials to your systems. Treat captured pages as public content regardless.

No. Embeddings are computed on our own infrastructure with a self-hosted open-source model, so the documents you index for AI grounding are never sent to an external embedding API, and there is no third-party vector database holding your content. Most tools in this category cannot say that.

Anthropic for the conversational agent, OpenAI for image generation, Murf for the synthesised voice your demo narration is rendered in, and — only if your workspace enables live voice — Deepgram for speech-to-text, ElevenLabs for speech synthesis, and LiveKit for real-time transport. Live-voice providers receive nothing unless live voice is switched on.

Yes, from the dashboard. Export produces a machine-readable file covering customer records, chat sessions, audit records and demo engagement history — including the prospect details and AI question-and-answer transcripts captured during a demo. Erasure is a genuine erasure rather than a hidden flag: identifying fields are overwritten and related records are deleted or anonymised, so the person can no longer be identified. Both are rate-limited to prevent misuse. Scope worth knowing: erasure matches on the exact email address supplied, and it does not reach inside screenshots or page captures you recorded — if a captured page shows someone’s personal data, delete that capture directly.

Workspace content is retained while your account is active. Each workspace can additionally set its own retention window for engagement data, and a scheduled purge enforces it automatically for engagement records, activity and logs. Demos and the screenshots inside them are kept until you delete them, so that a live demo never expires underneath you. On workspace deletion, content is removed within 30 days.

In the United States — the application and PostgreSQL database run in a US West region, with TLS enforced on database connections. Demoplex is a US-hosted service and we do not operate regional data boundaries today. If your policy requires data to stay in a specific region, tell us before you buy — we would rather say so up front than after a trial.

For the personal data inside your workspace — your prospects, your viewers, your content — you are the controller and Demoplex is your processor. The vendors listed below are our sub-processors, engaged to deliver the service to you. For your own account data (your name, work email, billing) we are the controller. That split is what a DPA formalises, and it is why the DPA is signed by you, not by your prospects.

The categories, with the vendors we use today: hosting and database (Railway, US West) and CDN/edge (Cloudflare); AI (Anthropic for the agent, OpenAI for image generation); email delivery (Resend); payments (Stripe — card details go directly to Stripe and never touch our servers); error monitoring (Sentry). Demo narration is rendered to audio by Murf, which receives the narration script only. If your workspace enables live voice, that adds Deepgram, ElevenLabs and LiveKit. Optional integrations you switch on yourself — calendar, meetings, cloud storage — add only the provider you connect. Embeddings are computed on our own infrastructure, so no third party receives your knowledge base for indexing. We will send the current list with change notification terms as part of a DPA.

Platform administrators cannot read your workspace content. Their role is operational — onboarding and offboarding workspaces, plan and platform configuration — and it is enforced in code rather than by policy: a platform administrator account belongs to no workspace, every query for workspace content is filtered by workspace, and there is no impersonation or "log in as this customer" feature anywhere in the product to step around that. The administrative dashboard has no route into a workspace at all. What they can see is aggregate operational data — how many sessions and how much usage a workspace generated, which is how the service is billed and sized — and never the content: not your demos, not your prospects’ details, and not the transcripts of what a viewer asked. Inside your own workspace, access is role-based and every state-changing action is written to the audit log.

Not yet, and we will not imply otherwise. The platform is built and reviewed against SOC 2 and ISO 27001 control expectations, and those controls are documented publicly in our security policy — but a formal attestation requires an independent third-party audit we have not completed. We can send our security documentation, subprocessor list and a completed copy of your questionnaire on request. If a signed certificate is a hard requirement for you, we would rather you know now than after a trial.

Not yet. We run a documented responsible-disclosure process and welcome findings from your own security team. If you want to test before you buy, contact us and we will authorise it in writing.

Yes to both. Email security@demoplex.io and we will send a DPA to sign and complete your questionnaire. Most of a standard questionnaire is already answered on this page, so it is usually quick.

Standard plans are provided without a contractual uptime guarantee. We monitor availability continuously and run on managed infrastructure with automated security patching, but if you need a committed SLA with remedies, that is an enterprise agreement — ask us.

Email security@demoplex.io. We acknowledge reports promptly, keep you updated while we investigate, and will not pursue good-faith researchers who follow our responsible-disclosure policy.