Security as a contract, not a slogan.
Two promises, in plain words: we only ever show people what they already have permission to see, and we never train on your data. Security shaped every decision from the first commit, not after a customer asked. The page below is what we hand a CISO in a security review.
The boundary, drawn honestly
A simplified view of where your data lives, where it travels, and what enforces the seal between you and us. The full architecture diagram is in the trust pack; this is the version you’d want at a security review.
Same query, filtered to what youcan already see. The two sources you have access to resolve; the one you can’t stays locked, with a one-click request-access path. No widening, ever.
Fifteen controls we’d want an auditor to look at first
What’s implemented today and what we’re building toward, in the order we’d show a security review. Statement-of-applicability documentation will publish here once the SOC 2 + ISO 27001 audits begin.
Your data, isolated end to end
Row-level tenant isolation on a shared, single-region Postgres: every query is scoped to your company, so nothing is pooled or cached across companies. Independent third-party verification will follow once we begin a SOC 2 audit.
No training on customer data
Anthropic and OpenAI do not train on the API traffic we send, under their standard API terms (inputs may be retained briefly, up to 30 days, for abuse monitoring). The part that learns from feedback runs inside your own workspace; nothing leaks between companies. We do not fine-tune on your data.
Permission propagation, on every call
Native ACLs from Slack, Drive, GitHub, and Confluence flow into the map (Notion exposes no per-page permissions; its content is scoped to the installer or the workspace, chosen at connect time). Pulse re-checks the mirrored permissions on every answer; mirrors refresh on webhooks, syncs, and hourly sweeps.
Audit log with no in-product edit path
Writes, agent reads, API and MCP tool calls, and sensitive access events are recorded through a single audit chokepoint; there is no application code path that updates an audit row after it is written. Per-action retention is shipped (90 days default, 7 years for sensitive paths). Real-time export to your Splunk / Datadog / Elastic is on the Enterprise roadmap, and a cryptographic hash chain is planned, not yet shipped.
Audit retention with a workspace viewer
Sensitive actions (auth, billing, security, api_key, oauth) hold for 7 years; everything else ages out after 90 days. A nightly sweep prunes expired rows in 1000-row batches without locking the table. Owners get a filtered viewer at /app/admin/audit-log with URL-driven actor/action/resource filters so compliance reviews link to a specific slice without grepping a CSV.
Encryption at rest + in transit
AES-256 at rest, TLS 1.3 in transit. HSM-backed and customer-managed-key (BYOK) options planned for Enterprise.
Bring your own model key (BYOK)
Anthropic BYOK ships today for Enterprise; paste your own key on the admin page and every Claude call routes through it. AES-256-GCM encrypted at rest, decrypted only at request time. AWS Bedrock and Azure OpenAI are on the roadmap.
Scoped tokens, no master key
API tokens declare what they're allowed to do at creation, and Pulse refuses anything beyond that. There is no in-app admin bypass: application access paths run through the same permission engine and scope checks as any token, with no internal-only mode.
Agents read only what their creator can see
A Custom Agent's reads resolve through the same per-document permission gate as a person's, scoped to an explicit grant: a team, a Slack channel, a source type, or a single document. Fail-closed, so an agent with no grant reads nothing. A grant can never widen access past what the granting user can see; reads are intersected with each document's ACL at read time. A sub-agent invoked by another agent inherits the intersection of the whole call chain. Scope filters narrow what subject matter an agent searches, but the grant is the permission boundary, and a zero-grant read writes an `agent.read.no_grant` audit row.
Personal data stripped before anything reaches an external system
At execution time, before the payload reaches any executor (Slack, Linear, calendar) or leaves Pulse, the content passes through a redactor that strips email addresses, phone numbers, and SSN-shaped strings unless the agent is explicitly allowed to send them. The redactor runs after approval but before the external write fires, and logs how many fields were scrubbed to the audit record so admins can see what was removed.
A 5-minute undo on most external writes
Most external writes Pulse drafts (Slack DM, Linear comment, calendar invite) are reversible for 5 minutes after execution; the source system’s delete endpoint retracts the artefact. A few create-only writes have no clean delete in the upstream API (e.g. a new Linear issue) and are flagged non-revertible up front. After the window the audit-log row is permanent.
SSO + SCIM, IdP-enforced MFA
SAML 2.0 + OIDC for sign-in. SCIM for provisioning. MFA is whatever your own SAML IdP enforces, Pulse honors it at the assertion. Pulse-native session-timeout and IP-allowlist controls are on the roadmap, not shipped yet.
Vulnerability program
Pre-launch: every code change is reviewed by both founders, runs through static analysis (eslint + tsc), and ships behind feature flags where the surface is sensitive. Independent pen testing and a bug bounty program will follow as the customer base grows.
Subprocessors, listed and pinned
Sub-list is on the DPA page, versioned in git. New subprocessors will get 30 days’ notice via email before they go live. You can object; we have an exit path documented in the DPA.
Disaster recovery, designed
RPO target 5 min, RTO target 1 hour. Today we run single-region on Supabase with in-region replicas, daily backups, and point-in-time recovery; cross-region replication is on the Enterprise DR roadmap. Failover-drill cadence will publish on this page once we have sufficient production volume.
Incident transparency
Pulse is in early access. We have not had a public production incident yet. When we do, it shows up here, as a Sev-1 or Sev-2 with date, impact, time-to-resolution, and a link to the postmortem in the changelog. We don’t bury incidents.
We will publish every Sev-1 and Sev-2 here, with full postmortems in the changelog.
Want to walk the architecture?
We’ll send what we have.
Available today: the architecture overview, threat model and adversary assumptions, the permission-engine test suite that locks the boundary, sub-processor list, and our DPA. Once the SOC 2 and ISO 27001 audits complete, those reports will be available too. Email us from a corporate domain and you’ll have what we have within one business day.
Drafted by the founders. We read every reply.
Seven questions a security team actually asks
Where does our data live, physically?
Pulse runs on Supabase (Postgres) and Vercel. Today we serve from a single primary region; data-residency options for EU/US Enterprise customers will publish here once we have committed customers in those regions. No data leaves the primary region except for explicitly-configured exports the customer triggers.
Are model providers training on our prompts?
No. Anthropic's and OpenAI's API terms bar training on the inputs we send; both providers may retain inputs briefly (up to 30 days) for abuse monitoring before deletion. We are pursuing zero-data-retention agreements as volume grows; none is signed yet. The part that learns from feedback runs entirely inside Pulse, in your own workspace.
Can the founders read our data?
There is no admin tool that bypasses your permissions; the application has no internal-only mode that reads around the permission engine. Debugging on a customer report happens with your explicit consent and is recorded in the audit log. As a two-person company we hold infrastructure credentials, like every early-stage vendor; formal third-party verification of the controls around that access is what the SOC 2 audit (in prep) exists to provide.
What happens when we leave?
Export your map graph as JSON or JSON-LD from the export endpoint. Your index and graph are deleted within 30 days; we confirm the deletion in writing. Backups expire on the same schedule.
What can we get today as a security review pack?
Email support@pulsehq.tech from a corporate domain. Available today: architecture overview, threat model, sub-processor list, DPA template, our BYOK setup notes, the public security page itself. Future: SOC 2 + ISO 27001 reports once those audits complete (roadmap above).
Does Pulse ever send our data to the public web?
Only when a workspace admin explicitly enables the public-web fallback at /app/admin/research (off by default, demo workspaces hard-blocked). When enabled, only the user's question is sent to OpenAI's Responses API under the same no-training API terms as the rest of our inference. Workspace content, citations, ACL-scoped data, and user identifiers never flow out. Voice asks the user verbally before searching; Ask requires an explicit click. Web sources are labelled with a separate citation chip so a web result is never confused with team knowledge. Every call writes a research.web audit row visible in your audit log.
Can Pulse surface names tied to confidential work?
No. The Expert Finder ranks teammates per topic from decisions made, docs written, and questions answered, weighted toward recent work. Documents flagged confidential are left out before any ranking is computed, by the weekly job. So when Voice, Ask, the People surface, or your AI tools surface 'Diego is the most likely expert on X,' the rank that put Diego there cannot include a contribution from a confidential doc. Toggle a doc to confidential and any contribution from it is dropped on the next weekly recompute. The admin people page shows an aggregate 'confidential exclusions' count so you can see the filter working.
From the blog
Why AI tools should never train on your company's data
Every AI vendor uses the same privacy language. The differences underneath are enormous. The four structural commitments worth looking for, and why policy promises rarely survive competitive pressure.
Read →The trust problem with enterprise AI tools
Four diagnostic questions every AI vendor should answer with a clean yes or no. The deflections to watch for. Why structural commitments survive competitive pressure and policy ones do not.
Read →The new shadow IT, managing personal AI agents
Productivity pressure plus consumer priced AI plus capability gaps equals shadow AI agents at every software company. The four categories of new risk, and the three responses that actually help.
Read →Want to walk the architecture? We’ll send the trust pack.
Email support@pulsehq.tech from a corporate domain. The architecture overview, threat model, sub-processor list, and DPA template are all in your inbox within a business day.