Enterprise MCP Server Setup for Notion Workspaces

MCP, released by Anthropic in late 2024, replaced that with an open standard built on JSON-RPC 2.0 that connects AI hosts to external tools, resources, and systems without a custom integration for every connection. OpenAI, Google, Microsoft, and Block all backed the standard, which is a big reason adoption across enterprise tool stacks moved as fast as it did. The scale backs this up: MCP infrastructure now sees more than 97 million monthly SDK downloads and supports over 10,000 active public servers, numbers that put it well past the experimental phase.

Notion sits near the front of this wave. It's one of the first major SaaS productivity platforms to stand up a remote, hosted MCP server, reachable at mcp.notion.com/mcp, making it an early stop for any company rolling out enterprise agents. That's not a small thing. Notion workspaces tend to be packed with exactly the kind of material an attacker wants: personal data, contracts, financial records, source code, credentials. Plugging an AI agent into that pile of information, through a protocol that has no authentication or authorization built into its core, raises the stakes the moment the connection goes live.

Notion's MCP server: design-level protections and limitations

Notion MCP works like this: a remote server, hosted by Notion, accepts a connection from an MCP client (Claude Code, Cursor, Codex, or something custom-built), the client authorizes through OAuth, and from there it calls the Notion API on behalf of whichever user authorized it. Once connected, the agent can search across Notion and any linked sources, and it can read, create, and update pages and databases.

The hosted server at mcp.notion.com/mcp is the current recommended path for new deployments, while Notion is winding down the older open-source local package, makenotion/notion-mcp-server. Self-hosting still has a place, though: for read-only use cases, a self-hosted server paired with a "Read content"-only integration token keeps the agent's reach narrow by design. Some endpoints only work with Notion API version 2026-03-11, and the server pulls the right Notion-Version header for each operation straight from its OpenAPI spec.

Governance controls depend heavily on which plan a company is on. Enterprise tier (custom pricing) is the only place that includes unlimited page history, SCIM, audit logs, and something called MCP Governance, and it's also the only tier, along with Business, where MCP connections for Custom Agents are even available. MCP Governance itself gives admins an approved list of AI apps, the ability to audit connections, and a blunt disconnect-all switch, though there's no way to disconnect one app at a time. Day to day, workspace owners manage which MCP clients can connect through Settings → Connections, and organization owners have an Admin API for listing and revoking member connections.

This matters most, though. Every single tool call the agent makes returns whatever the authorizing account is allowed to see, full stop, no filtering. PII, PHI, financial figures, source code, secrets, none of it gets inspected before landing in the AI model's context window. That's a design decision nobody bothered to question. It's how the system is built to work, and it's the exact reason governance can't be an afterthought.

The threat landscape that makes Notion MCP a governance problem, not just a configuration one

The uninspected data flow described above appears in measured, catalogued attacks against real MCP deployments. By early 2026, researchers had already counted around 7,000 MCP servers exposed to the open internet, and roughly 40% of those had no authentication at all sitting in front of them; more than 800 have since been independently scored for security risk. OWASP's MCP Top 10, first published in 2025 and still being updated through 2026, lays out where the damage tends to come from: Tool Poisoning, Privilege Escalation via Scope Creep, Token Mismanagement, Shadow MCP Servers, Software Supply Chain Attacks, and Context Injection.

Tool poisoning gets talked about the most in 2026, and for good reason. An agent reads a tool's description the same way it reads its own instructions, so a hidden command buried in that description gets followed without question. Microsoft's Defender research team documented a case in mid-2026 that shows how this plays out: a finance team connected its agent to a third-party invoice tool that had been approved on paper but never given a proper security review. An attacker later edited the tool's description to quietly siphon off unpaid invoice data, and because MCP just picks up description changes automatically, no re-approval process ever triggered. Separately, the MCPTox benchmark ran adversarial versions of real tools, pulled from 45 live MCP servers, against 20 different language models. Attack success rates came back substantial across the board, with the worst results against a leading reasoning model, and even the model with the strongest refusal behavior still complied with poisoned instructions at a rate that should worry anyone deploying agents at scale.

Supply chain attacks follow the same playbook that's plagued open-source software for years, just wearing new clothes. The postmark-mcp npm package is the clearest example so far: a malicious version, roughly 1.0.16, quietly BCC'd every processed email to an outside domain, and Snyk's disclosure on September 25, 2025 marked it as the first tracked case of a malicious MCP server making it into the supply chain. Typosquatting and fake update pushes are just the same trick recycled. Authentication adoption across the MCP ecosystem stays thin: only 8.5% of MCP servers use OAuth at all, Astrix Security's 2025 State of MCP Server Security research found, and separate assessments from Endor Labs and Equixly found a large share of public servers carrying exploitable flaws depending on which attack class gets tested.

The organizational numbers close the loop. Cisco's State of AI Security 2026 report found that 53% of organizations have already had an AI agent exceed the permissions it was supposed to have, and 47% have suffered an actual security incident tied to an agent; only a small slice of companies say they feel genuinely ready to secure agentic AI. Gartner projects that 25% of enterprise GenAI apps will experience five or more minor security incidents per year by 2028, up from 9% in 2025, explicitly tying the trend to MCP adoption.

The MCP specification's authentication gap that cannot be closed at the configuration layer alone

None of this can get fixed with a settings toggle, and that's by design, not oversight. The MCP spec itself says the protocol "cannot enforce these security principles at the protocol level," which means every organization using it has to build authentication and authorization controls externally. MCP does include an OAuth 2.1-based authorization model, but the NSA's May 2026 cybersecurity guidance points out that using it is optional, and plenty of implementations skip it entirely.

