Building Security into AI Agents for Collaborative Workspaces

notion · Tech · 2026 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.5 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Secure autonomous agents in collaborative workspaces

Notion needed Custom Agents to be useful in multi-user workspaces without letting agents over-read, over-write, bypass permissions, or take risky actions such as posting to company-wide Slack channels.

Constraints:

• Single-user assistant permission models do not fit collaborative workspaces.
• Broad access makes agents dangerous, while no access makes them useless.
• Safety instructions in prompts can be compressed out or bypassed.
• MCP integrations are not always resource-based and often assume single-player use cases.
• Prompt injection remains unsolved, so successful attacks must be contained.
• Users need remediation paths when agents make mistakes.

Architecture

Notion Custom Agents use a build-from-nothing security architecture. Agents start with no permission to read, write, or interact with most resources; users then grant page-level view/edit permissions, Slack modes, email confirmation settings, and MCP tool/action approvals. Safety is enforced outside the model in access-control and deterministic layers rather than relying on the LLM to obey safety text. At runtime, layered controls monitor external data and suspicious agent behavior, pause risky actions for owner confirmation, and provide remediation such as deleting bad Slack posts. Alpha testing at large scale informed new permissions such as Slack read-and-reply and motivated first-party integrations where MCP lacked resource-level controls.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  custom-agent[Custom Agent] --> deterministic-access-control-layer[Deterministic access control layer]
  deterministic-access-control-layer --> page-permission-grants[Page permission grants]
  deterministic-access-control-layer --> slack-first-party-integration[Slack first party integration]
  deterministic-access-control-layer --> mcp-tool-controls[MCP tool controls]
  custom-agent --> page-permission-grants
  custom-agent --> slack-first-party-integration
  custom-agent --> email-confirmation-control[Email confirmation control]
  custom-agent --> mcp-tool-controls
  custom-agent --> runtime-warning-system[Runtime warning system]
  prompt-injection-monitor[Prompt injection monitor] --> runtime-warning-system
  prompt-injection-monitor --> custom-agent
  email-confirmation-control --> runtime-warning-system
  slack-first-party-integration --> remediation-delete-action[Remediation delete action]
  alpha-testing-program[Alpha testing program] --> slack-first-party-integration
  alpha-testing-program --> deterministic-access-control-layer
  security-team-agents[Security team agents] --> custom-agent

Components

Data flow

A Custom Agent starts with no access. During configuration, a user grants explicit page-level access, selects integration permissions, configures email confirmation, and chooses MCP tools/action approvals. If a configuration is risky, Notion shows confirmations or requires workspace-admin approval. At runtime, the agent executes only through the deterministic access-control layer. External data is tagged and monitored for prompt-injection risk; suspicious behavior or risky actions pause execution for the agent owner. For Slack, the first-party read-and-reply permission lets an agent respond only in threads where it was explicitly triggered. If the agent posts something wrong, the owner can delete the message.

Why this architecture

Notion intentionally keeps security out of the model's discretion. A zero-permission default and deterministic access controls create a hard boundary before the LLM reasons about tasks. Resource-level grants keep agents useful without broad workspace power. Runtime warnings and prompt-injection monitoring recognize that static permissions alone do not handle all execution-time risks. First-party integrations are used where standardized protocols such as MCP do not yet provide the collaborative, resource-based controls Notion needs.

Models used: Notion Custom Agents · Scruff security agent

Scale

• Notion ended alpha testing with more than 3,000 internal Custom Agents.
  “Notion had more than 3,000 internal Custom Agents”article, stated
• Alpha customers created more than 25,000 agents.
  “our alpha customers had created more than 25,000.”article, stated
• The accidental Slack #general posts reached a company-wide channel with hundreds of people.
  “posted to #general (the agent knows every Slack workspace has #general!), the company-wide channel with hundreds of people in it.”article, stated
• Notion planned a beta period over the next couple of months for continued improvement.
  “Our Custom Agents beta period over the next couple of months will also help us to continue to improve alongside our customers.”article, stated
• Notion's next roadmap was framed in coming weeks and months.
  “In the coming weeks and months, we expect to tackle:”article, stated

Alternatives considered (roads not taken)

Start agents with broad access and rely on safety instructions

Rejected because: Prompt safety text can be compressed out and leaves security to model reasoning.

Grant broad workspace access

Rejected because: Collaborative agents should receive specific resource permissions, not broad workspace access.

