# Reviewing account security, end to end

A review has four parts and each has one question. Sessions: is every live one yours? Provider grants: does each connection still hold consent you would give again today? Stored credentials: is anything here a copy of a secret somebody else rotates? The trail: can you still tell who decided what? Nothing in the review needs a support request to complete.

- **Status:** Available
- **Audience:** both
- **In the app:** #/account, #/integrations, #/autonomy-audit
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/workflows/account-security-review/

## The four questions

| Area | The question | A bad answer looks like |
|---|---|---|
| Sessions | Is every live session one of your devices? | A count higher than the machines you recognise, or a session you cannot place |
| Provider grants | Would you grant this consent again today? | A mailbox connected for a person who has left, or scopes wider than the work needs |
| Stored credentials | Is anything here a copy of a secret somebody else rotates? | A password pasted into configuration that a provider changes on its own schedule |
| The trail | Can you reconstruct who decided what, and when? | A gap where an action happened but no decision was recorded against it |

The order is deliberate. Sessions are the fastest to check and the most immediate risk; credentials are the slowest and the most likely to be wrong in a way nobody notices until a restart.

## Stage by stage

1. Trigger — a periodic review, a colleague leaving, a device lost, or an unexplained action somebody wants to account for.
2. User or external event — a person with workspace administration opens the account, integrations and decision-log screens. Nothing here is automatic.
3. Authentication and workspace resolution — every screen in the review answers for exactly one workspace: your own. There is no cross-workspace view, by design, and the operator gets no wider answer than a customer does.
4. Ingest or request — each screen asks for its own slice: sessions for your address, connections for this workspace, decisions for this workspace.
5. Canonical record — sessions live in the control plane beside identity and membership; connections and their sealed credentials are workspace-scoped rows; the decision log is workspace-scoped too.
6. Reasoning — none is applied to the review itself. Nothing here is summarised by a model, because a security answer that has been paraphrased is a security answer you have to verify again.
7. Knowledge, memory and rules — untouched by looking. Revoking a grant or ending a session changes access, not what Connect knows.
8. Autonomy and approval — a review can end with an autonomy change, and that is a separate, recorded decision rather than a side effect of reviewing.
9. Action through a provider — only when you revoke: a mailbox disconnect stops fetching immediately, and re-consent at the provider is the only way back.
10. Result — a shorter list of live sessions, a shorter list of grants, and a written note of anything you could not explain.
11. Relationship, timeline and memory — nothing is written to any relationship. A review is about the people using Connect, not the people it talks to.
12. Audit, usage and Needs You — every revocation is recorded, and an unexplained finding belongs in Needs You so it is not lost between two people.

## Sessions

Start here because it is the only part of the review that closes a door in one action. Every session for your address is listed; the one you are using is recognised by the stored hash of its token rather than the token itself, which is why the list can point at your current session without ever holding a usable credential.

- End other sessions if the count does not match your devices. Your own is deliberately kept.
- Remember that a session's expiry is fixed at creation and does not slide forward with use, so an old session can be live without anybody having touched it recently.
- On a shared machine, sign out rather than closing the tab — closing a tab leaves the row valid until it expires.

## Provider grants and stored credentials

Every connection a workspace holds — a mailbox over Google or Microsoft, a mail server over IMAP and SMTP, a messaging or telephony provider — is a grant somebody made once and nobody re-examines by default. Two failure modes matter more than the rest: consent that outlived its reason, and a credential that is a copy of a secret its owner rotates.

Credentials are sealed on save and never echoed back to a screen, so a review is about *what exists*, not about reading values. If you cannot tell what a connection is for, that is itself the finding — remove it and reconnect deliberately, rather than leaving an unexplained grant in place because removing it might break something.

> **Careful** A copied secret is the quiet one. A password stored in a second place keeps working until the system that owns it rotates the original, and then fails at the next restart rather than at the moment of the change — which is why the failure so often looks like a bad deployment. Prefer a connection that reads the live secret over a connection that holds a copy of it.

## The trail, and what you are allowed to see

The decision log records what was decided, by what, under which rule, and what happened — refusals included, because a refusal is a decision. That is the part of the review that answers questions weeks later, and it is also the part people forget to check while it is still cheap to fix a gap.

Access to the trail is scoped like everything else: a workspace sees its own decisions and no one else's. That holds for the operator too — running the platform is not a licence to read a customer's decisions, and the isolation that enforces it is the same three layers that scope every other record.

## Questions

### How often is a review worth doing?

There is no schedule enforced by Connect. The events worth reacting to are concrete: somebody leaves, a device is lost, a connection starts failing, or an action appears that nobody can account for. A calendar reminder is a poor substitute for reacting to those.

### Can I see a colleague's sessions?

No. The session list is per person, keyed to the signed-in address. What a workspace administrator can do is change what a member may reach and remove their membership, which is the control that actually ends their access.

### Does revoking a mailbox lose the mail already ingested?

No. Messages already stored stay in the workspace and remain readable. Revoking stops future fetching and future sending on that connection; it is not a deletion, and re-consenting later resumes rather than re-imports.

## Related

- [Security settings](https://connectbyjbrh.com/docs/account/security-settings/)
- [Sessions](https://connectbyjbrh.com/docs/account/sessions/)
- [How provider credentials are stored](https://connectbyjbrh.com/docs/security/credential-sealing/)
- [Who can read the audit trail](https://connectbyjbrh.com/docs/security/audit-access/)
- [Rotating a provider credential, end to end](https://connectbyjbrh.com/docs/workflows/credential-rotation/)
- [A copy of a password somebody else rotates](https://connectbyjbrh.com/research/stale-credentials/)

## What this page is based on

- `backend/app/app_auth.py` — sessions, token hashing, revocation
- docs-source/sources/GENERAL.md §10 — security, sealed credentials, the rotated database secret
- docs-source/sources/GENERAL.md §5 — the audit trail records refusals too
- Connect capability registry (docs-source/facts.py)