Last reviewed: October 29, 2026.
Security at IntelliPrompter is architecture, not policy. The parts of the system that process customer meeting data were designed so that data never leaves the user's machine in the first place. That is not a configuration flag. It is where the code runs. This page describes what that means in practice, what we send out when, and the controls around the pieces we do operate.
Sensitive values on the user's device are encrypted using the operating system's native secret store through Electron's safeStorage API, which maps to macOS Keychain, Windows DPAPI, and Linux libsecret. OAuth refresh tokens for Google Drive and Atlassian are stored this way in the integrations.auth_token_encrypted column of the local SQLite database. Refresh tokens never leave the main process; the renderer only sees short-lived access tokens indirectly through IPC-mediated API calls.
AI provider API keys supplied by the user for bring-your-own-key routing are encrypted with AES-GCM at rest using a per-install key held in safeStorage, through the helper at src/main/ai/encryption.ts. The same primitive protects every integration token we persist.
Server-side data lives in the Supabase Postgres project that powers the marketing site (waitlist + blog subscribers today, billing records when Stripe is wired). Supabase provides platform-level encryption at rest for the whole database; billing and other high-sensitivity columns are additionally protected with column-level encryption so that even operators with database access cannot read them in cleartext without the application key.
The user's local SQLite database inherits whatever full-disk encryption the user has configured (FileVault on macOS, BitLocker on Windows). We recommend enabling it; neither the app nor this policy can substitute for the operating system refusing to decrypt a stolen drive.
All network traffic the application initiates uses TLS 1.2 or higher. The marketing site at intelliprompter.com serves HSTS, redirects every HTTP request to HTTPS, and runs on Vercel's edge network with modern cipher suites. API calls to AI providers (Anthropic, OpenAI, Google), integration endpoints (Google Drive, Atlassian), and our own hosted edge functions all use TLS. We do not operate TLS-terminating proxies in front of provider traffic.
The marketing site's Supabase Postgres database has row-level security enabled on every user-facing table. Policies enforce that an authenticated user can only read or write their own rows. Public read paths exist only where they are intentional (for example, the model catalog at /model-catalog.json).
The admin surface on the marketing site is gated by a check on profile.role = 'admin' inside server components. There is no client-side route that renders admin data; every admin page fetches through server actions that verify the role on each request.
Server-side administrative tasks use a separate Supabase service-role key held only in Vercel environment variables. That key is never shipped in the client bundle, never committed to the repository, and is scoped per environment (preview versus production). Developer access to the service- role key is limited to the Vercel project owners.
Access to subservice organizations (GitHub, Vercel, Supabase, Resend, GoDaddy, Anthropic Cloud) is through individual operator accounts with MFA where the provider supports it. We are a single-founder team today, which keeps the access surface small; the plan at team-growth time is to adopt Clerk- backed SSO for the app itself and SSO for every subservice organization that supports it.
The parts of IntelliPrompter that touch meeting audio run entirely on the user's machine. There is no cloud transcription service in our architecture.
The one network boundary any meeting data can cross is the AI provider call for coaching and for the Ask-AI feature, and only when the user has chosen to use a cloud provider. In that case we send a bounded transcript window to the provider the user has configured, using the user's own API key under their own contract with the provider. In Self- only privacy mode (BL-PC-06), the audio pipeline is forced to microphone-only at capture, the coaching engine and Ask-AI filter the transcript to speakers tagged as the user before building prompts, and the AI system prompt is prepended with an instruction that the model can only hear the user. End-to-end, nothing the user did not say themselves reaches the provider in that mode.
If the user has Ollama configured for local inference, the pickProviderForTask() router prefers it for classification and summarization tasks, which keeps the high- volume background calls (proactive topic detection, summarization) entirely on-device. The full data flow and the exact scopes of every integration are documented in the privacy policy.
If you believe you have found a security vulnerability in the IntelliPrompter website, API, desktop app, or related infrastructure, please email security@intelliprompter.com. We read every message and acknowledge within 48 hours. Please include enough detail for us to reproduce the issue, your preferred name for any public credit, and your contact for follow-up questions.
We publish our security contact per RFC 9116 at /.well-known/security.txt. That file is canonical; if anything on this page conflicts with it, treat the security.txt file as the source of truth for the contact address and expiration.
We do not operate a bug bounty program today. We are a pre-launch, single-founder product; a paid program is on the roadmap once the team and the customer base justify the triage overhead. In the meantime we commit to acknowledging reports, keeping researchers informed of our fix progress, and crediting disclosures publicly when the reporter wants that credit.
Please do not test against production customer data, do not run denial-of-service attacks, and do not pivot into any system beyond proving the finding. Good-faith research in line with those limits will not result in legal action.
If a security incident affecting customer data is confirmed, we notify affected users within 72 hours of confirmation. For users in jurisdictions covered by GDPR this aligns with the 72-hour supervisory authority notification requirement under Article 33. We will tell affected users what happened, what data was involved, what we are doing about it, and what, if anything, we recommend they do.
After the immediate response is contained, we publish a post-mortem for incidents that affected customer data. The post-mortem states what we know and what we do not know, avoids blame language, and lists concrete changes we are making so the same class of failure cannot recur.
A formal written incident response plan is a known gap today and is tracked internally. Our current scale (single founder, private beta, no payment processing live) keeps the response simple, but we treat the plan as a prerequisite for the SOC 2 audit observation period described below.
Every CI run on the repository executes the OSV scanner against the full dependency graph (both the Electron application and the Next.js marketing site). The workflow lives at .github/workflows/osv-scan.yml and runs on push, pull request, and a nightly schedule. The build fails when a known vulnerability of moderate severity or higher is introduced into the lockfile.
Dependabot is configured for both pnpm workspaces and the GitHub Actions ecosystem. It opens pull requests automatically for security advisories; patches to internal transitive dependencies are preferred as pnpm.overrides entries so we are not blocked waiting for direct dependency maintainers to re-release.
We treat security advisories as release-blocking. A dependency PR that passes CI merges on the same day; a failing one gets a triage comment on the PR within the next business day.
All production secrets live in Vercel environment variables for the marketing site and in Electron safeStorage for the desktop app. No secret value is ever committed to the repository. Local development reads from .env.local, which is listed in every .gitignore that could reach it.
Secret regressions are caught in CI by secretlint, which scans the diff on every push and pull request. The scanner catches well-known patterns (AWS access keys, Google API keys, Stripe keys, generic high-entropy strings in suspicious contexts) and fails the build when a match is found. Historical commits were baselined into the ignore file at CI adoption time; new matches must be either rotated or explicitly justified.
If a secret is ever exposed, our response is to rotate the key at the issuing vendor first, revoke the compromised credential second, and only then begin the post-incident investigation. Rotation precedes investigation because an unused valid credential is still a live credential.
IntelliPrompter is not SOC 2 Type I or Type II certified today. We are a pre-launch, single-founder product; a formal audit observation period is a cost and process that only makes sense once we have enterprise customers requiring it.
In the meantime, our system description is maintained in SOC 2 format against the AICPA SSAE 18 Trust Services Criteria. It documents system boundaries, subprocessors, data classes and flows, the control environment, and known control gaps. It is the document we expect to hand to an auditor on day one of an observation period; keeping it current now reduces that onboarding cost later.
We are happy to share the system description, our subprocessor list, and this security policy with any prospective enterprise customer under NDA. Email security@intelliprompter.com if you need additional documentation for a vendor security review.
Email security@intelliprompter.com. We acknowledge within 48 hours and will keep you informed through fix and disclosure.
This page is a living commitment. When our posture changes, this page changes with it, and the system description linked above is updated in the same commit.