How AnchorGrid handles your data.
An honest read on the architecture: where bytes flow, what's encrypted, what we keep, and how to report a vulnerability.
Built so the wrong server can't see the wrong byte.
Session media goes peer-to-peer when it can. When it can't, it routes through a TURN relay that holds the encrypted bytes for milliseconds and forgets them.
Every media flow rides DTLS 1.3 + AES-GCM. Encryption is the WebRTC default; TURN relays see ciphertext only.
Subdomain per workspace. Database reads are scoped at the middleware layer; there is no code path that returns one workspace's data to another.
AnchorGrid staff cannot view your workspace without a grant you created. Grants are time-bounded and revocable from any notification email.
Every join, leave, and admin action lands in the workspace audit log with role-aware visibility.
How a session moves.
Reporting a vulnerability.
The short version
AnchorGrid takes security seriously. If you've found a vulnerability, email alex.cthompson97@gmail.com with a description and reproduction steps. We'll acknowledge within 2 business days and keep you updated until it's resolved. We won't pursue legal action against good-faith researchers who follow this policy.
Scope
In scope
-
anchorgrid.ioand all subdomains under*.anchorgrid.io -
The AnchorGrid iOS app (bundle
com.anchorgrid.app) -
API endpoints under
api.anchorgrid.io -
The WebSocket signaling endpoint
/api/signal/:code - The coturn TURN relay reachable at our production TURN hostname
Out of scope
- Findings dependent on the user installing malware, granting attacker physical access, or running an unsupported OS version
- Social engineering of AnchorGrid staff or customers
- Volumetric or denial-of-service testing against production
- Missing security headers without a demonstrated exploit (please show the impact)
- Self-XSS or other attacks that require the victim to paste attacker-supplied code into devtools
- Vulnerabilities in third-party services we use (Railway, Fly, Cloudflare, Resend, Microsoft Entra). Please report those upstream
- Issues already publicly disclosed
What you can expect
| Milestone | Target |
|---|---|
| Acknowledgment | 2 business days |
| Triage | 5 business days |
| Critical fix | Drop-everything · days, not months |
| High fix | Within 2 weeks |
| Medium fix | Within 30 days |
| Low fix | Triaged into the backlog |
| Public credit | If you want it; we don't pay bounties yet |
Safe harbor
We won't pursue civil or criminal action against you, or ask law enforcement to investigate, for good-faith security research that:
- Stays within the scope above
- Avoids accessing other users' data beyond what's necessary to demonstrate the vulnerability
- Doesn't destroy or corrupt data
- Doesn't degrade service for other users
- Reports the issue to us privately before making it public
- Gives us reasonable time to fix the issue before disclosing it
Disclosure expectations
Hold disclosure until the fix is out. We aim to fix critical and high severity issues in days, not months. If you've found something serious, expect us to drop other work and patch it. Once a fix has shipped and customers have had a reasonable window to update, you're free to write about it. If a fix is taking longer than expected we'll tell you why and we'll coordinate timing with you, rather than pointing at a calendar.
If you find evidence of active exploitation, lead with that. We'll prioritise it accordingly.
Acknowledgments
We'll list researchers here once the first one comes in. None yet.