Context holds credentials to storage buckets other people own, and mediates access to their private notes. We take that seriously, and we'd rather hear about a problem from you than from a user.

Please do not open a public issue for a security problem.

Use GitHub's private vulnerability reporting, or email security@supa.media.

Please include what you found, how to reproduce it, and what an attacker could actually do with it. If you have a proof of concept, even a rough one, it helps enormously.

We'll acknowledge your report within 3 business days and keep you updated as we work through it. If you'd like credit in the advisory, say so and we'll include you.

Please don't run tests against other people's data or against production infrastructure you don't own. Self-host a gateway — it's designed to be easy — and attack that.

Roughly in order of how much it would ruin our day:

• Cross-tenant access. Any path by which one workspace can read, write, list, or infer the existence of another workspace's notes, storage binding, grants, or audit events.
• Credential exposure. Any way to recover a stored storage-provider secret, or to get one into a log, an error message, a URL, an audit record, or a customer's own bucket.
• Privacy-tier bypass. Any way a team-scoped connection can read, list, search, or infer the filename of a private note. Inference counts — a team caller learning that a private note exists is a bug, not a near-miss.
• Authorization bypass. Acting outside a granted scope or role; a revoked grant that still works; one AI client's grant affecting another's.
• OAuth flaws. Authorization code interception, PKCE bypass, redirect URI validation gaps, token substitution, confused-deputy attacks through the gateway.
• Path traversal. Escaping a workspace's bucket or configured root prefix.
• Ingestion abuse. Forging an inbound capture into someone else's context, or bypassing sender/quota policy.

• Findings against a deployment you control, where the impact is limited to your own data.
• Missing hardening headers on the marketing site.
• Rate limiting on unauthenticated endpoints that expose nothing.
• Reports generated by a scanner with no analysis of exploitability.

These are properties we intend to hold, and the things worth testing us on:

1. The control plane never stores note content. It holds accounts, workspaces, storage bindings, grants, and audit metadata. Notes live only in the customer's bucket.
2. Storage secrets are encrypted at rest and decryptable only by internal server code paths — never returned by any client-callable function.
3. Tenancy is bucket-level. A workspace's credentials reach exactly one bucket. There is no shared bucket to escape from.
4. Visibility is enforced server-side before content is returned, never by frontmatter in the file and never by the client.
5. team never means public. There is no anonymous or internet-facing tier.
6. Every AI client gets its own revocable grant. Revoking one leaves the others working.
7. A customer can revoke us unilaterally at their storage provider, without asking us, and keep a complete working context.

The gateway in apps/mcp is dependency-free and deployable on your own Cloudflare account against your own bucket. If you don't want to trust our control plane, don't — that's the point of the architecture, and we'd consider it a bug if self-hosting stopped working.