Legal

Capable — Security Overview

Effective date: 2026-06-17

This overview summarises how Capable Agents AB ("Capable") protects Customer Data. It supports our Data Processing Agreement (see Annex II for the technical and organisational measures) and Privacy Policy.

We build to SOC 2 principles. We are not yet SOC 2 certified — we have implemented the controls so that an audit, when a customer requires one, is a matter of weeks rather than months.

Data residency

Our primary data store and authentication run in the European Union (Supabase eu-west-3, Paris), and application hosting is pinned to the EU. The meeting recorder (Recall.ai) is region-bound and is configured to the EU (eu-central-1, Frankfurt), with transcription (Deepgram) routed through Recall's EU deployment. Some sub-processors operate outside the EEA; for those we use the safeguards described in our Privacy Policy and DPA (EU SCCs, the UK Addendum, and the Swiss addendum). The current vendor list, with regions, is at legal/subprocessors.md.

Encryption

  • In transit: all traffic is encrypted over HTTPS/TLS.
  • At rest: Customer Data is encrypted at rest by our managed data platform.
  • Secrets: connected Google OAuth refresh tokens are encrypted with authenticated encryption (AES-256-GCM); application secrets are held in our hosting provider's secret store.

Access control and authentication

  • Single sign-on is required for access; in the current release end-user sign-in is via Google Sign-In.
  • Least privilege — access to production data is limited to personnel who need it.
  • Role-based access within each Workspace (admin, manager, member, viewer), with write permissions tiered by role.
  • Tenant isolation — row-level security isolates each Workspace's data; backend service credentials are restricted to server-side use.

Auditing and governance

  • Audit logs from day one for security-relevant and write operations.
  • A single governance enforcement chokepoint through which write operations pass, supporting policy enforcement and approval workflows.
  • Per-Workspace and per-user rate limiting to protect availability.

Resilience

  • Backups with point-in-time recovery (PITR).
  • A documented disaster-recovery plan.
  • Soft deletion across the Services, so deletions are recoverable within our normal cycles before being purged.

Incident response

We maintain a documented incident-response process, including triage, assessment, containment, and notification. In the event of a personal-data breach affecting Customer Data, we notify affected customers without undue delay, consistent with the DPA.

Vendor management

We maintain a vendor / sub-processor list with contractual data-protection obligations and change notification. See legal/subprocessors.md.

Privacy-by-design choices

Security and privacy are built into the product's architecture, not bolted on:

  • Gmail: metadata only. We request only the Gmail metadata scope and read header metadata (From/To/Cc/Date/Subject); we never read email bodies.
  • Calendar: metadata only. We read event titles, attendees, and times, and scan only for a join link; we never persist calendar descriptions, locations, or attachments.
  • No per-individual enrichment. Company enrichment is domain-level only (public firmographic facts); we do not enrich individual contacts.
  • No server-side LLM calls. We make no server-side calls to any large language model and do not transmit Customer Data to a model. AI assistance runs inside the Authorized User's own Claude session under that user's own Anthropic agreement (see the Privacy Policy, Section 4.4).
  • Cookieless analytics. In-product analytics is cookieless, metadata-minimized, and opt-out.
  • Error monitoring without PII. Our error monitoring is configured not to send personal data by default.

Reporting a vulnerability

Please report security issues to hello@capable.run. We support good-faith research as described in our Acceptable Use Policy (Section 5) and will work with you to validate and remediate.