Security claims and validation roadmap

This page defines what Claire may say publicly about security, and what evidence is required before stronger statements are published. It exists because security copy is the easiest thing in a product to overstate and the hardest to walk back.

Claims we can make today#

Claire requires authenticated account access for private application routes.
The production API uses security headers, an origin allowlist, and separate rate limits for authentication and AI endpoints.
Claire Cloud synchronizes normalized message data to provide the unified inbox, search, and AI features.
Connected networks still process original messages under their own security models. When an AI feature is invoked, selected context may be sent to the configured AI provider.
Self-hosting puts the existing stack on infrastructure the user controls — which is not equivalent to an offline or local-only guarantee.

Claims we must not make today#

Mautrix supports optional end-to-bridge encryption, but it requires explicit bridge configuration and testing. It is not a blanket property of any application that happens to use mautrix. See the mautrix encryption guide.

Gate: end-to-end encryption#

The full research boundary, including the hosted-bridge limitation and future local connector requirements, lives in the end-to-end encryption research document.

Enable and enforce bridge encryption in production
Test the full matrix of behaviour
Encrypted send, receive, media, device verification, recovery, and bridge restart — for every named connector.
Publish the precise scope
Which devices, networks, bridges, and metadata are and are not covered.
Complete an independent implementation and threat-model review

Gate: private desktop-only mode#

Prove containment with outbound-network tests
Messages, media, indexes, embeddings, logs, notification bodies, and credentials must be shown unable to reach Claire services.
Enforce local storage, local search, and local or disabled AI
With telemetry disabled by enforced configuration, not by default setting.
Verify offline export, deletion, recovery, sleep and restart, and the limits of mobile access
Review production binaries, not just development configuration

Gate: bring your own AI provider key#

Store cloud keys in an encrypted secret store, local keys in the OS credential store
Keep keys out of every incidental surface
React state, analytics, application logs, AsyncStorage, ordinary database rows, crash reports, and URL parameters.
Test redaction, rotation, revocation, and disconnect cleanup

Copy review checklist#

Use “end-to-end encrypted” only for a tested and explicitly scoped flow.
Describe the AI data boundary beside every AI-related plan or feature.
State whether a feature is current, planned, or in development.
Do not imply that self-hosted means offline, private desktop-only, or free of external network processing.
Re-review security copy with every material change to bridge, hosting, AI, analytics, credential, or telemetry behaviour.