The situation
A product manager asks for Notion in ChatGPT. Someone in security asks the obvious follow-up. Does that mean ChatGPT can read the private pages, the compensation doc, the board notes? The honest answer depends on whose Notion account is behind the connection. That is the decision most teams make by accident.
This playbook sets up Notion MCP access for ChatGPT across a company, in the order you would actually do it, without exposing private pages. It assumes you have already added Elaichi to ChatGPT. If you have not, the walkthrough is in connecting ChatGPT to one address. MCP is the protocol an AI client uses to call tools. Elaichi serves it at one endpoint, https://api.elaichi.ai/mcp, the same address for every organization.
How do you set up Notion MCP access for ChatGPT without exposing private pages?
Have each person connect Notion with their own account. The connection decides what the AI reaches, not the client.
A private Notion page is exposed when the connection behind the tool call belongs to someone who can see it. Nothing else decides this.
In Elaichi, every call through a connection uses the account that connection was made with, whoever makes the call. A Notion connection made by a workspace owner and shared with a team reaches Notion as that owner. It does so for everybody it was shared with. The AI client is not the variable. The connected account is.
Notion's own MCP server works the same way. Notion describes it as a remote server it hosts. An authorized client can read and update the content the authorizing user can access (checked October 2026, Notion's MCP overview). Notion workspace owners manage MCP client access from Settings, then Connections. Organization owners can use Notion's Admin API to list and revoke members' MCP connections.
That gives you the first real choice. If Notion is the only app your team needs in ChatGPT, Notion's own server needs no second vendor, and you already know how to revoke it. Elaichi earns its place when the same people also need HubSpot, Jira and Slack. One address, one set of rules, one audit log. Elaichi's own Notion connector sits in the connector catalog.
Step one: each person connects their own Notion account
The restriction that stops the private-page problem is not a rule you write. It is a decision about whose account signs in.
Have each person create their own Notion connection in Elaichi. Their calls then reach Notion as them, and Notion's page permissions do the work. A page they cannot open in Notion is a page ChatGPT cannot read for them. A connection is a single row the organization reuses through sharing. The temptation to connect once and share it with everyone is real. Resist it here.
There are three ways to get tools running on each person's own account in Elaichi, and only three. The three are their All tools toolbox, a toolbox they build on their own connections, and a template each person stamps. With a template, each person picks their own connection for each connector. A single toolbox shared with a team cannot do it. A stored toolbox's entries run only on the connections pinned in them, under the authority of whoever pinned them.
So for a Notion rollout, publish a template and share it at use. Each person stamps it, picks their own Notion connection in the per-connector picker, and ends up with their own toolbox. The console's stamp dialog starts every picker at "Skip and add a connection later". It pre-fills nothing from anyone's connections. The same per-person pattern applied to a file store is in the Dropbox walkthrough.
Step two: block the write tools for roles that only read
For a role that should read Notion and not change it, write block rules naming the Notion tools that create and update pages. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. So write the rule on each role that should be held back.
Two details decide whether the rule holds.
A layer with only block rules has no allowlist, so everything it does not block passes it. Blocking some write tools leaves every write tool you did not name reachable. Enumerate them, or use an allow rule instead.
An allow rule naming a connector whole admits every tool on it. Once a role carries any allow rule, every tool its allow rules do not name is blocked for that role. So an allow rule that holds Notion to its read tools also needs allow rules for every other app that role uses. That is the trade: allow rules are tighter and more work. The mechanics are in the piece on name matching versus operation matching.
Restrictions are evaluated for the person making the call, not for whoever pinned the connection. They are checked before the call leaves Elaichi. A tool restricted for someone is left out of the tools Elaichi advertises to ChatGPT. It is still named in search results, flagged restricted, with no schema and no way to call it. The model can then tell the person what to ask an admin for.
One thing to plan for: a role or restriction change takes effect within about two minutes. Revoking a grant, or removing a member, is different. Those stop the client on its next call.
Step three: lock the workspace argument where it matters
If a role should only ever touch one Notion database or one parent page, freeze that argument on the toolbox entry. Frozen parameters are labeled "Locked-in values" in the console. They are argument values written into a toolbox entry. A caller cannot override them when the call runs through that entry.
Frozen keys are removed from the tool's advertised input schema, so ChatGPT cannot set them. Be clear about what this does and does not hide. Elaichi prefixes the tool's description with a note such as "(frozen: folder_id=HR)", and short values show. Anyone who can open the toolbox reads every frozen value in full. The AI can see that a value is set, and often what it is. It cannot change it.
The freeze also holds only on calls that run through the entry carrying it. Anyone who can use the connection themselves has the same tool, unfrozen, in their All tools toolbox. So keep the connection unshared. Pin it into a toolbox entry with the frozen value. Share the toolbox at use rather than the connection. The general case is worked through in locking tool arguments.
The audit query that proves it
Open the audit log and filter the category to Assistant. Connected-tool calls, including calls from ChatGPT, sit in the Assistant category, because their action is assistant.toolbox_tool. Filtering to MCP does not show MCP tool calls. That category holds grant events.
Each connected-tool row records the person and the toolbox the call went through. It also records the tool's advertised and catalog names, the connector, the connection the call reached and the tool's classification. It records how approval was given, the surface, and the MCP client's id when the surface is mcp. The detail panel reads as a sentence, something like "Using ChatGPT, Emily Carter updated the page "Q4 Roadmap" in Notion through the connection "Acme Notion"."
Three lines answer the private-page question:
- Connection. This is the account the call actually reached, not the one the arguments asked for. If it names one shared connection on every row, you did not do step one.
- Ran from. This tells you the call came from ChatGPT rather than the console or an API token.
- What it did. Read data, Changed data or Deleted data, from the tool's recorded classification. A read-only Notion rollout should show Read data and nothing else.
Export the view as CSV with its filters applied when you need evidence outside the console. The export stops at 10,000 entries rather than saving a partial file. Elaichi keeps 90 days of audit history. For a longer trail, forwarding to your own Datadog comes with the Black plan, which is launching soon.
One honest gap: a scope refusal writes no audit row, because the refusal happens before any executor runs. Absence of a row is not proof nothing was attempted.
What ChatGPT's own controls can and cannot do here
ChatGPT's per-app permission settings act on the Elaichi app as a whole, not on Notion inside it. Elaichi's tool list never names a connected tool, however few there are. A client control that gates individual MCP tools can only act on execute_tool, run_code and two Elaichi operations as wholes. It cannot single out Notion.
Nor does a read-only client setting help. None of the tools that run connected tools is marked read-only. A setting that lets read-only tools run unprompted still prompts for every connected-app call, reads included. It does not make Notion read-only.
The workspace controls are still worth setting. In ChatGPT Enterprise and Edu, new plugins and apps are generally disabled by default, and admins review and change their availability; in ChatGPT Business, apps are enabled by default (checked October 2026, OpenAI's admin controls for plugins and apps). OpenAI also says Always allow is not offered as a persistent permission to members of a managed workspace (checked October 2026, OpenAI on managing app permissions).
Per-app and per-tool control is set in Elaichi, as restrictions. What ChatGPT's own admin controls do cover, and where they stop, is laid out in restricting ChatGPT Enterprise connectors. For the question of which workspace a write landed in, see the Notion workspace post. For the model underneath all of this, read MCP governance.
