Notion AI Security: What Page Permissions, the Audit Log, and Workspace Controls Cover

Notion AI reads from the same permission graph the rest of Notion uses, which means its security posture is a restatement of the workspace's existing sharing decisions. Enterprise plans add an audit log, admin controls over sharing and export, and content search for reviewing who can see what. Notion states in its Enterprise security provisions that it "does not use your Customer Data or permit others to use your Customer Data to train the machine learning models." I want to walk through what each of those controls governs and the request none of them evaluates.

TL;DR

• Notion AI surfaces content from the pages a user already has permission to open, so its reach equals that user's existing effective access across teamspaces and shared pages.
• The Enterprise audit log covers eight event categories spanning pages, workspaces, accounts, teamspaces, data sources plus organization settings, retained for up to 365 days.
• Audit events export as filtered CSV and stream to a SIEM by webhook in real time, with organization events excluded from the SIEM integration.
• Admin controls can disable public sharing, guest access, exports plus page duplication to other workspaces, which bounds distribution without evaluating any individual AI request.

The permission graph is the exposure surface

The security story starts with how Notion gets used, and only then with how Notion AI works. A workspace that has accumulated four years of pages, with teamspaces created ad hoc and pages shared to "everyone at the company" because that was faster than picking people, holds an access graph nobody has read end to end.

Notion AI queries that graph on the user's behalf. Content that was technically visible but practically buried under three levels of nested pages becomes a one-sentence answer. The permission was already wrong on the day it was set. What changed is the cost of finding what it exposed, which dropped to the length of a question.

Notion's Content Search feature exists for exactly this review, letting administrators see page access permissions, discover who has visibility into specific content, and change sharing settings. Running it before an AI rollout rather than after an incident is the whole recommendation, and the number of teams that skip it is the reason this paragraph exists.

What the audit log records

The Notion workspace audit log is available to organization owners on the Enterprise plan and covers eight categories:

• Page events, covering creation, editing, deletion, sharing, permissions, comments plus file operations.
• Workspace events, covering member management, integrations, SAML and SCIM configuration, groups plus AI settings.
• Workers events, covering deployment, execution, secrets plus access control.
• Account events, covering login and logout, password changes, MFA updates plus profile modifications.
• Teamspace events, covering membership, permissions, archival plus settings changes.
• Form events, covering responses and form configuration.
• Data source events, covering creation, schema changes plus permissions.
• Organization events, covering domain verification, security policies, legal holds plus admin roles.

Retention is stated plainly: "audit log history is retained for up to 365 days, so you can select any range within the past year." A year of history with a real query range is better than most SaaS platforms provide, and the SIEM webhook streaming makes it usable in an existing detection pipeline.

Two boundaries are worth writing into a runbook. Organization events are excluded from the SIEM integration, so domain verification changes, security policy edits and admin role assignments have to be pulled from the CSV export path instead. And the categories describe workspace operations: workspace events include AI settings changes, meaning the toggle, not the prompt.

AI usage is not the audit unit

Read the category list again with an incident in mind. A product manager asks Notion AI to summarize the compensation planning teamspace they were added to last quarter and pastes the summary into a Slack channel.

The audit log holds page events for the pages that were read, an account event for the sign-in, and workspace events if anyone touched AI settings that day. Reconstructing the AI interaction itself means inferring it from page-read events near a timestamp, a correlation exercise built on no underlying record.

Notion's documentation does not specify whether Notion AI prompts are recorded as their own event type, and it notes that content reads by external AI tools are logged. For a compliance program that has to answer "what did this employee send to a model, and was it allowed," page-read inference is a weak substitute for a per-request record. The requirements a stronger record has to meet are laid out in AI audit log schema design.

The controls that do bound distribution

Notion Enterprise gives administrators a set of workspace-level switches that meaningfully reduce blast radius: disabling public page sharing, disabling guest access, disabling exports, and disabling page duplication to other workspaces. Notion also documents DLP integrations with tools including Nightfall AI and Polymer to "identify different types of sensitive information stored in Notion and take action to remove them."

Those controls operate on content at rest and on the paths content takes out of the workspace. They are the right controls for that job. They do not sit on the request between a user's prompt and a model, so they cannot evaluate what a specific question is about to pull together from a dozen pages.

The parallel case is what happens outside Notion entirely. The same employee copying the same compensation summary into an unmanaged consumer chatbot leaves Notion's controls behind at the clipboard, which is the visibility problem covered in shadow AI detection and how to find shadow AI.

What a per-request decision needs

For a Notion AI deployment inside a regulated organization, the record a reviewer will ask for has four parts that page-read events cannot supply: the authenticated principal as asserted by the identity provider, the role or group that principal held at the moment of the request, the classification of the content that entered the prompt, and the policy decision that permitted the interaction with the version of the policy that produced it.

Producing those four fields requires a component on the request path that verifies identity independently and evaluates policy before the model responds. The permission graph is an input to that decision. What the audit log records is everything except the decision itself. Sitting between the two is the post-authentication gap.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits inline as a stateless proxy on HTTP AI traffic between authenticated users or agents and LLM endpoints, evaluating identity, role, and data classification on every request before it reaches a model, across the sanctioned tools and the ones an engineering team wired up without telling anyone.

Each decision produces a signed record carrying the named principal, the role, the classification of the prompt content, the policy version, and the allow-or-block outcome, in a form that streams into the same SIEM already receiving Notion's audit webhook. Notion's permission model keeps deciding which pages a person may open, the audit log keeps a year of workspace history, and the sharing controls keep bounding distribution. DeepInspect adds the per-request authorization decision that turns activity history into audit evidence. Book a technical deep dive at deepinspect.ai.