# Privacy inside the product

Everything a workspace supplies belongs to that workspace and is filtered by it three separate times. What reaches an AI model on any one task is a budgeted extract rather than the whole record. Memories, files and records can be corrected or removed by a person, and a small set of things is kept deliberately, because removing them would cause the harm they exist to prevent.

- **Status:** Available
- **Audience:** both
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/product/privacy-in-the-product/

## What this page covers, and where the legal statements are

This is the operational half: what the software does with your material while it runs. The legal half lives in two places and is not repeated here. The [Privacy Centre](/privacy) sets out the roles — where JBRH decides and where your organisation decides — the Gmail permission and what it is used for, the technology providers observed in production, retention, and how to make a request. The [Trust Centre](/trust) carries the retention table, the security practices, the grievance route and the plain statement that no certification is held.

> **Careful** Nothing on this page overrides either of those. Where a sentence here and a sentence there appear to disagree, the notice is the statement of record and this page is the one to correct.

## Where your material actually sits

In one workspace, and only one. Nearly every record carries its workspace identifier and is filtered by it automatically, and three independent mechanisms enforce that: an allowlist decides which paths a customer session may call at all, the object layer filters every query by workspace, and the database itself refuses rows belonging to another workspace. Any one of the three can be got wrong by a single line of code, which is why there are three.

**Mailbox credentials** — Encrypted at rest, with the key held separately from the database.
**Session tokens** — Stored only as digests, never in a readable form.
**Machine credentials** — Integration keys are scoped to one workspace and an explicit permission set, stored as digests, compared in constant time, revocable and rate limited.
**A row with no workspace stamp** — Matches no scope and no database policy, so it is invisible rather than shared. That failure mode has happened here, and it is a defect rather than a leak.

## What reaches a model

An extract, assembled for one task and bounded by budget. Grounding material is capped at roughly two thousand characters and four facts; what Connect remembers contributes about seven hundred characters; the block describing who is being spoken to is about six hundred. A person's voice profile is held under about two and a half thousand characters. Those limits exist because a longer prompt measurably delays the first token on a live call — but the privacy consequence is the useful one: the whole mailbox is never handed over, because it would not fit and would not help.

Before any model sees an incoming message, it is screened for instructions aimed at the automation rather than at a person. A message carrying one is routed to a human instead of being acted on. That is a security control first and a privacy control second, since the usual goal of such an instruction is to make the system reveal or send something it should not.

> **Note** What a model provider does with what it receives is a question about that provider, not about Connect. The [Privacy Centre](/privacy) names the providers observed in the production configuration and states what is and is not claimed about each. This page does not add to that.

## What a person can remove or correct

- **A memory.** What Connect knows is readable at all four tiers — workspace, channel, endpoint and one person — and any of it can be corrected, superseded or forgotten. A correction changes behaviour, which is the point of showing it rather than hiding it.
- **A record.** People, companies, conversations, prospects, deals and cases can be edited or removed through the service that owns them, so the rules that apply when Connect writes a row apply when you delete one.
- **A file.** Documents are versioned with provenance; a change produces a new version rather than overwriting the last.
- **A knowledge source.** Removing the source removes the grounding it provided, and Connect refuses more questions as a result — which is the designed consequence rather than a fault.
- **A connection.** Disconnecting a mailbox revokes the token and stops further access. It is a separate act from deleting the records already synchronised into the workspace, and the [Privacy Centre](/privacy) is explicit about that distinction.

## What is kept on purpose

Three categories resist deletion for reasons worth stating, because each looks like an inconsistency until you see why.

| Kept | Why removing it would be worse |
|---|---|
| A suppression or do-not-contact entry | It exists because somebody asked not to be contacted. Deleting it would let a later campaign contact them again, so a minimal record outlives the data it relates to. |
| The decision log | It is the evidence that a rule was followed. It records refusals as well as actions, which is what makes an unexpected outcome explainable months later. |
| Financial records | A record of money changing hands is kept for tax and company-law purposes and is not used for anything else afterwards. |

Everything else has a lifecycle set out in the Trust Centre's retention table rather than a single blanket figure, because one figure would either destroy records the business is required to hold or keep personal content far longer than promised.

## The operator is not an exception

JBRH runs its own business in a workspace of its own, on the same code. The three isolation layers have no operator bypass, so the operator does not read a customer's conversations through the product. Where JBRH must act on a request about workspace content — a deletion, an export, an objection — the route and the verification are the ones in the Trust Centre, not a back door in the application.

## Questions

### Does Connect read my whole mailbox?

It syncs the mail in the account you connected and writes canonical records from it, which is what makes triage and a single relationship history possible. What reaches a model on any one task is a small budgeted extract, not the mailbox.

### If I forget something, does Connect stop using it?

Yes. Memory is what shapes a reply, so removing a memory changes the next reply. That is why memory is shown at every tier and is editable, rather than being an opaque store you have to trust.

### How do I get a copy of what is held, or have it deleted?

Through the request route in the [Trust Centre](/trust), which covers access, correction, deletion, export and objection, and states the acknowledgement and response timelines. Identity is verified first, because acting on an unverified deletion request would itself be a breach.

## Related

- [The data you give Connect](https://connectbyjbrh.com/docs/product/data-you-give-connect/)
- [What is kept and for how long](https://connectbyjbrh.com/docs/security/data-retention/)
- [Forgetting something](https://connectbyjbrh.com/docs/memory/deleting/)
- [Workspace isolation](https://connectbyjbrh.com/docs/security/workspace-isolation/)
- [Instructions hidden in content](https://connectbyjbrh.com/docs/knowledge/prompt-injection/)
- [Export your data](https://connectbyjbrh.com/docs/how-to/export-your-data/)

## What this page is based on

- `webapp/privacy/index.html` — roles, Gmail permission, retention, requests
- `webapp/trust/index.html` — retention table, security practices, data rights
- `docs-source/facts.py` MEASURED — the context budgets
- AGENTS.md §3 and §4 — the three isolation layers and the workspace stamp