Last updated: August 31, 2026. Every third-party service the platform uses, what data flows to it, and how long that data is kept.
Where the platform runs and where your workspace data lives.
Data flow: Account profile (email, name, optional Telegram chat ID), canary identities, monitored email addresses, threat and tripwire events, subscription and billing records, privacy-request tokens, and authentication credentials.
Retention: Stored until account deletion. Threat events follow the account retention window (default 365 days).
Data flow: Outbound alert emails to your address; inbound email sent to tripwire canary addresses (attacker contact) is received via SES and stored in S3 for processing.
Retention: Email delivery is transient; inbound tripwire messages are processed into trigger events.
Data flow: Standard web-request metadata (IP address, user agent) processed by the hosting layer.
Retention: Subject to the hosting provider's standard request-log handling.
Billing runs through PayPal. Prompts and documents you submit for inspection are processed by an inference provider.
Data flow: Subscription identifiers, plan, and billing event data (amount, currency, status). Card details are entered on PayPal, never on CanaryVaults; full card numbers are not stored by CanaryVaults.
Retention: Billing records are kept until account deletion. Deleting your account also cancels any active PayPal subscription.
Data flow: The prompts and document text you submit to those product surfaces are sent to the Groq API to produce the inspection or analysis result.
Retention: Used for inference; results are stored in your workspace, not by reference to the provider.
These services see attacker IP addresses captured by tripwires and honeypots — never your account data.
Data flow: Attacker IP addresses only. No account data.
Retention: Lookup results are cached for about 15 minutes.
Data flow: Attacker IP addresses only. No account data.
Retention: Lookup results are cached for about 15 minutes.
Data flow: Attacker IP addresses only. No account data, no API key required by this service.
Retention: Lookup results are cached for about 15 minutes.
Data flow: Attacker IP addresses only. No account data.
Retention: Lookup results are cached for about 15 minutes.
Data flow: The monitored email addresses you add are queried against breach data.
Retention: Findings are stored as breach events in your workspace.
Optional channels you enable, plus operational error monitoring.
Data flow: Your chat ID and the content of alerts you have routed to Telegram.
Retention: Messages persist in your Telegram chat under Telegram's terms. Unlink the chat in settings to stop delivery.
Data flow: Error and stack-trace data, sent under four redaction settings applied at SDK initialisation. send_default_pii is disabled, so the SDK attaches no user id, IP address or cookies. include_local_variables is disabled, so captured stack frames carry no local variables — this is what keeps prompt and document text out of an error report. max_request_body_size is set to never, so request bodies are not captured at all. And a before_send hook redacts every email address anywhere in the outgoing event, keeping only addresses at the platform's own domain, which are needed to tell one email-delivery failure from another; if that redaction ever fails, the event is dropped rather than sent.
Retention: Subject to the configured Sentry project retention.
One product mechanism intentionally places data in a public location today, and one more would if it were enabled. Both are listed here because anything published this way cannot be recalled.
On-chain proof anchoring is not enabled on this deployment. No content hash, transaction, or any other data has been written to Base or to any other public blockchain. The capability exists in the codebase but is inert. If it is ever switched on, it would write content hashes and transaction references to a public network where they are permanent and cannot be deleted; raw document content would still never be placed on-chain. This page is updated before anchoring is enabled, not after.
The canary seeding pipeline plants synthetic decoy identities in public locations so attacker pickup can be detected. Only fabricated decoy data is seeded. Real customer content is never posted to these surfaces.
How to read the entries above.
