Notion MCP server links product requirements to working code

At a glance

What this is: Notion’s MCP server connects product documentation and implementation so developers can move from PRD to prototype in one prompt.

Why it matters: That matters because once documentation can drive code and code can update documentation, IAM and NHI teams have to govern tool access, user-based permissions, and scope drift as part of the development identity surface.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read WorkOS's recap of Notion's PRD-to-prototype MCP demo

Context

Model Context Protocol is turning documentation systems into active inputs for software development, not just repositories for reference material. In this case, the key identity question is not whether a developer can make a PRD executable, but whether the permissions behind that workflow are bounded tightly enough for NHI governance.

The operational gap is familiar: when an external tool can fetch documents, invoke code-generation flows, and write back to the source of truth, the development workflow becomes an identity-controlled path. That path needs scoping, attribution, and review because the same access that accelerates delivery can also widen blast radius if the MCP server or client permissions are too broad.

Key questions

Q: How should teams govern document-to-code workflows that use MCP servers?

A: Treat the workflow as a privileged identity path, not a productivity shortcut. Define which documents can be read, which tools can be called, and which write-back actions are allowed in a session. Then review those permissions as NHI entitlements, because the server is translating document access into operational action.

Q: What breaks when a development IDE can inherit broad workspace permissions through MCP?

A: The main failure is scope leakage. If the IDE can reach everything the user can reach, then a local coding session can become a broad privilege bridge into documents, databases, and connected tools. That widens blast radius and makes accidental or malicious overreach harder to contain.

Q: When should organisations re-evaluate access reviews for MCP-based development tools?

A: Re-evaluate them whenever a tool can both read source material and write back decisions, code, or documentation. Traditional reviews often focus on static application access, but MCP changes the unit of control to a session with tool calls. That makes periodic recertification too coarse unless it includes the reachable action set.

Q: What is the difference between user-based permissions and least privilege in MCP workflows?

A: User-based permissions tell you who the session is acting for. Least privilege tells you how much the session should be allowed to do. In MCP workflows, those are not the same thing, because the client may only need a narrow slice of the user’s access to complete the task safely.

Technical breakdown

How MCP turns documentation into an executable workflow

MCP gives a client like an IDE a structured way to call tools exposed by a server, so the model can pull context from documents, databases, or APIs and act on it during a session. In this example, the PRD is not just read once. It becomes a live input that can be fetched, interpreted, and used to generate code, then queried again to check for drift or missing requirements. That bidirectional loop is powerful because it collapses the gap between specification and implementation, but it also makes the document repository part of the operational control plane.

Practical implication: treat document-access tooling as production-grade identity infrastructure, not a convenience integration.

User-based permissions change the NHI trust boundary

The article describes a shift from bot-style access to user-based permissions, where the MCP server can reach the pages and databases the user can access and attribute actions back to that user. That model simplifies UX, but it also inherits the full risk profile of delegated access. If the client can act with the user’s permissions, then the server, the token, and the connected IDE all become part of the trust boundary. The governance question is whether the access path is constrained enough to keep developer productivity from becoming an uncontrolled privilege bridge.

Practical implication: review delegated access paths as NHI entitlements with the same scrutiny you apply to service accounts and API tokens.

Why tool limits and stateful servers matter for control design

The post notes that some clients struggle with stateful servers, granular tool sets, and complex schemas. That is not just an engineering nuisance. It affects how much surface area the agentic workflow exposes and how reliably security controls can be enforced across calls. When a server accumulates many narrowly scoped tools, or when the client cannot handle state cleanly, teams often compensate by broadening access or simplifying guardrails. That creates a security tradeoff: convenience and interoperability can quietly pull governance toward larger privilege bundles.

Practical implication: design MCP tool boundaries and state handling so security does not depend on client-specific workarounds.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Documentation-to-code workflows create identity exposure, not just productivity gains. The article shows how a PRD can move from Notion into code generation and back again in the same flow. That means the document system is no longer passive content storage. It becomes an identity-mediated control surface where access to a page can influence implementation decisions, which pushes the problem squarely into NHI governance and tool-scoping discipline.

