ProductManifestoPricingEnterprise
Try free
Security
Effective October 19, 2026

Capable — Security Overview

Effective date: 2026-10-19

Updated 2026-10-19: clarified Unipile’s broader synchronized-data scope and the existing owner-scoped local export, targeted-erasure and replay controls, including their limits for provider-held data and separately published CRM notes.

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, Supabase-managed authentication and session storage, and file storage run in the European Union (Supabase eu-west-3, Paris), and application hosting is pinned to the EU. WorkOS processes enterprise single sign-on and directory-sync data in the United States, including primary and backup hosting, for organisations that enable those features. 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; the recorder does not start unless its region is explicitly configured. 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, including uploaded files, is encrypted at rest by our managed data platform.
  • Secrets: connected Google and Microsoft OAuth refresh tokens and IMAP mailbox passwords are encrypted with authenticated encryption (AES-256-GCM), using a separate key per provider; they are never written to logs and never returned to the browser. A connected LinkedIn account's session is held by the provider (Unipile); Capable stores a provider account identifier, not the LinkedIn credential. Application secrets are held in our hosting provider's secret store. Inbound capture API keys are stored only as hashes.

Access control and authentication

  • Authentication. Sign-in is via Google Sign-In, Sign in with Microsoft (Microsoft Entra ID), enterprise single sign-on (SAML / OIDC through WorkOS) where a customer's organisation enables it, or a one-time code emailed to an address that already belongs to a user or holds a pending workspace invite. There is no password authentication, and email-code sign-in never creates an account by itself.
  • 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. Enterprise customers can provision and de-provision users through directory sync (SCIM).
  • Tenant isolation — row-level security isolates each Workspace's data; backend service credentials are restricted to server-side use.
  • Uploaded files live in a private storage bucket and are downloaded only through short-lived signed links.

Auditing and governance

  • Audit logs from day one for security-relevant and write operations.
  • A single governance enforcement chokepoint through which write operations pass — whether they come from the web app, a connected AI assistant, the browser extension, or the inbound capture API — supporting policy enforcement and approval workflows.
  • Per-Workspace and per-user rate limiting to protect availability.

Secure development and vulnerability management

  • Vulnerability management. We run automated dependency-vulnerability scanning in our CI pipeline on every change, gated by a severity-based policy (a build fails on un-remediated high- or critical-severity advisories) with a reviewed, dated exception list for advisories that have no safe fix. Vulnerability reports from researchers are handled through the channel below.
  • Secure development / CI security gates. Every change runs automated linting, type-checking, and tests, the dependency-audit gate, and verified-secret scanning (scanning the codebase and its history for live credentials) before it can be merged.

Resilience

  • Backups with point-in-time recovery (PITR).
  • A documented disaster-recovery plan.
  • Soft deletion across the Services: a deleted record leaves active use and stays recoverable until it is purged with the related workspace or account data, on a deletion request, or by a scheduled purge once we set one. Uploaded files are the exception: deleting an attachment removes the stored file immediately. Meeting recordings are the other exception: video and audio are deleted six months after the call, while the transcript remains until the related activity is deleted.
  • Read-only, never deleted. When a trial ends without a subscription, or a subscription lapses, the Workspace becomes read-only: data stays visible and exportable, and nothing is deleted.

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:

  • Mail: content stored securely and purged on deletion. Capable reads email header metadata (From/To/Cc/Date/Subject) and stores the readable content of emails from a connected Google, Microsoft, or IMAP mailbox so customers can view and search their correspondence in the app. Stored content is encrypted at rest and access-controlled to the workspace, is returned to a connected AI assistant only on an authorized request (see the Privacy Policy, Section 4.4), and is purged when the related activity is deleted (and on account-data deletion). Drafts, spam, and trashed mail are never imported.
  • Calendar: metadata plus the meeting description (the agenda). We read event titles, attendees, and times, and scan only for a join link. We also read and store the event description (the meeting agenda) on the corresponding activity, scrubbed of obvious join credentials (passcodes/PINs) before storage. Stored agendas are encrypted at rest, access-controlled to the workspace, returned to connected AI assistants only on authorized requests, and purged when the related activity is deleted. We never persist calendar event locations or attachments.
  • Meeting recorder: on for customer calls, with notice. The recorder auto-joins only meetings with at least one attendee from outside the workspace's organisation; internal-only meetings are never recorded automatically. The bot is named, announces in the meeting chat that the call is being recorded, and one hour before the meeting every external attendee receives an email notice with a one-click Don't record this meeting option. An opt-out is stored so it sticks. A workspace admin can switch the recorder, and the notices, off. Video and audio are deleted six months after the call; the transcript remains until the related activity is deleted.
  • Uploaded files are stored and displayed, not read by AI. Files attached to records are kept for humans to download. No connected assistant or automated process reads their contents.
  • Product-event capture is write-only. A customer's own product can send sign-up and usage events through a send-only API key. Each event is reduced to a strict, bounded set of fields before it is stored; unknown fields are dropped, receipt bodies are cleared once processed, and receipt records are purged after 180 days. The key can never read data.
  • LinkedIn conversations are private to their owner and explicit recipients. Imported conversations stay outside shared timelines, global search and caches. Admins and managers have no private-message override. An owner may separately review and confirm saving one message as a shared CRM note; that note follows ordinary CRM permissions and must be managed separately from private history. Provider-side account synchronization is broader than Capable's selected message imports: Unipile states it stores all synchronized V1 messages, chats, attendees and attachments until connected-account deletion, as described in the Privacy Policy, Section 4.7. Capable provides an authenticated owner-scoped workflow for local private-data export and reviewed targeted erasure, with local replay protections. This does not establish deletion of original LinkedIn messages, separately published CRM notes or every vendor-held log and backup copy.
  • No per-individual enrichment. Company enrichment is domain-level only (public firmographic facts); we do not enrich individual contacts.
  • User-connected AI assistants. Capable does not operate a server-side large language model or make server-side model inference requests on your behalf. Authorized Users can connect supported AI assistants through MCP (Model Context Protocol), including Anthropic's Claude and OpenAI's ChatGPT and Codex, using their own provider accounts. On an authorized request, Capable returns the requested, permitted Customer Data to the connected assistant and can perform permitted CRM actions. Data returned through MCP is disclosed to and processed by the connected assistant provider under the agreement, account type, and settings applicable to the Authorized User or their organisation. Users and workspace administrators control these connections and can revoke access. 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.