Security as a contract, not a slogan.
Security wasn’t bolted on after a customer asked, it shaped every architectural decision from the first commit. The shape of every Pulse decision: would this hold up to a CISO walking the architecture diagram in a security review? If the answer’s no, we don’t ship it. The page below is what we hand them.
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.
Twelve 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.
Tenant isolation, top to bottom
Per-tenant DEKs, per-tenant retrieval index, per-tenant graph store. No shared embedding pool, no shared retrieval cache. Independent third-party verification will follow once we begin a SOC 2 audit.
No training on customer data
Models are called via zero-retention APIs (Anthropic, OpenAI). Calibration loop runs per-tenant; signal never leaks across tenants. We do not fine-tune on your data.
Permission propagation, on every call
Native ACLs from Notion, Slack, Drive, GitHub flow into the map. The policy engine re-checks ACLs at retrieval time, stale permissions can’t leak.
Audit log is immutable
Every read, every write, every tool call. Writes are append-only with hash-chained records. Real-time export to your Splunk / Datadog / Elastic / S3 is on the Enterprise roadmap.
Encryption at rest + in transit
AES-256 at rest, TLS 1.3 in transit. KMS-backed keys. HSM-backed and customer-managed-key (BYOK) options planned for Enterprise.
Bring your own model key (BYOK)
BYOK Anthropic ships today on the admin page; paste your own key and every Claude call routes through it. AES-256-GCM encrypted at rest, decrypted only at request time. AWS Bedrock and Azure OpenAI are next.
Capability scopes, not god tokens
API tokens declare scopes at creation; the policy engine refuses anything beyond. There is no admin escape hatch in the codebase, every internal access path is audited and tied to a token with explicit scope claims.
Reversal pointers on writes
Every external write Pulse drafts (Slack DM, Linear ticket, calendar invite) is reversible for 5 minutes after execution; the source system’s delete endpoint retracts the artefact. After the window the audit-log row is permanent but the action stays reversible by hand.
SSO, SCIM, MFA
SAML 2.0 + OIDC for sign-in. SCIM for provisioning. MFA enforceable per-org. Session timeout configurable, IP allowlists supported.
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. Cross-region Postgres replication via Supabase, daily backups with point-in-time recovery. Failover-drill cadence will publish on this page once we’re past private-beta volume.
Incident transparency
Pulse is in private beta. 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, policy-engine capability proofs, 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.
Five 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. We use zero-retention API endpoints for Anthropic and OpenAI; both are contractually prohibited from logging or training on the inputs we send. Our calibration loop runs entirely inside Pulse and is per-tenant.
Can the founders read our data?
There is no admin tool that bypasses the policy engine. Both founders' access to production goes through the same audited paths as any API token. For incident response we may use a customer-signed break-glass token; every action with that token is recorded in your audit log and surfaced in-product.
What happens when we leave?
Export your map graph as JSON-LD or Parquet via the lifecycle export endpoint. Your tenant index and graph are deleted within 30 days; you receive a deletion certificate. 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).
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.