Scope drift is the real governance failure mode in MCP-based development. The integration is attractive because it reduces friction, but every added tool, client, and connected workspace expands the reachable action set. That expansion is not visible in the same way as a traditional application permission review, so teams can miss how quickly a development workflow becomes a multi-system privilege path. Practitioners should treat that as identity sprawl in the software delivery chain.

Access attribution is necessary, but attribution alone does not contain blast radius. User-based permissions improve accountability because actions are tied back to a person rather than a generic bot. But accountability does not equal constraint. If the connected client can see everything the user can see, the security model still depends on the original permission boundary being correctly designed for machine-assisted use. Teams need to re-evaluate whether human permissions are safe proxies for development-time machine access.

Notion’s MCP pattern sharpens a new named concept: documentation-driven access inheritance. The article illustrates how a document system can inherit the access and context of the user session that is invoking it, then pass that authority into code generation and update flows. That is useful for delivery, but it also means documentation can become a privilege amplifier when the surrounding identity controls are broad. The implication is that document access and execution access can no longer be governed as separate domains.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• Our research also found that 53% of MCP servers expose credentials through hard-coded values in configuration files, which keeps the exposure window open longer than most teams expect.
• For a broader control view, see Analysis of Claude Code Security for how agentic workflows change the identity boundary around developer tooling.

What this signals

MCP-driven development will keep collapsing the boundary between content and execution, which means IAM programmes need to treat design-time systems as runtime identity surfaces. The organisations that will struggle most are the ones still separating developer collaboration tools from privilege governance.

Documentation-driven access inheritance: when a document can drive code and update itself through the same session, the access model attached to the document becomes part of the application control plane. That changes how teams think about recertification, because the reachable action set matters more than the label on the account.

The broader signal is that AI-enabled development is pushing NHI governance upstream into product design workflows. Teams that wait until deployment to examine tool scoping will find the privilege model already embedded in the way work gets done.

For practitioners

• Map the document-to-code trust path Inventory every system that can read from Notion, invoke an IDE, or write back to the source of truth. Classify the path as an identity flow, not a collaboration feature, and require ownership for each hop.
• Scope MCP tools to the smallest viable action set Avoid exposing broad, catch-all tool collections when narrower functions will do. Keep the tool catalogue small enough that access reviews can actually determine whether each capability is justified.
• Separate user attribution from permission design Do not treat user-based attribution as a substitute for least privilege. Validate which pages, databases, and actions the session can reach, and verify that the connected client cannot inherit more reach than the workflow requires.
• Review stateful MCP sessions for privilege drift Check whether token refresh, durable session state, or repeated tool calls expand the effective access window beyond what the original task needed. Re-authenticate and re-scope sessions when the workflow changes.

Key takeaways

• Notion’s MCP pattern shows how quickly documentation can become an operational identity surface once a tool can read and write in the same session.
• The governance risk is scope drift, because user-based permissions can still create broad privilege bridges when the client inherits too much of the user’s reach.
• Teams should review MCP tool scopes, session boundaries, and write-back paths together, rather than treating documentation access and execution access as separate problems.

Key terms

• Model Context Protocol: A structured protocol that lets an AI client call tools and retrieve context from external systems in a controlled session. In practice, it turns documents, APIs, and databases into part of the runtime interaction model, which makes identity and access design central to safe use.
• Documentation-driven access inheritance: A governance pattern where the permissions attached to a document or workspace flow into a session that can generate code or update records. It is useful for productivity, but it also means the document’s access boundary can indirectly shape operational behavior and exposure.
• Tool scoping: The practice of limiting which actions an MCP server or agent can invoke during a session. Good tool scoping keeps the reachable action set narrow enough that access reviews, monitoring, and incident containment remain practical instead of becoming open-ended.
• Scope drift: The gradual expansion of what a session can do as more tools, connections, or permissions are added. In AI-assisted development, scope drift often happens faster than teams notice, because each small integration can broaden the effective blast radius of the workflow.

Deepen your knowledge

MCP-based document-to-code workflows are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving documentation into the development control plane, that training is directly relevant.

This post draws on content published by WorkOS: From PRD to Prototype in One Prompt: How Notion's MCP Server Transforms Product Development. Read the original.