Security

Canopy holds a map of how your systems fit together - so we treat that picture as sensitive by default. This page covers how Canopy protects your data, what we store, the controls you have, and how to use them well.

Overview

At a glance

• Private by default - maps, workspaces, and spend are scoped to your workspace and visible only to its members. Nothing is public unless you explicitly publish it.
• Workspace isolation - every row in the database is guarded by Postgres Row-Level Security (RLS), so one workspace can never read another's data, even through the API.
• Encrypted in transit and at rest - all traffic is served over HTTPS/TLS, and data is encrypted at rest by our managed Postgres provider.
• No payment data on our servers - billing runs through Stripe; Canopy never sees or stores your card details.
• Role-based access - Owner, Admin, Editor, and Viewer roles are assigned per workspace, so people only get the access they need.

How access works

Authentication is handled by Supabase Auth - you sign in with GitHub OAuth or email and password. Canopy hashes passwords and never stores them in plain text.

Once signed in, every read and write is checked twice:

1. Application layer - routes verify your session and the active workspace.
2. Database layer - RLS policies re-check ownership on every query, so a bug in the app can't expose another workspace's rows.

Public profiles and public maps are the one exception - they're served through a narrow, read-only path that exposes only the maps you've explicitly marked public. See Data and privacy for the details.

Data and privacy

What Canopy stores

Canopy stores the architecture you put on the canvas. It is not a secrets manager - see Best practices for what not to put in a map.

Isolation with Row-Level Security

Every table is protected by Postgres RLS. Policies tie each row to its owner or workspace, so queries can only ever return rows you're entitled to - the database enforces this independently of the application code.

Public reads (public profiles and published maps) go through dedicated, read-only database functions that return only explicitly-public data and never expose private maps, spend, or member details.

Encryption

• In transit - HTTPS/TLS on every request, including the API and MCP server.
• At rest - data is encrypted at rest by our managed Postgres provider.

Public vs private

• Maps are private by default. A map is only ever visible outside your workspace if you publish it or create a share link.
• Public maps are clearly marked and appear on your public profile at canopy.8starlabs.com/w/<handle>. Free public maps carry a small "Made with Canopy" badge.

Private share links Pro Coming soon

Private share links (coming soon) will let you share a single map with people outside the workspace without making it public. Until then, sharing is either workspace-only (members) or public.

Data ownership & deletion

Your data is yours. You can edit or delete maps at any time, and removing a workspace removes its maps. Exports (PNG, Markdown, CLAUDE.md, AGENTS.md) are plain files you own and control once downloaded.

Best practices

A few habits keep your architecture maps safe to share and safe to keep.

Never put secrets in a map

Canopy maps describe architecture, not credentials. Treat them like a diagram you might screenshot into a doc.

• Reference a secret by name (STRIPE_SECRET_KEY), never its value.
• Don't paste API keys, tokens, connection strings, or passwords into node labels, descriptions, or purpose fields.
• The same applies to exports - a CLAUDE.md or AGENTS.md lands in your repo, so keep it free of secrets too.

Grant the least access needed

Roles are assigned per workspace. Default to the smallest role that works:

• Viewer - read-only. Use this for stakeholders who just need to see the map.
• Editor - can edit maps but not invite or manage billing.
• Admin - full edit, and can invite Editors/Viewers into open (already-paid) seats. Can't change roles, remove members, or manage billing.
• Owner - full workspace control: member management, billing, Stripe payouts, paid-template listing, and verification requests.

Every member is a paid seat regardless of role, so invite people deliberately and remove members when they leave - removing a member frees their seat and revokes their access immediately. See Roles & permissions.

Share deliberately

• Keep maps workspace-only (private) unless they're genuinely meant to be public.
• Publish a map only when you intend it to be visible to anyone with the link; for internal review, keep it inside the workspace instead.
• Review your public profile before publishing - only maps you mark public appear there.
• Unpublish or rotate share links you no longer need.

Strengthen sign-in

• Sign in with GitHub so your Canopy access inherits GitHub's protections, including its MFA.
• Keep the email tied to your account secure - password reset links are sent there.

Protect API and MCP access

• The API and MCP server act with your workspace's permissions - treat any access token like a password.
• Store tokens in environment variables or a secrets manager, never in code or a map.
• Rotate tokens periodically and revoke any you suspect are exposed.

Report a vulnerability

We take security seriously and welcome reports from the community. If you've found a vulnerability in Canopy, please tell us before disclosing it publicly.

How to report

Email security@8starlabs.com with:

• A description of the issue and its potential impact.
• Steps to reproduce (a proof-of-concept helps).
• The affected URL, endpoint, or area of the product.

If you'd rather not email, use support and mark it as a security report.

Our commitment

• We'll acknowledge your report promptly and keep you informed as we work.
• We won't pursue legal action against good-faith research that respects user privacy, avoids data destruction, and doesn't degrade the service.
• We're happy to credit you once a fix has shipped, if you'd like.

Please avoid

• Accessing, modifying, or deleting data that isn't yours.
• Running automated scans that degrade the service for others.
• Social engineering, phishing, or physical attacks against our team or users.

Thank you for helping keep Canopy and its users safe.