There's also a structural quirk worth understanding. MCP often flips that: the server itself queries and executes actions on the client's behalf, and the NSA specifically flags this reversal as opening attack paths that traditional API threat models were never built to catch. Add to that the fact that MCP expects authorization to happen continuously, on every action, not just once at the start of a session, so a compromised session that skips per-request checks keeps its access for as long as that session lasts.

The spec, too, keeps moving and unsettles all of this. A March 2026 roadmap led into a release candidate lock in May, and then a full revision landed on July 28, 2026, bringing stateless sessions, Enterprise-Managed Authorization (stable as of June 2026), the retirement of Dynamic Client Registration in favor of Client ID Metadata Documents, and server-to-client change notifications. Companies that tried to build their own governance layer in early 2026 are already looking at external platforms instead, simply because their engineering teams couldn't keep pace with how fast the spec itself changed.

Layer on top of that the sheer number of non-human identities now running through enterprise systems. The Cloud Security Alliance puts the ratio at roughly 45 non-human identities for every human one, and only about 23% of organizations have anything resembling a formal strategy for managing AI-agent identity. Put together, the conclusion is straightforward: identity binding, per-request authorization, credential lifecycle management, and audit trails all need to be designed into a Notion MCP deployment from the first day it goes live, not bolted on once agents are already running in production.

Pre-setup decisions: plan tier, permission scope, and identity model before writing a single config line

Before any config file gets touched, a handful of decisions need answers. First: which plan tier is this running on? MCP Governance, meaning approved app lists, connection auditing, and the disconnect-all switch, only exists on Enterprise. Business tier gets SAML SSO and granular database permissions but lacks SCIM and the Enterprise audit log, while MCP Governance controls (approved app lists, connection auditing, disconnect-all) are Enterprise-only, so the available controls define the governance architecture.

Second: who or what is authorizing the connection? This question deserves real thought before OAuth ever gets configured. Connect a broad admin account to the hosted server, and the agent inherits everything that account can see, no exceptions. For anything read-only, a dedicated Notion integration carrying a "Read content"-only token, run through the self-hosted server, keeps the blast radius small if something goes wrong. Reusing a human employee's login for this should be avoided; purpose-built accounts or tokens, one per agent use case, are the safer default.

Third: what does the agent actually need to touch? Map out the specific pages and databases the use case requires, then apply page-level permissions in Notion so the authorizing account can only reach those resources, and do this before the connection exists, not after. Fourth: what identity model governs the agent long-term? Agents are non-human identities and need their own credential lifecycle, not shared API keys, and not a developer's personal OAuth token. Last, a quick technical check: confirm whichever MCP client is in play, Claude Code, Cursor, Codex, or something custom, actually supports Notion API version 2026-03-11, since certain endpoints won't function without it.

Step-by-step: standing up the Notion MCP connection with authentication built in

Step one is picking the deployment model. For most new builds, that means the hosted server at mcp.notion.com/mcp. Notion's development effort is going there, especially since the older local open-source package is being wound down. Self-hosting stays reserved for cases where read-only access through a scoped token is the actual requirement, nothing more.

Step two is setting up OAuth the right way, meaning through enterprise identity rather than someone's personal login. Whatever account authorizes the connection, its permissions become the agent's permissions, full stop, so a dedicated service account or purpose-built integration matters here, not a personal employee credential. Where it's available, Enterprise-Managed Authorization, promoted to stable status in the spec back in July 2026, is worth using: a user authenticates once through the company's identity provider, and that IdP automatically hands out access to whichever MCP servers the user is cleared for, which removes the mess of separate consent screens and cuts down on people accidentally connecting with personal accounts instead of work ones.

Step three is applying page and database-level permissions before connecting. Lock down the authorizing account's access to only the pages and databases the use case actually needs. Anything sensitive, HR files, financial records, source code repositories, should be explicitly excluded from the service account's reach unless there's a real reason for it to be there.

Step four is pointing the MCP client at the right server endpoint and making sure it speaks the right API version. Confirm the client handles the Notion API version 2026-03-11 requirement for the endpoints that need it, remembering that the server pulls the correct Notion-Version header per operation from its own OpenAPI spec.

Step five, for Enterprise workspaces, is turning on MCP Governance. Admins do this through Settings → Connections, then build out the approved list of AI apps, blocking anything not on that list from connecting at all. This is the same mechanism that closes off shadow MCP servers, tools nobody signed off on quietly finding their way into a workspace.

Step six is using session-scoped authorization instead of handing out tokens that live forever. Session scoping ties an agent's access to the length of a specific task, and once that task ends, access ends with it, automatically, no cleanup required. The agent can't renew its own session either; a human has to sign off on starting a new one. If a session ever gets compromised or an agent starts drifting from what it was supposed to do, this keeps the window of damage small instead of open-ended.

Credential management for Notion MCP agents: treating AI agents as the non-human identities they are

Most enterprise security programs were built around a simple assumption: identities are people, and people have faces, laptops, and a working day that starts and ends. AI agents break that assumption completely. They authenticate, hold API keys, read straight through databases, and take action on a customer's behalf around the clock, with none of the usual signals a security team relies on to spot something off. Treating an agent's credentials like a slightly odd version of a human employee's login misses the point; they need their own lifecycle, one built for something that never sleeps, never logs off, and never has a "normal" pattern of behavior to compare against.

The scale of the problem backs this up. Non-human identities already outnumber human ones by roughly 45 to 1 across enterprise environments, yet barely a quarter of organizations have written down any formal strategy for managing them. Every Notion MCP deployment adds to that pile: a service account here, a scoped integration token there, each one needing its own rotation schedule, its own audit trail, its own clear owner. Skipping that step doesn't make the risk of unmanaged, unaccountable credentials disappear. It just means the problem becomes visible later, usually at the worst possible time, as one more credential nobody remembers creating.