What Can a Notion AI Agent Change? A 45-Action Audit

A Notion-connected AI agent can reach far beyond one project page. In a bounded review of Aident Loadout's staging catalog on September 12, 2026, the current Notion integration contract contained 45 public Actions: 21 had read-oriented names such as fetch, get, list, query, retrieve, or search, while 24 had names that clearly add, append, archive, create, delete, duplicate, insert, move, replace, send, update, or upsert workspace data.

That 21-to-24 split is useful for inventory, but it is not a permission policy. The current search Action can fall back to an empty query that lists accessible items, and database-page results can include every custom property. Its optional property filter is applied only after the provider response reaches the integration wrapper. All 45 reviewed Actions also shared the wrapper's conservative operationType: write label and risk level 2.

Authorize the exact Action, query, workspace, returned fields, row limit, and consequence. Do not grant the whole Notion surface because an account can open one approved page.

For a safe first test, allow only one job:

1. search page titles for one specific approved project phrase;

2. return at most five page matches; and

3. return only the title property to the agent.

Do not use an empty query, search databases, read page bodies, fetch comments, enumerate users or uploads, query rows, create content, or change workspace state in that first test.

If that is the boundary you need, inspect the current Notion integration in Aident Loadout before connecting an account. The goal is to inspect one current schema and preflight one bounded reader, not to approve every Notion Action.

The 45-Action Audit Result

The 21 read-oriented names comprise seven fetch, three get, three list, three query, four retrieve, and one search. The 24 write-oriented names comprise one add, six append, one archive, four create, one delete, one duplicate, two insert, one move, one replace, one send, four update, and one upsert.

This count came from the exact Action enum behind the current public Notion search contract, deduplicated and cross-checked against an integration-scoped capability search. It classifies names, not HTTP methods, data sensitivity, recoverability, or business impact.

The search Action is broader than its name

The reviewed notion_search_notion_page contract recommends a specific title query as the primary approach. It also documents a fallback: when a known item does not appear, an empty query can list all accessible items for client-side filtering. That changes a narrow lookup into workspace enumeration.

The same schema warns that database pages can return every custom property with full nested structures. A filter_properties input can reduce what the agent receives, but the schema says that filter is applied client-side after the API response. It is a useful model-context ceiling, not a Notion authorization boundary.

The durable rule is simple: a read-only Action can still exceed the intended data scope. Review query behavior, fallback behavior, and returned fields in addition to whether the Action changes data.

What the 45 Actions Can Reach

The reviewed surface crosses several responsibility levels.

Pages, blocks, comments, and people

Read-oriented Actions can search and retrieve pages, render page Markdown, fetch block content and metadata, read comments, inspect a page property, and list users. Those results can contain internal plans, customer notes, linked files, meeting decisions, personal information, or page-level access clues.

The largest block reader supports recursive traversal, a default maximum depth of 10, and a default maximum of 5,000 blocks in the wrapper contract. Those defaults may be reasonable for document export, but they are much too broad for a first connection test.

Databases, data sources, and rows

Other read-named Actions can fetch databases and rows, query a database or data source, retrieve a database property, and list data-source templates. A single row can still expose people, dates, relations, files, formulas, contact details, or commercially sensitive fields.

A safe analyst role therefore needs both an object boundary and a property boundary. Permission to read one project-status view does not imply permission to query every database the account can access.

Content and structural changes

Write-named Actions can create pages, databases, comments, and file uploads; append text, code, media, tables, tasks, and layout blocks; update pages, blocks, rows, and database schemas; replace whole page content; move or duplicate pages; archive pages; and delete blocks.

These consequences are not interchangeable. Appending a reviewed paragraph, replacing a page body, changing a schema, moving a page, and deleting a block each need a different approval and recovery plan.

Uploads and external transfer

The catalog can create, send, list, and retrieve file uploads. Reading upload metadata may expose filenames or workflow state. Sending a file changes provider state and may place new content in the workspace. Treat upload discovery, byte transfer, and page attachment as separate permissions.

Use a Notion Permission Ladder

Start with the smallest role that completes one useful job.

This ladder separates authentication, reading, and mutation. A connected Notion account proves that a credential is available. It does not prove that the agent should inherit every page, database, or update permission held by that person.

A Safe First Test in Aident Loadout

Begin with the installed public CLI and current connection state:

aident account auth status
aident vault status --integrationId "notion_tools"

If the Notion connection is not ready, stop after discovery, schema inspection, and preflight. A valid schema does not prove workspace access or permission to read private content.

Discover the current title-search Action by job:

aident capabilities search \
  --query "Notion search five page titles read only" \
  --types '["action"]' \
  --scope '{"integrationId":"notion_tools"}' \
  --targetEnv staging

Copy the exact public name from the result, inspect its current schema, and preflight a narrow request:

NOTION_TITLE_SEARCH_ACTION="<PASTE_RETURNED_NOTION_SEARCH_ACTION>"

aident capabilities get \
  --name "$NOTION_TITLE_SEARCH_ACTION"

aident capabilities preflight \
  --name "$NOTION_TITLE_SEARCH_ACTION" \
  --input '{
    "query":"Approved Project",
    "page_size":5,
    "filter_value":"page",
    "filter_property":"object",
    "filter_properties":["title"]
  }'

