# One page for security review

> **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.

## Why one page

Member roles live in [members and roles](/guide/cn-members), material scope in
[Drive](/guide/cn-drive), tool permissions in [turning tools on and
off](/guide/cn-tool-settings). Each is well covered, but **a security reviewer
wants it on one page.**

This is that page.

## There are five boundaries

```mermaid
graph 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) |

## 2. The workspace is your strongest control

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](/guide/mcp-prompt-injection) path.

## 3. Who sees a conversation

| 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.

## 4. Scope of material

Files uploaded to [Drive](/guide/cn-drive) become **answer material for that
workspace.** Retrieval does not know about permissions.

```
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?
```

**"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.

## 5. The ways out

This is the section reviewers spend longest on. There are four kinds.

### Tools

Enabled per workspace in [turning tools on and
off](/guide/cn-tool-settings). The criterion is the same as in [tools are
permissions](/guide/mcp-security).

```
Read tools        →  generally safe (if what they read isn't sensitive)
Reversible writes →  logging is enough
Irreversible      →  send email · payment · delete · publish → human approval
```

### From outside in — channels, widget, email

| Route | Who can send |
|---|---|
| [Channels](/guide/cn-channels) | users of the connected external service |
| [Chat widget](/guide/cn-chat-widget) | **any visitor to the website** |
| [Email agents](/guide/cn-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](/guide/ax-compliance) apply.

### API keys

A key from [calling in with an API key](/guide/cn-api) carries **that
workspace's permissions in full.**

```
□ 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
```

### Systems

A [system](/guide/cn-systems) 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.

## Review checklist

Copy this as-is.

```
[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?
```

## The three questions a review always asks

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](/guide/cn-masking) — swapped for tokens on the way out |
| **"Is there a record of who looked at what?"** | [Audit log](/guide/cn-audit) — queries and grounding documents |
| **"Can people sign in with company accounts?"** | [SSO and department sync](/guide/cn-sso) — 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](/guide/cn-approvals) — the actual
implementation of "human approval on irreversible tools".

## Quarterly review

```
□ 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)
```

## Common misconceptions

### "Doesn't finer-grained permission make it safer?"

**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.

### "Isn't a private conversation invisible to everyone?"

**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.

---

## Check yourself

**1. What is the surest control when handling work of differing sensitivity?**

<details>
<summary>Answer</summary>

**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.
</details>

**2. Why separate the workspace when using the chat widget or email agents?**

<details>
<summary>Answer</summary>

**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.
</details>

**3. Why is system registration closed even to admins?**

<details>
<summary>Answer</summary>

**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.
</details>

---

Finally, what to check first when something isn't working →
[Troubleshooting](/guide/cn-troubleshooting)