Security and isolation
Connect runs one application over many workspaces, so the boundary between them is the thing that matters most. It is enforced three separate times — at the edge, in the object layer, and inside the database — because any one of them can be undone by a single careless line, and three independent mechanisms do not fail to the same mistake.
What this section covers#
- Workspace isolation
- The three layers, what each catches that the others do not, and why the count is three rather than one good one.
- Multi-tenancy in Connect
- What is genuinely shared between workspaces, what never is, and where the line is drawn in the data model.
- Row-level security
- The database's own filter: what it protects against that application code structurally cannot.
- The customer facade
- The closed-by-default surface a customer session is served through, and the shape of its refusal.
- Authorisation
- Who may call what, how a refusal is worded, and why reaching across workspaces has to be awkward.
- How provider credentials are stored
- Sealing on save, never echoing a value back, and the masked stand-in a screen shows instead.
Number and mailbox ownership, webhook verification, audit access, what is public against what is private, and retention have their own pages in this section as well. Each answers one question rather than restating the boundary.
The one idea underneath all of it#
Isolation used to rest on a single list of permitted addresses. That is one line of defence, in one function, protecting every business's data — and it only works while the operator's surface and the customer's surface are different addresses. The moment they become the same service, which is the point of running one engine for everybody, a list of addresses stops meaning very much.
So the boundary was made structural instead. The active workspace comes from the authenticated session and from nowhere a request can influence; reads are filtered automatically rather than at each call site; inserts are stamped so a record cannot be created into somebody else's workspace; and the database applies its own filter underneath all of that. The default is safe and the exception is loud — reaching across workspaces is deliberately awkward, has to state a reason, and reads as unusual in a change.
What is recorded#
- Every decision Connect makes and every action a person approves or rejects goes to the decision log, with the rule behind it and the person who acted.
- Platform-level events are held outside any single workspace on purpose: one action touching three workspaces writes three rows, and an auditor has to be able to see all three.
- Refusals are recorded as well as successes. A quiet period explained by refusals in the log is a very different thing from an unexplained one.
- Usage is recorded per workspace per day, with the limit that applied at the time.
Reviewing all of that is Audit access and The decision log.
What this section will not tell you#
These pages describe the shape of each protection and the reason it exists separately. They deliberately do not publish an internal route map, a way to probe any of it, or where a credential lives. That is not coyness about a weakness — it is the ordinary judgement that a public manual explains a design without handing anyone a checklist to test it against.
Nor does anything here claim a certification. No page in this corpus asserts one, and any page that appeared to would be wrong. The only health address the application publishes is /api/health; there is no other, and the application's own generated API description pages are closed.
Everything in this section#
12 pages, each with its own status and the date it was last checked against the running system.
| Page | What it covers |
|---|---|
| Authorisation | Five different questions get called permission. The order they are asked in, which one produced your refusal, and how each one is worded. |
| How provider credentials are stored | Provider credentials are sealed as they are saved and never shown again. What a screen displays instead, and why the database password lives in no file. |
| Multi-tenancy in Connect | One application serves every business. What is genuinely common, what belongs to exactly one workspace, and where the data model draws that line. |
| Proving a mailbox belongs to a workspace | The scoped lookup that replaced a bare fetch on four mailbox routes, what it prevents, and the single webhook still allowed to resolve differently. |
| Proving a phone number belongs to a workspace | How Connect proves a phone line really belongs to the workspace being served, and the class of defect that check exists to prevent. |
| Public and authenticated surfaces | Which Connect surfaces answer without a session, which require one, and which are deliberately closed — with the rule that decides where a new surface belongs. |
| Row-level security | The database applies its own workspace filter beneath the application. What that catches which application code structurally cannot, and what it refuses to write. |
| The customer facade | A customer session is served through a closed surface: what is not explicitly permitted is refused, and the refusal says so in plain words. |
| Verifying an inbound webhook | What an inbound provider callback has to prove before Connect acts on it: origin, freshness, single use and a known route, plus one named exception. |
| What is kept and for how long | How long each class of record survives in Connect, what deleting something actually does, and the two classes that are deliberately kept longest. |
| Who can read the audit trail | Who can read the record of what Connect decided and did: the two doors onto one trail, what each shows, and what the trail deliberately does not hold. |
| Workspace isolation | The boundary between two businesses is enforced three separate times. What each layer catches, and why one careful layer was not judged enough. |
Questions#
Where do I report something that looks like an isolation problem?
Tell JBRH directly, with what you saw and roughly when, and stop using the screen in question. Records visible outside their workspace would have to defeat three independent mechanisms, so a report of one is taken seriously rather than triaged.
Does Connect hold a security certification?
No such claim is made anywhere in this documentation, and none should be inferred from it. What these pages describe is how the system is built and what it records — which is a different question from an external attestation.
Is there a status or health address I can watch?
/api/health is the only one the application publishes. Addresses along the lines of /healthz or /readyz do not exist here, and the application's own generated API description and its interactive pages are closed and stay closed.