Who may change what
Three boundaries decide who may do what: the workspace, which every record belongs to and nothing crosses; the person, identified by a Google account and able to decide items on channels they may send on; and the Connect Assistant, whose rights are deliberately narrower than any person's. Everything anybody does is recorded against them by name.
The workspace boundary#
Every record belongs to exactly one workspace, and that is enforced three times rather than once: an allowlist in front of the customer API, the workspace kernel in the data layer, and row-level security in PostgreSQL. Reading or changing another workspace's autonomy settings is not an elevated right that somebody could be granted — it is a state the system has three independent reasons to refuse.
Sign-in is by Google account only; there is no password sign-in to misplace or reuse. Signing in as somebody else ends the session it replaced on that browser, and only that one — never that person's other devices.
What a person may do#
- Decide a held item
- Any workspace member with permission to send on that channel, with the decision recorded against them by name.
- Change a mode or an exception
- A workspace-level change to what Connect may do — see Workspace administration for who holds that in your workspace, and Adding a colleague for how membership is granted.
- Read the decision record
- Within the workspace, subject to the same rules as the rest of the product; Who may read the audit record covers it specifically.
- Clear a suppression
- Only where clearing it is legitimate. A do-not-contact entry is deliberately not casual to remove.
What the Connect Assistant may never do#
The Assistant works through a defined set of tools, and it is given fewer rights than the person talking to it. That gap is deliberate: an agent that can be persuaded by a well-written message should not be able to do the two things hardest to undo.
| It may | It may not |
|---|---|
| Read: find records, search knowledge, list held items and commitments, recall memory | Quote pricing |
| Write: release, send or decline a held item; remember and forget; create and complete commitments | Clear a do-not-contact entry |
| Act on a request and have that work recorded as its own | Act as though it were the person who asked |
The screen context it is given is checked against the database before it is trusted, so a page that claims to be showing one record cannot talk the Assistant into acting on another. Anything it does appears in the decision log as its own action, which is what keeps the accountability question answerable.
Two rights that belong to the platform operator#
Verifying customer payments, the operator's own price list, and enquiries addressed to the operator through the public website sit outside every customer workspace by design. They are the work of running the platform rather than of using Connect, and no autonomy setting or workspace right reaches them.
Beyond those, there is no capability one audience has and the other does not — a claim checked by a parity suite rather than asserted here. See Autonomy for the Owner and for a customer.
Questions#
Can somebody change an autonomy mode without anybody knowing?
Changes to what Connect may do are workspace configuration, and the effect of a change is visible in the decision log immediately afterwards, because every action and refusal names the rule it ran under. A mode that started releasing work unattended is legible in the log from its first entry.
Is there password sign-in for people who do not use Google?
No. Google is the only sign-in, deliberately, so there is no second credential path to secure. Google sign-in covers what that means in practice.
Can I stop the Assistant touching the approval queue?
Its ceiling is fixed rather than configurable: it cannot quote pricing and cannot clear a do-not-contact entry under any instruction, and everything it does is recorded as its own. Narrowing what it may do beyond that is a question for the workspace administration screen rather than the autonomy one.