That exact placeholder-free input passed schema validation and returned a free Aident quote during this audit. It was not executed because the reviewed Vault had no connected Notion account.

Replace Approved Project only with a phrase that a person has approved for the selected workspace. Do not silently replace it with an empty query when no result appears. The current contract says indexing may be delayed and search may be incomplete, so an empty result is not proof that a page does not exist.

Success for this first live test is narrow: the agent returns no more than five page-title matches for the approved phrase and makes no Notion change. If the title is ambiguous, a person selects the page before any content read.

What Changes With Notion's Direct MCP Server

Notion hosts an official remote MCP server at https://mcp.notion.com/mcp and documents OAuth authorization. Its current tool surface can search, fetch, create, update, move, duplicate, and query Notion content. Notion's documentation says a connected client can read and update content that the authenticated user can access.

Notion also documents useful platform controls. Workspace owners can manage MCP connections, organization owners can list and revoke connections through the Admin API, and enterprise administrators can maintain client allowlists. Existing Notion permissions continue to apply.

Those controls answer whether a client may connect and what the person can access. They do not automatically define the agent's temporary job. If the person can access an executive workspace, customer database, or private notes, a broad content search can reach that scope unless the workflow narrows it.

Notion's security guidance also treats tool output as untrusted, warns that prompt injection can cause disclosure or unwanted changes, and recommends confirmation before content-changing actions. Apply the same boundary whether the client uses Notion's direct MCP server or Aident Loadout.

Use the direct route when Notion is the whole job and its current tool and admin controls fit the operating policy. Use Aident Loadout when Notion is one reviewed step in a cross-service workflow and you need one discovery, Vault, preflight, and Audit pattern across services. Neither route turns account access into standing authorization.

Record Six Things Before a Notion Write

Before an agent changes Notion, record:

1. Identity: the selected workspace, authenticated account, and connection type;

2. Action: the exact current Action or MCP tool;

3. Target: the page, block, database, data source, row, comment, or upload;

4. Input: the exact text, properties, files, parent, destination, and options;

5. Consequence: what becomes visible, moves, changes structure, overwrites content, or is difficult to recover; and

6. Read-back: the smallest independent Notion read that proves only the approved change occurred.

For creation and upsert operations, add duplicate prevention. For replacement, move, archive, and delete operations, preserve the prior location or content needed for recovery. For comments and shared pages, preview the audience and final text. One successful write does not grant permission for another page or Action.

Common Notion Agent Permission Mistakes

Letting the person's workspace access become the agent's role

Notion enforces the connected person's permissions, but the agent still needs a narrower task-specific allowlist. An executive using an assistant to find one project page should not implicitly delegate access to every page the executive can open.

Falling back to an empty search automatically

The current wrapper recommends empty-query enumeration when title search misses a known item. That may be useful during supervised troubleshooting, but it expands data scope. Ask for a more specific phrase or a direct page URL before widening the search.

Treating returned-field filtering as authorization

The current filter_properties option is applied client-side. It can keep unwanted properties out of the model context, but it does not make the provider call page-specific or change what the connection is authorized to access.

Using large read defaults for a small job

Recursive block reads and large maximums are export-like behavior. Set explicit page, depth, block, cursor, and property ceilings for the actual question.

Combining analysis and mutation in one autonomous step

A project summary may recommend changing a status, adding a comment, creating a page, or restructuring a database. Return that recommendation for review. Do not let evidence collection silently become a workspace-visible change.

Using a free preflight as a safety verdict

The bounded search request returned a $0.00 Aident quote. Free Actions can still expose private workspace data. Cost approval and consequence approval are separate controls.

Repeat the Audit When the Contract Changes

Recount and inspect the exact Action schemas when Notion changes its MCP tools, authentication, admin controls, or API behavior; when Aident changes the Notion Action version or wrapper metadata; or when the workflow's role expands.

This September 12 review is a contract audit, not a security certification or live-account test. It did not read private Notion content, execute a Notion Action, compare direct-MCP latency, test provider quotas, or verify all 45 operations against a real workspace. Its conclusion is narrower: the current surface mixes read and write jobs, one search can widen into workspace enumeration, and model-output filtering is not a substitute for a least-privilege data scope.

Inspect One Notion Reader Before Enabling Writes

Follow https://aident.ai/SETUP.md

Set up Aident Loadout and inspect one Notion reader

Use the risk-versus-spend approval workflow to separate a free quote from permission to read Notion. Review Aident Loadout credits, BYOK, and Action pricing before any metered step. For the general discovery, connection, preflight, and execution loop, continue with How to Use Aident Loadout.

Sources

• Notion MCP overview, reviewed September 12, 2026.

• Notion MCP supported tools, reviewed September 12, 2026.

• Connect to Notion MCP, reviewed September 12, 2026.

• Notion MCP security best practices, reviewed September 12, 2026.

• Notion MCP admin controls, reviewed September 12, 2026.

• Notion for Aident Loadout, reviewed September 12, 2026.

• Aident Loadout setup, reviewed September 12, 2026.

• Live Aident Loadout staging capability catalog, exact public Notion search schema, and one exact-free preflight, inspected September 12, 2026.

Refresh this audit when Notion changes its remote MCP server, OAuth flow, supported tools, admin controls, or data APIs, or when Aident changes the Notion Action set, schemas, risk metadata, connection flow, pricing, or approval behavior.