Use MCP alone for Slack-style integrations

Rejected because: MCP did not natively handle the resource-based permissions and triggers needed for multi-user collaborative workspaces.

Assume prompt injection can be fully caught

Rejected because: Notion treats prompt injection as unsolved and designs to block impact rather than claim perfect detection.

Only prevent mistakes up front

Rejected because: Agents will still sometimes do the wrong thing, so users need remediation paths.

Patterns

safety-policy-enforcement (security)

Notion enforces agent safety through deterministic access controls and resource-level permissions rather than relying on model reasoning.

human-in-the-loop-gate (control)

Risky configurations and runtime actions pause for user, owner, or workspace-admin approval.

tool-use-orchestration (integration)

Notion controls which Slack, email, and MCP tools agents can use and which action types require approval.

guardrails-io-filtering (security)

Runtime layers tag and monitor external data, detect suspicious behavior, stop execution, and ask for confirmation.

privacy-preserving-processing (security)

Build-from-nothing permissions and page-level grants limit which workspace resources an agent can read or modify.

eval-driven-development (quality)

Notion used a large alpha-testing program to stress-test security in practice and convert observed failures into new permission modes.

Tradeoffs

Start agents with zero permissions

Chose Build-from-nothing security model over Broad default access with prompt-level safety instructions.

Rationale: Deterministic access control makes safety enforceable even when prompts are compressed or bypassed.

Build first-party Slack integration

Chose Custom resource-level Slack permissions over Relying solely on MCP.

Rationale: First-party integration let Notion enforce read-and-reply and other collaborative permissions without extra customer work.

Use confirmations for riskier actions

Chose Config-time and runtime approval prompts over Fully autonomous execution of every granted action.

Rationale: Confirmation keeps low-risk autonomy possible while adding a human gate for sensitive setups or actions.

Permit extensibility through MCP with controls

Chose Specify tools and action approval modes over Reject MCP integrations entirely.

Rationale: MCP gives extensibility, but Notion wraps it in explicit tool availability and action-approval settings.

Conservative permissions first, broader scopes later

Chose Phased rollout with future admin-approved broader scopes over Launching with broad advanced permissions immediately.

Rationale: Notion preferred to establish guardrails before reintroducing broader permissions for advanced use cases.

Gotchas (what bit them)

Single-user agent permission models fail in collaborative workspaces.

Root cause: Agents operating around multiple users and shared resources need resource-level controls, not permissions mapped to one user.

Resolution: Use build-from-nothing permissions and granular resource grants.

Broad Slack write access let agents post to company-wide channels.

Root cause: Early agents encouraged overly permissive Slack access without users understanding consequences.

Resolution: Introduce a custom read-and-reply Slack permission limited to explicitly triggered threads.

MCP did not satisfy collaborative resource-permission needs by itself.

Root cause: Most MCPs were designed for single-player use cases and lacked native resource-based permissions or triggers.

Resolution: Build first-party integrations for core services while still supporting MCP with explicit tool/action controls.

Prompt injection cannot be treated as solved.

Root cause: Even with detection, some attacks may pass, so the architecture must reduce blast radius.

Resolution: Layer permission controls, external-data tagging, runtime monitoring, and confirmation pauses.

Prevention alone is incomplete for autonomous agents.

Root cause: Agents can still post incorrect messages or take actions that need reversal.

Resolution: Provide owner-level remediation such as deleting the incorrect Slack message.

Evaluation

Notion evaluated Custom Agents through a large internal and external alpha-testing program, stress-testing security at increasing scale and converting observed failures into permission-model changes. The source also reports internal security-team adoption for alert triage, AppSec automation, code fixes, and adversarial tests.

Metrics: More than 3,000 internal Custom Agents · More than 25,000 alpha customer-created agents · Observed over-permissive Slack write failures · Security-team internal adoption · Beta-period customer feedback

Outcomes

• Notion launched Custom Agents with zero-permission defaults and resource-level access controls.
• Alpha testing led to a custom Slack read-and-reply permission after over-permissive agents posted to #general.
• Notion chose first-party integrations for core services where MCP lacked collaborative resource permissions.
• The security team adopted agents internally, including Scruff for alert triage and enrichment.
• Notion entered beta with planned broader admin-approved scopes, external integration permissions, and additional permission modes.

The security model was tested across more than 3,000 internal agents and more than 25,000 alpha customer-created agents before the beta period.