How to Block Notion Teamspaces and Pages from Notion MCP
You want to connect Notion to your AI agents through MCP, but your workspace has areas no agent should ever read: the People teamspace, board notes, financial models, acquisition plans. Here is how to block those areas while keeping the rest of Notion available to your team.
Notion MCP acts as the person who connects it. After authorization, the client can read and update everything that person can access in the selected workspace. A person opens a board page on purpose. An agent answering a prompt, or following instructions planted in page content, searches and fetches across everything in scope. The access is technically identical. The risk is not.
This guide shows how to build a custom rule engine in MCP Manager that blocks Notion teamspaces, page trees, and databases from agents, with child pages inheriting the block and human permissions untouched.
Key Takeaways
- Notion MCP runs with each user’s own Notion permissions, so an AI agent reaches whatever its user can access.
- Notion’s Enterprise MCP governance decides which clients may connect, not which content they reach.
- An MCP Manager gateway rule inspects every Notion tool call and result, and blocks or filters items inside a protected teamspace, page tree, or database.
- Inheritance can come from Notion itself: a dedicated internal connection shared with the protected roots can read their child pages, so any item that connection can read is treated as protected.
- This is a custom rule engine (a webhook you write, host, and maintain), not a managed, no-code engine like MCP Manager’s Google Drive Folder Blocker.
Why Notion’s Native MCP Controls Are Not Enough
Three properties of Notion MCP leave the gap open:
- Access is permission-bound in both directions. The connection never widens anyone’s Notion permissions. It never narrows them either.
- Governance stops at the client. With MCP Governance on the Enterprise plan, admins approve specific AI apps and MCP clients and block all others (Notion Help). That decides which client connects, not which teamspace it reads.
- Page sharing only limits integrations. Notion’s advice to not share pages an agent doesn’t need applies to Custom Agents and internal connections (Notion Help). A person’s own MCP connection has no sharing step and inherits everything that person can see.
Removing someone from the People teamspace to protect it from their agent breaks their job, which leaves two options: expose everything, or connect nothing.
The protocol does not close the gap either. Under the 2026-07-28 MCP spec, the Mcp-Name header lets gateways authorize on the tool name without parsing the body. But the page a notion-fetch call targets sits in its arguments, and the pages a search returns sit in its result. Content-level policy means reading the JSON-RPC body on both legs.
Page content is also untrusted input. Text in a page or comment can steer an agent that has write tools or other servers connected, known as indirect prompt injection.
How MCP Manager’s Custom Rules Engine Works for Notion
An MCP gateway like MCP Manager sits between the AI client and Notion MCP, brokering each user’s own Notion identity. A gateway rule hands each tools/call to your custom rule engine on the request leg, the response leg, or both. The engine receives metadata such as serverGuid, toolName, and direction plus the JSON-RPC body, and answers with pass, block, modify, or error. An error falls through to the rule’s failure mode, which defaults to Block for custom engines.
Rules have no per-server or per-tool selector, so the engine passes any call it was not written for. That routing also lets one engine serve Notion alongside Slack channel and Jira project rules, each with its own parser.
How Child Pages Inherit the Block
For every ID it sees, the engine has to answer one question: does this item sit inside a protected tree?
To check whether a page sits inside a protected teamspace, the engine would have to look up each page’s parent through Notion’s REST API, since the MCP message doesn’t carry the hierarchy. For teamspaces, that lookup doesn’t help: Notion’s API currently reports top-level teamspace pages as children of the workspace, so the teamspace never appears in the parent chain .
Notion’s access inheritance can serve as the lookup:
- Create a dedicated internal connection, called the reference connection from here on, and share only the protected roots with it. Sharing a parent page grants the connection access to all of its child pages, independent of any individual user.
- The engine then retrieves each ID with this reference connection’s token.
- If Notion returns the item, it sits inside a protected tree. If Notion returns not found, the engine treats the item as outside the protected trees, and any other failure returns an
errorverdict so the rule’s failure mode applies.
Test this against nested pages, database rows, moved pages, and linked views before enforcing.
Step-by-step Guide to Blocking Notion Teamspaces and Pages
The setup takes eight steps: map what to protect, create the reference connection, connect Notion MCP, set up the gateway and pin the tool surface, build the request-leg rule, build the response-leg rule, deploy and apply the engine, and test with a small pilot group before widening access.
1. Map What to Protect
Start with the areas AI agents should never read, such as board materials, HR and compensation, legal databases, security incident logs, and M&A workspaces. Collect three kinds of identifiers for each:
- Page and database IDs: the ID is the 32-character hex string at the end of the URL, as in
notion.so/acme/Board-Deck-1a2b3c4d5e6f47a8b9c0d1e2f3a4b5c6. The API shows the same ID as a hyphenated UUID, so normalize both forms. - Teamspace IDs: the
notion-get-teamstool returns them (Notion). The rule uses them to catch searches filtered to a protected teamspace and pages created at its top level. - The teamspace’s top-level pages: share each one with the reference connection. That protects the teamspace’s contents.
One gap needs a process: a top-level page added to a protected teamspace later stays unprotected until someone shares it. Limiting top-level page edits in protected teamspaces to teamspace owners keeps that step with the people who own the policy.
2. Create the Reference Connection
The reference connection is the Notion internal connection described above. A Workspace Owner creates it in Notion’s developer portal. It starts with no access, so the protected roots are added on its Content access tab, or from each page’s Connections menu. Sharing a root covers its child pages.
- Grant read access only. The lookup never needs to write.
- Store the token as a secret. It is kept in a secrets manager and passed to the engine as an environment variable.
- Share the teamspace’s top-level pages. Each one is added individually, per Step 1.
3. Connect Notion MCP to MCP Manager
On the Servers page, paste https://mcp.notion.com/mcp and click Continue. Detection resolves to standard OAuth 2.1 with dynamic client registration, so no client ID or secret is needed, and each user approves Notion’s consent screen.
Need the full walkthrough? The step-by-step guide to connecting Notion MCP covers the setup, Enterprise admin approval, and plan requirements for some tools.
On Enterprise workspaces, Notion’s MCP Governance lets admins approve which AI apps and MCP clients may connect to Notion MCP. The MCP Enterprise Lockdown Checklist covers how to route an organization’s MCP traffic through governed gateways, since gateway rules only apply to traffic that passes through them.
4. Create the Gateway and Pin the Tool Surface
Create a gateway for Notion, or add Notion to an existing one, and assign the server with per-user identities so each call runs as the person behind the agent. Teams are provisioned last, after the rules are applied and tested in Step 8. The safe rollout sequence covers the order for configuring a gateway before any user connects.
With feature provisioning set to allow only tools that match conditions, a new tool stays hidden until it is added to the allowlist, so the engine can be checked against its payloads first. Two choices matter for Notion:
- Hide the Custom Agent session tools such as
notion-spawn-sessionunless needed, since their results may not expose page IDs for the engine to check. - Leave prompts and resources off unless needed. Gateway rules inspect
tools/calltraffic only, and Notion MCP also exposes resources.
5. Build the Request-Leg Rule
This rule fires before a call reaches Notion. The engine extracts every identifier in the arguments (page and database URLs, compact or hyphenated UUIDs, collection:// data source URLs, view:// URLs, and teamspace IDs), checks each one, and blocks the call if any is protected. It covers:
- Direct reads such as
notion-fetch,notion-get-comments, andnotion-query-data-sources, including data sources named inside a SQL query. - Writes such as
notion-update-page,notion-create-pages,notion-create-comment, andnotion-delete-pages. - Moves and copies:
notion-move-pagesandnotion-duplicate-pagecan take content out of a protected tree, so block them when the source is protected. - Scoped searches whose location filter names a protected page, data source, or teamspace.
A call that should name a target but doesn’t is blocked. This leg also enables read-only areas: pass reads for a release planning tree and block its write tools.
6. Build the Response-Leg Rule
Search bypasses the request rule: notion-search takes a query and returns matches from everywhere the user can read. The response rule removes protected items with a modify verdict and rewrites any count fields, so the agent still gets legitimate results. MCP Manager’s allowlist recipe shows the handler pattern for both legs.
Notion adds cases the recipe doesn’t cover:
- References inside allowed pages: a fetched page can contain mentions, child page links, and linked database views whose source sits in a protected tree. Whether these expose items from a protected tree should be tested, then a reference with its title is either accepted or stripped.
- Connected sources: with AI search,
notion-searchalso queries sources such as Slack, Google Drive, and Jira. Those results are not Notion pages, so the reference connection cannot evaluate them. Govern them at their source, or have an admin turn AI search off. - Unknown payload formats: capture real results through an admin-only gateway before writing the parser. Block unparseable results only for tools whose format is confirmed, since a rule that blocks every unrecognized result can break fetch or search entirely.
7. Deploy, Register, and Apply
The engine needs a public HTTPS endpoint with a public CA certificate, HTTP 200 for every verdict, responses well under the 30-second timeout, and idempotent handling, since transient failures are retried up to three attempts. Calls should be authenticated with a static header, and MCP Manager’s static outbound IP can be allowlisted. Header forwarding stays off, since this design does not need the user’s tokens.
Register the engine under Rule Engines with the Custom provider. Then open the Notion gateway’s Rules tab, add a rule with the engine as the detection method, choose Both to create one rule per leg, and leave the failure mode at Block. Registering an engine does not apply it. Until a gateway rule references it, Notion traffic is unfiltered.
Need setup details? The guide to registering and securing a custom rule engine covers headers, IP allowlisting, and testing.
8. Test Before Rolling Out
Start in shadow mode: the engine returns pass with a comment such as “would block page X”, which lands in the rule_engine_comment column of the logs. Once coverage looks right, switch to enforcement.
Provision the gateway to two or three admins, and test each path:
- Fetch a protected page by URL and by bare ID, then a deeply nested child.
- Move a test page into a protected tree and out of it, then fetch it again.
- Query a linked database view on an allowed page whose source is protected.
- Search for a term that matches protected and allowed pages.
- Edit a page in a read-only tree.
Blocks log as policy_enforced_abort and rewrites as policy_enforced_mutation. Widen access only after every path behaves as intended.
What the Agent and the User See
A blocked call returns a JSON-RPC error. The engine can instead return modify with a custom error body, and a not-found style message avoids confirming that the page exists. Filtered search results disappear silently. A placeholder stops agents from retrying around the gap, but reveals that protected matches exist. The person’s own Notion access stays exactly as it was.
Build or Wait for a Managed Rule Engine?
The Google Drive Folder Blocker is a managed engine: an admin sets MCP Manager’s hosted endpoint, pastes folder IDs, and applies the rule. The Notion rule is code your team writes, hosts, and maintains, and four things need an owner:
- Maintenance: when Notion adds or changes tools, the parser needs a matching update, and the people who administer Notion rarely maintain web services.
- Security review: InfoSec will ask how coverage of every path is demonstrated. Test cases, captured payloads, and logs are the evidence. A vendor-maintained engine is an easier case to make.
- Operations: the engine sits in the path of every Notion call. With the default failure mode, an outage pauses Notion MCP until it recovers.
- The reference connection: its token can read every protected page. Grant it only the read content capability, store it in a secrets manager, and rotate it. Creating it requires a Workspace Owner.
A managed Notion blocker is not available today; teams that want one can raise it with their MCP Manager contact. To build now, a coding agent can draft the engine from the MCP Manager docs MCP server. Review it like any other code before it enforces policy.
Weighing build against managed? Book a no-obligation demo with MCP Manager and scope the Notion rule for your team.
Practical Tips for Running the Notion Rule
A rule that blocks Notion pages from AI agents is only as good as its edge cases. These practices tighten a custom rule engine on an MCP gateway before Notion MCP reaches the wider organization.
- Choose between a blocklist and an allowlist. Sharing the protected roots with the reference connection creates a blocklist. For regulated content, share only the approved roots instead and block anything the connection cannot read, so new top-level pages stay out of reach until approved.
- Cache verdicts briefly. Lookups count against Notion’s API request limits, so cache per ID with a short time-to-live.
- Combine with PII filtering. Allowed pages can still hold personal data. A Microsoft Presidio rule set to Replace turns detected entities into tags such as
<EMAIL_ADDRESS>. Presidio is less reliable for names in free-form text, so add regex rules for structured identifiers, and place block rules first. - Separate gateways for different risk profiles. The same server can sit on several gateways with different rules, each provisioned to its own team.
- Export logs to your SIEM. MCP Manager forwards logs over OpenTelemetry to Splunk, Datadog, Grafana Cloud, and other collectors, with or without call bodies.
Keep Notion in Your AI Rollout and the Board Pages Out
The gap between “this person can see this page” and “this agent should see this page” is where the risk lives. Notion MCP does not close that gap on its own. A gateway rule does.
A request-leg rule, a response-leg rule, and a lookup based on Notion’s own access inheritance give teams a third option between blocking Notion MCP and exposing every teamspace. It takes engineering effort to build and maintain, and it is worth being clear-eyed about that.
Book a demo with MCP Manager and test the Notion rule against your own workspace before rolling it out.
FAQ
Which Notion teamspaces and pages should I block from AI agents?
Start with board materials, HR and compensation, legal databases, security incident logs, and M&A workspaces. These are the areas where an agent reading by mistake, or through injected instructions, does the most harm.
Can I block Notion pages from MCP without writing code?
Not today. The Google Drive Folder Blocker is a managed, no-code engine. Notion page and teamspace blocking runs on a custom rule engine you write and host.
Does blocking a Notion page from the agent also block it from the human user?
No. The rule applies only to traffic through the MCP gateway. Teamspace membership, page permissions, and the Notion app stay unchanged.
Can I block an entire Notion teamspace?
Yes. Protect the teamspace’s top-level pages once, and everything inside them is covered automatically. The only ongoing task is protecting new top-level pages as they are added, so that step needs a named owner.
Can I block entire Notion databases, not just individual pages?
Yes. Share the database with the reference connection, and its rows are covered along with it. Views of that database on other pages should be tested before enforcing the rule.
What happens if Notion adds new MCP tools after I deploy my rule?
With feature provisioning pinned to known tools, a new tool stays hidden until the engine handles it. Without that pin, a new tool that returns page content could bypass the rule.
Does MCP Manager add latency to Notion MCP calls?
Gateway overhead for brokering and forwarding is typically around 150 ms or less per call (MCP Manager docs). A custom engine adds its own round trip, including any Notion lookups.
What if an agent uses Notion’s search tool to find blocked content?
Search results are filtered before they reach the model. Matches from protected areas are removed, the agent still receives the rest, and searches aimed directly at a protected teamspace or page are blocked.
