Security
Last updated: July 28, 2026
inDemo logs into your product and drives it in front of your prospects. That is a lot of trust to ask for, so this page describes what actually happens to your credentials, your product, and your leads' data — in the specific rather than the reassuring.
The demo runs inside a fence
Every demo session runs in a headless browser governed by a navigation policy. Before the agent performs any action — a click, a form fill, a navigation — the action passes through a single gate that checks it against an allow-list of origins derived from your app URL and login URL, plus a list of forbidden paths.
- A navigation to an origin outside the allow-list is refused, not followed.
- A click that would open an off-list origin is blocked before it fires.
- Only
httpandhttpsURLs with a real host qualify at all. - The gate is the only path to action execution, so the agent cannot route around it.
This is why the agent cannot wander onto your admin panel, a third-party site, or anything else you didn't point it at — the restriction is structural, not a prompt instruction the model might ignore.
Credentials you connect
To demo your product, you give inDemo a demo account. That credential is treated as a reversible secret:
- Encrypted at rest with AES-256-GCM, under a key derived from a deployment secret that never leaves the server environment.
- Never serialized to any API response. The field is excluded from JSON output at the type level, so it cannot leak through a new endpoint by accident.
- Never shown to a lead. The login happens inside the session before the prospect sees anything; the credential is not rendered, typed visibly, or included in the recording.
- The same treatment covers the other reversible secrets we hold — saved login sessions, Slack webhooks, and the Gmail refresh token if you connect follow-up email.
We strongly recommend connecting a dedicated demo account with demo data, not a real production login. Nothing about the design requires production access.
Demo recordings
Every demo is recorded and transcribed so you can audit what was said. Those recordings are the most sensitive thing we store, and they're handled accordingly:
- Stored in a private object storage bucket with public access blocked. There are no public object URLs.
- Playback is proxied through the API and authorized per account — a recording URL is useless without a valid session for the account that owns it.
- Retention is configurable and enforced by a scheduled job that deletes expired recordings from storage, not just from the index.
- Video bytes never sit in the database or the application heap — uploads arrive as ordered, idempotent chunks and finalize into a single object.
Your account
- Passwords are hashed with bcrypt. We cannot read them.
- Login compares against a hash even for unknown addresses, so accounts can't be enumerated by response timing.
- Sessions use HttpOnly, Secure, SameSite=Lax cookies with a bounded lifetime.
- Sensitive changes — edits to your demo script and other versioned settings — are written through a single audit choke point that records what changed, from what, to what.
- Sign-up is protected by Cloudflare Turnstile.
Where your data lives
The application and its Postgres database run on Fly.io with Frankfurt as the primary region. Recordings live in private S3-compatible object storage. Transport is TLS end to end.
Language-model inference is not in the EU: narration and answers are generated by OpenAI and Google models hosted in the United States. If EU-only processing is a hard requirement for you, tell us before you sign up rather than after — we would rather lose the deal than misrepresent this.
Subprocessors
These are the third parties that may process data on our behalf:
| Provider | What it does | Where |
|---|---|---|
| Fly.io | Application hosting and compute | Frankfurt (primary), EU |
| Tigris | Object storage for demo recordings | EU / global edge |
| OpenAI | Language model for demo narration and answers | US |
| Gemini Live for real-time voice | US | |
| Resend | Transactional and follow-up email | US / EU |
| Polar | Subscription billing and payments | EU |
| Cloudflare | Turnstile bot protection, CDN for this site | Global edge |
| Firecrawl | Reading the public docs you point us at | US |
| PostHog | Website analytics for indemo.ai | Frankfurt, EU |
We'll post changes to this list here. See the Data Processing Addendum for the contractual version.
What we don't have yet
inDemo is an early-stage product and we'd rather you learn this here than in a questionnaire three weeks into an evaluation. As of today we do not have:
SOC 2 or ISO 27001 certification · a third-party penetration test · SAML/OIDC single sign-on · multi-factor authentication · a contractual uptime SLA.
If any of those is a blocker for you, email us and say which one. It tells us what to build next, and we'll tell you honestly where it sits.
Reporting a vulnerability
Found something? Email support@indemo.ai with "Security" in the subject line. We'll acknowledge within two business days. We won't pursue legal action against anyone who reports a genuine issue in good faith and gives us a reasonable window to fix it before disclosing.
Questions
Security review, questionnaire, or something this page doesn't answer — support@indemo.ai. A real person answers.
Never miss another lead.
30 free demo minutes · no card