Where your client's unpublished work is kept, and who can reach it.

Marketing content that has not been published yet, belonging to companies that are not our customers. An agency's client is frequently under an NDA with that agency, and the material in Canopy — an unannounced product, a campaign with a launch date, a price change — is exactly the material that agreement exists to protect.

We are describing the sensitivity accurately because everything below only matters in proportion to it.

Separation between agencies is enforced in the database, not in the application. Every table carries a policy that resolves which organisation a row belongs to and refuses rows outside the one asking. That check runs inside Postgres, so it holds even if the application layer is bypassed entirely — a bug in our code cannot open a door the database keeps shut.

No agency can reach another's data, and no account inside the product grants that reach — not an agency owner, not a workspace administrator. An earlier version of Canopy had a global administrator role and removing it was the single largest piece of work in making the product multi-tenant. It has not come back.

Canopy's own operator is the exception, and it is a real one rather than a technicality: there is a support console that can open an agency's workspaces. What it can do, what it cannot, and what happens when it is used are described in the next clause, because a boundary is only meaningful if its exceptions are stated in the same breath.

Visuals are stored in private object storage. There is no public URL for a client's unpublished asset — not an obscure one, not a hard-to-guess one. Access is granted through short-lived signed links, issued per viewer and only after the same organisation check as everything else.

Canopy is one person, and that person can open your workspaces through a support console. Pretending otherwise would be easy and false: the credential that applies migrations and restores backups is not bound by the policies described above, and never can be.

So the guarantee is not that it cannot happen. It is that it cannot happen quietly. Every time that console opens an agency's content it writes a row — who looked, when, and the reason given — to a log that agency reads from its own settings page. The write happens before anything is displayed, and if it fails, nothing is displayed. There is no insert, update or delete policy on that table for any signed-in user, so the record cannot be forged, edited, or removed afterwards.

What the console shows is deliberately narrower than what it could: post titles, statuses, dates and counts — enough to answer “is this working”. Captions and files are not on that screen. Being able to read everything is not a reason to display it.

Permission for it is given once, when you accept the terms at signup, and covers troubleshooting — diagnosing or fixing a problem — and nothing else. It is not a licence to browse, and the terms say so in those words.

You can withdraw that permission at any time from Settings → Organization. The console then shows nothing about your agency — not a workspace name, not a post title — until someone at your agency approves a specific request naming what is being looked into. Those approvals are time-limited, expire on their own, and can be ended early from the same page.

We would rather state the trade than dress it up. The guarantee here is not that we cannot look. It is that we cannot look without you being able to see that we did, and that you can take the permission away without asking anyone. Agencies who signed up before these terms have the permission on by default and their settings page says exactly that, rather than claiming an agreement that never happened.

The limit worth stating: this governs the console, which is what a person actually uses. It does not remove the database credential that applies migrations and restores backups, because nothing can — a system that could lock its operator out of the database could not be repaired. What that credential cannot do is open your content in a product surface without leaving a record you can read.

An automated test suite builds two complete agencies — each with staff, client contacts, workspaces, posts, captions, files and comments — then signs in as each of their users in turn and asserts that neither can read or write a single row belonging to the other. It also checks the reverse: that isolation has not been achieved by accidentally hiding an agency's own data from itself, which is the failure that looks like success.

Over a hundred assertions, run on every change, against a database rebuilt from an empty schema so the whole migration history is exercised rather than the current state of one server. A change that breaks isolation fails the build rather than reaching you.

The reason for the second half of that sentence: assertions that exist but never run are not a guarantee. This suite is the acceptance gate, and it is only a gate because it is wired into the build.

A page that only lists strengths is marketing. These are the limits, stated plainly, so you can decide rather than discover.

• No SOC 2

  Not today. A readiness assessment is planned; a completed audit is not something we can promise a date for, and inventing one would be the first dishonest thing on this page.

• One region

  Data is stored in a single region. If you need EU residency specifically, ask before you commit — the answer today is that we cannot guarantee it.

• No single sign-on

  There is no SAML or SCIM. Accounts are email and password, with invitations bound to the address they were sent to.

• No custom data processing agreement

  A standard DPA is being prepared alongside the terms and is not ready yet. We are not in a position to negotiate bespoke terms either, and an agency that needs to is probably larger than Canopy is built for.