Security

Written for a reviewer, not a marketer.

Everything stated as fact on this page is implemented and tested today. Everything on the roadmap says so in the same sentence, in the same size type. If you are doing a vendor review, this page is meant to answer you without a call.

Status at a glance
Credentials and webhook secrets encrypted at rest; API keys stored only as hashesRed-team and cross-audience leak suites running in CIDeny-by-default egress gatewayDPA, processor register and cookie policy — prepared for verification and founder approvalSelf-serve data export, workspace or contact — built, not yet switched onSOC 2 — not started

Filled dot: in place and tested. Hollow dot: on the roadmap, not yet achieved.

01 — Capture and redaction

The riskiest thing we do is take screenshots of your product.

So this is the control set we treat as load-bearing.

Masked at the sourceCapture records the label of a field — "Card number" — and never the value entered into it. This is an architectural property of the capture pipeline, not a setting an admin can switch off.
Four tiers of redactionManual blur; assisted Smart Blur with a durable decision log; enforced policy redaction that runs at ingest before any human sees the image; and custom regex or selector rules, which have no editing screen yet.
Enforced before human eyesOn Enterprise, policy redaction runs at ingest, not at render. An agent reviewing a capture sees the redacted derivative — there is no window in which the raw image is browsable.
Strict originals modeEnterprise workspaces can encrypt every screenshot original at rest and never serve it; once a redacted derivative exists, an admin can delete the original for good. There is no settings screen for it yet.
02 — Tenancy and access

Isolation enforced by the build, not by convention.

The failure mode we care most about is one tenant seeing another's data, or a customer-facing answer citing an internal runbook. Both are pipeline failures rather than review items.

Workspace scopingEvery tenant-scoped model carries a workspace scope. This is enforced at the model layer rather than remembered at each query site.
Policy coverage in CIEvery route requires an authorization policy, and the pipeline fails on any route without policy coverage. A new endpoint cannot ship unguarded by being forgotten.
Cross-tenant probesAutomated probes attempt cross-tenant access against the suite on every build. A regression in isolation breaks the build rather than surfacing as a support ticket.
Audience enforcement at retrievalEvery knowledge chunk is audience-tagged and every query carries an audience scope, so an internal runbook cannot be surfaced by a customer-facing answer even if someone links to it directly.
Roles, SSO and SCIMSeven built-in roles, from owner to viewer, resolved as permissions rather than role names; SAML SSO and SCIM provisioning on Enterprise require customer setup. Change logs exist; customer audit export awaits production activation and acceptance.
03 — AI safety

AI safety here means tests, not a paragraph about our values.

Prompt injection and cross-audience leakage are the two attacks that matter for a grounded support agent. Both are in the pipeline as adversarial suites.

Grounding is a policy, not a promptAnswers must cite retrieved sources. Ungrounded generation is refused rather than hedged — there is no mode in which the agent improvises and hopes.
The eval harness gates changesA golden set scores groundedness, refusal and escalation on every build, and a regression fails the build. It runs on recorded model responses, so it guards the grounding and handoff logic; a live-model run is not part of the gate yet.
Prompt-injection suite in CI"Ignore your previous instructions" and its many descendants are test cases that run on every build, not a class of surprise.
Cross-audience leak probesAdversarial retrieval attempts run in CI on every build, and a nightly job re-checks what is cleared for public. An internal document reachable from a public scope is a build failure.
Tool calls are permissionedEvery tool the agent can invoke carries a permission rule, argument constraints and an audit trail. Actions taken on a user’s behalf are logged individually.
Walkthrough execution is fenced"Do it for me" runs on verified domains only, never on payment or password pages, never into a field marked sensitive — and typed values come from a secure user prompt, never from the model.
04 — Infrastructure and secrets

Egress is deny-by-default, because we crawl and call out on your behalf.

Deny-by-default egressThe crawler, HTTP tools and webhooks run behind a dedicated gateway that blocks private and reserved address ranges and cloud metadata endpoints — independently of application code and of DNS resolution timing.
Secrets handlingPer-workspace integration credentials and webhook signing secrets are encrypted at rest with the application key (AES-256). API keys are stored only as hashes. Signed webhooks carry retries and redelivery.
Contract-first API surfaceAn OpenAPI 3.1 specification is the single source of truth for every HTTP payload; client types are generated from it and CI fails on drift between the spec and the code.
Data lifecycleConfigurable retention windows, and contact erasure that removes messages, attachments, call recordings and mined-conversation embeddings. Deleting content removes its vectors. Self-serve export is built but not yet switched on, and the privacy page lists subprocessor categories rather than named vendors.
Stack, for the reviewer who asks
ApplicationLaravel 13 / PHP 8.5, Vue 3 with TypeScript strict, Tailwind
DataPostgreSQL 18 with pgvector, Redis
RealtimeLaravel Reverb websockets
ClientsManifest V3 browser extension for Chrome and Edge (store listings coming soon); Tauri 2 desktop app and iOS, Android, Flutter and React Native SDKs — built, not yet released
IntegrationPublic REST API, OAuth app platform, signed webhooks; an MCP server you run yourself (npm release coming soon); Zapier and n8n coming soon
WidgetStatic CDN delivery, under 120KB, walkthrough runtime under 25KB
05 — Compliance and reliability

What we have, and what we do not have yet.

In place today
  • US business use only: patient-identifiable health information is prohibited across chat, capture, uploads, voice, knowledge, tools and integrations. No HIPAA service or BAA is offered.
  • Contact erasure and configurable retention windows, with deletion reaching embeddings
  • Role-based access control and change logs; customer-facing audit export awaits production activation and acceptance
  • Integration credentials and webhook signing secrets encrypted at rest (AES-256, application key); API keys stored only as hashes
  • Adversarial AI and cross-tenant isolation suites running in CI
On the roadmap — not yet achieved
  • A DPA, processor register and cookie policy are prepared for verification and founder approval. Publication and the operational evidence remain prerequisites; Cairn is not described as GDPR-ready.
  • Self-serve data export, for a whole workspace or a single contact — built and tested, not yet switched on in production.
  • SOC 2 — not started. This line will say so when an audit begins, and we will publish the report when there is one.
  • A contractual uptime SLA — the figures below are internal objectives only.

If a procurement checklist needs one of these today, we will tell you it is not available rather than describing it as "in flight" and hoping.

Reliability — internal service objectives, not a contractual SLA
API availability99.9%
Widget boot (static CDN)99.95%
Message delivery, p95< 500ms
Agent first token, p50< 1.5s

Published for transparency. These are the numbers we hold ourselves to internally; they are not a contractual commitment, and we will not present them as one until they are backed by a signed agreement and a track record.

Responsible disclosure

Found something? It reaches an engineer, not a queue.

Email the security address directly rather than using the contact form. We acknowledge within one business day, we will not threaten you, and we will credit you if you want the credit.

Disclosure details
What we askEmail the security address rather than the contact form, so it reaches an engineer directly.Give us a reproduction and a reasonable window before disclosing publicly.Do not test against another customer’s workspace — ask us for a sandbox and we will provide one.We acknowledge within one business day, and we will credit you publicly if you would like that.