What you will learn Where data is contained, how many ways out there are, and what locks each one — in a form you can hand to an internal review.
Member roles live in members and roles, material scope in Drive, tool permissions in turning tools on and off. Each is well covered, but a security reviewer wants it on one page.
This is that page.
HyperTeamsgraph TD
A["1. Account — who gets in"] --> B["2. Workspace — the isolation unit"]
B --> C["3. Conversation — who sees this thread"]
B --> D["4. Material — what feeds the answers"]
B --> E["5. Ways out — tools, channels, API, systems"]| Boundary | What it decides | Where | Who |
|---|---|---|---|
| Account | who enters the workspace | invite on the members screen | owner · admin |
| Workspace | the unit where data does not mix | workspace creation | anyone (their own) |
| Conversation | who sees this thread | group visibility | owner · admin |
| Material | which files feed answers | Drive folders | whoever uploads |
| Ways out | which tools and routes can run | tool settings · channels · API keys · systems | owner · admin (systems: owner only) |
The most important sentence in this chapter.
A workspace is the unit where data does not mix. Conversations, material, and tools in another workspace are invisible from here.
So splitting work of differing sensitivity into separate workspaces is the surest control — simpler and far easier to explain than fine-grained permissions inside one workspace.
| Situation | Recommendation |
|---|---|
| Handling HR or legal material | separate workspace |
| External customer contact (widget, channels) | separate workspace |
| Tools that touch production systems | separate workspace |
| General work | one is enough |
The second row especially. Separating the workspace that receives outside input from the one holding internal material structurally breaks the prompt injection path.
| Kind | Who sees it |
|---|---|
| Private conversation | only its creator |
| Fully open group | every workspace member |
| Selected-member group | only the named departments or people |
Understand the exact scope of "private." It means other members cannot see it — not that the workspace owner has no database-level access. Treat it as the place for work in progress before it is tidy, not for personal matters.
Files uploaded to Drive become answer material for that workspace. Retrieval does not know about permissions.
"People allowed to see it" and "people it will surface for when they ask" are the same set. That one line is the whole Drive policy.
This is the section reviewers spend longest on. There are four kinds.
Enabled per workspace in turning tools on and off. The criterion is the same as in tools are permissions.
| Route | Who can send |
|---|---|
| Channels | users of the connected external service |
| Chat widget | any visitor to the website |
| Email agents | anyone who knows the address |
The bottom two rows are where control focuses. Unauthenticated input reaches the agent directly. Do not keep internal material and write-capable tools in that workspace. And this is where the notice and labelling duties of the AI Framework Act apply.
A key from calling in with an API key carries that workspace's permissions in full.
A system is one company machine attached to the workspace. That is why registration and policy changes are owner-only — the heaviest permission in the product, not open even to admins.
Copy this as-is.
The checklist above covers most of it, but enterprise reviews almost always ask these three separately. Each has a screen of its own.
| Question | Where you answer it |
|---|---|
| "Does personal data reach the model?" | Data masking — swapped for tokens on the way out |
| "Is there a record of who looked at what?" | Audit log — queries and grounding documents |
| "Can people sign in with company accounts?" | SSO and department sync — IdP groups become departments |
Fail the third and the rest is never evaluated. For many companies, having to create a separate password is itself a blocking condition.
And the mechanism that puts a person in front of execution is Pending approval and operator rights — the actual implementation of "human approval on irreversible tools".
Past a point it does the opposite. Once per-person exceptions start, nobody can describe the current state six months later. Split coarsely by workspace, then by department inside it — easier to review and easier to maintain.
It means invisible to other members. It does not stop database-level access or disclosure under legal process. Don't put personal matters in it to begin with.
1. What is the surest control when handling work of differing sensitivity?
Splitting it across workspaces. A workspace is the unit where data does not mix, which is simpler and easier to explain than fine-grained permissions inside one.
2. Why separate the workspace when using the chat widget or email agents?
Because unauthenticated outside input reaches the agent directly. With internal material and write tools in the same workspace, the prompt-injection path is complete. Separating them breaks it structurally.
3. Why is system registration closed even to admins?
Because it attaches a company machine to the workspace — the heaviest permission there is. Everything that machine can do enters the workspace, so only the owner can register one or change its policy.
Finally, what to check first when something isn't working → Troubleshooting
Before uploading: □ May every member of this workspace see this file? □ Does it contain personal data — and if so, is there a basis and a retention period? □ Is there a contractual restriction on taking it out?Read tools → generally safe (if what they read isn't sensitive)Reversible writes → logging is enoughIrreversible → send email · payment · delete · publish → human approval□ A separate key per purpose (one key everywhere means revoking stops everything)□ Keys in environment variables or a secret manager — never in code or prompts□ Check per-key consumption on the usage screen periodically□ A revocation procedure when the owner changes[Isolation] □ Is sensitive work in a separate workspace? □ Is outside input (widget, channels, email) kept out of the internal-material workspace?[Access] □ One owner plus one or two admins? (owner alone is a risk) □ Is there a removal procedure for leavers and transfers? □ Is group visibility set by department rather than per person?[Material] □ Has export permission been confirmed for files in Drive? □ Do files containing personal data have a basis and a retention period? □ Are conversations and files used for model training? (personal accounts too)[Execution] □ Is human approval attached to irreversible tools? □ Have unused enabled tools been turned off? □ Were MCP server credentials issued with least privilege?[External exposure] □ Are API keys separated by purpose? □ Is the AI notice shown where the widget or email agent is used?[Records] □ Are approval decisions being recorded? (→ audit trail) □ Is someone reviewing usage on a schedule?□ Member list (are leavers still there?)□ Enabled tools (anything unused for three months)□ API keys (keys whose consumer no longer exists)□ Drive (old sensitive files)□ Systems (slots left holding a disconnected machine)