Real-account early warning
This surface focuses on inboxes, recovery paths, and attacker contact against real identities. The control goal is to create believable tripwires without exposing the real account workflow.
Trust Center
Security and trust center
Last updated: October 7, 2026. Security design, incident handling, and disclosure paths across the full platform.
Multiple product surfaces, one security posture
Each module solves a different risk, but all of them aim for believable signals, clear alerts, and evidence you can act on.
Private-document AI leakage detection
This surface focuses on documents entering copilots, chatbots, and retrieval systems. The control goal is to catch answer leakage, preserve evidence, and reduce ambiguity during investigation.
Prompt injection prevention
This surface focuses on blocking instruction override, role hijacking, extraction attempts, and jailbreak patterns before they reach a live model.
Attacker trapping and fingerprinting
This surface focuses on public AI decoys that classify hostile probing, capture request telemetry, and escalate suspicious hits without revealing the trap.
Tamper-evident agent accountability
This surface focuses on tamper-evident audit trails for AI agents, with content hashes that make later tampering easy to detect.
Operating controls
How the platform reduces unnecessary exposure
- Synthetic or planted signals are separated from the real user-facing protection workflow wherever practical.
- Alerting is structured around clear trigger context so responders can tell what fired and why.
- Authenticated workspaces, account-scoped data, and controlled routing reduce cross-account exposure.
- Content-hash evidence is treated as an extension of, not a replacement for, operational logs.
Response model
How incidents and disclosures are handled
- Severity-based triage and user-facing alert states are used so incidents are easier to interpret.
- Security-sensitive reports can go directly to the security mailbox instead of general support.
- Support, privacy, and product surfaces are linked so users can move quickly between the correct trust documents.
Assurance roadmap
This is the direction of travel for external validation, hardening, and published trust updates.
- Independent testing and publishable trust updates as the platform matures.
- Clearer documentation of assurance milestones for teams evaluating operational risk.
- Ongoing hardening of the split between monitored identities, prompt defense, honeypots, and audit workflows.
Reporting a vulnerability
If you find a security problem in CanaryVaults, email security@canaryvaults.com. It reaches the person who can fix it.
What to send
- What the problem is, and where: the page, endpoint or feature.
- Steps to reproduce it, and what someone could do with it.
- How to reach you, and whether you want credit once it is fixed.
What is in scope
- www.canaryvaults.com, the API, and the signed-in console.
- Decoys are meant to be found. A honeypot that answers with convincing fake data, or a decoy address that looks real, is the product working. Tell us if a decoy exposes real data, a real system or another customer.
Please don't
- Access, change or delete data that is not yours, or keep more of it than you need to show the problem.
- Degrade the service: no denial of service, load testing or high-volume scanning.
- Social engineering, phishing or anything physical.
- Publish the details before the problem is fixed.
What you can expect
- Every report is read, and you get a reply from the security address.
- You hear when the problem is fixed, and you are credited in the changelog entry for the fix if you want to be.
- There is no paid bug bounty.
If you act in good faith and stay within this policy, we treat your research as authorized and will not take legal action against you over it.