Which Notion workspace did ChatGPT write to?
The audit trail tells you. Elaichi writes one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Each records the Notion workspace the call actually reached, which comes from the execution itself, not from what the model meant to do. To stop the wrong-workspace write before it happens, share the team a toolbox pinned to one workspace, with the database frozen where one fits. The model is then never offered the other.
Product teams end up here easily. One workspace is the company wiki. The second arrived with an acquisition, an agency or a team that moved before IT had an opinion, and both contain a page called Roadmap. When ChatGPT edits "the roadmap", the first question after an unexpected change is which of the two it touched, and a timestamp is not an answer.
To answer it, filter the trail by the person, or by free text on the workspace's connection label, and read the account on each write. What an AI agent audit log must capture covers the rest of each entry.
MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. Elaichi serves Notion from its 600+ catalog through one organization-wide endpoint. Notion's connector page lists its tools, and the knowledge management connectors sit beside it.
How does the model choose between two Notion workspaces?
From labels, unless you take the choice away. When both workspace connections are shared with a product manager, each Notion tool that can reach both takes a required connection argument. Its values are the account labels in the tool's schema, and the model fills it in on every call.
Label the connections so a person can tell them apart. "Notion Core Wiki" and "Notion Atlas" beat "Notion" and "Notion 2". Account labels stay scorable in Elaichi's tool search on purpose, so a distinct label helps the model and whoever reads the trail later. A value that names no real account returns an error listing the real ones, not a write somewhere else.
Through Elaichi, connected tools are never listed one by one, however few there are, so ChatGPT reaches a Notion tool by searching for it. How search picks one tool from hundreds covers the ranking. Labels make the model's guess better, but they do not take the guess away.
How do you stop a write landing in the wrong Notion workspace?
Share the team a toolbox pinned to one workspace, not the connections themselves. A toolbox is a curated set of tools shared with a team. The person who connected the workspaces leaves both connections unshared. They pin the core wiki into a toolbox entry for each tool the team writes with. If the team still reads the acquired workspace, its read tools get entries pinned to that one. Then they share the toolbox with the product team at use. From there, the team runs Notion only through those entries and cannot open or reshare the connections behind them.
Where it fits, pin the database too. The page-create tool, create_a_notion_page, makes a page "as a child of an existing page or database". Freeze the parent database's ID on that entry, and the model files a spec in the specs database and nowhere else. A frozen key is removed from the schema the model is offered. A frozen value is merged over the caller's arguments at execution, so passing the key anyway changes nothing. Locking a tool argument shows the same mechanism on a payment tool.
One condition: a freeze binds only calls made through its toolbox entry, so share the toolbox with the people it governs, not the connection itself. Anyone who also holds use on a workspace's connection, directly or through a team share, reaches its tools without the pins. Do not try to close that path with a block rule, because a block withholds the tool everywhere, the pinned entry included. Close it by not sharing the connection.
One side door stays open after the pin. The move tool, create_a_notion_page_move, moves a page "to a different parent location". Leave it out of the toolbox, or block it on the product role, if filed pages must stay where they were filed.
Which Notion deletes should the product team lose?
Page and block deletes, plus the trash flag that does the same job. Block delete_a_notion_page_by_id and delete_a_notion_block_child_by_id on the product role. Notion's delete-a-block reference says a delete sets the block to in_trash: true and moves it to the Trash, "where it can still be accessed and restored". So a delete can be undone, but only by someone who notices it in the right workspace.
Updates can trash content too. The page-update tool, update_a_notion_page_by_id, changes a page's "properties, icon, cover, or trash status", so a block on the delete tools leaves that path open. Either block it as well, or freeze its trash argument to false on the toolbox entry. Notion's API calls that field in_trash in the update-page reference, and you should copy the exact path from the tool's schema in Elaichi before you freeze it. Frozen to false on the entry, it means an edit made through that entry can never double as a delete.
The catalog has no tool named for deleting a database. Notion trashes one through an update instead: its update-database body takes in_trash, "Whether the database should be moved to or from the trash" (update a database). The catalog describes update_a_notion_database_by_id as changing a database's title, description or schema, so check its schema in Elaichi for that field. If it is there and a database must survive, block the tool too, and make schema changes in Notion itself.
Put these blocks on the role the product team holds. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A newly connected workspace is fully reachable until a rule exists. Write the rules as blocks, not as an allowlist. In Elaichi, the allowlist stage engages on the presence of an allow rule, not its contents, so an allow rule that names nothing denies everything. Why blocks and allows match differently explains that rule, and why a block also catches a renamed tool.
How do you set up both workspaces for ChatGPT?
Connect each workspace once, share the team a toolbox rather than the connections, and give every member one role. Sharing grants view, use or edit on one resource, a toolbox included, and the grantee can be a person, a team or everyone in the organization. A member's view holds what they own plus what was explicitly shared with them. No organization-level permission widens that list quietly, owners and admins included.
Exactly one role per member is enforced, so a role is a whole persona rather than a bolt-on. The tool:execute permission gates the endpoint ahead of every other check, and Guest, Billing Admin and Auditor do not have it. Sign-in can run on your identity provider: Elaichi has SAML and OIDC SSO built in-house, plus SCIM v2 with group-to-role mapping. A product manager added to the Product group arrives with the role that group maps to.
In ChatGPT, writes need Business, Enterprise or Edu. OpenAI says full MCP support, "including modify/write actions, is rolling out in beta" to those plans (OpenAI help center, checked October 2026). There, an admin creates the app and publishes it. Pro users connect "with read/fetch permissions in developer mode", so a product manager on Pro can read the roadmap but cannot file a spec. Connecting Elaichi to ChatGPT has the steps.
Why not use Notion's own MCP server?
For a team on one workspace that needs only Notion in ChatGPT, Notion's own server is the simpler choice. Notion describes it as "a remote MCP server hosted by Notion". After OAuth, the client can "read and update content that you can access" (Notion's developer docs, checked October 2026). Notion's own permissions decide what each person reaches, and there is no second vendor. Workspace owners "can manage MCP client access" from Notion's Settings, under Connections, and organization owners can "list and revoke members' connections".
Elaichi adds what spans more than Notion:
- One address. ChatGPT, Claude and Cursor reach Notion and every other connected app through the same organization endpoint.
- One rule set per role. The product role's delete blocks sit beside its rules for every other app, written once.
- Pinned entries. A shared toolbox entry pinned to one workspace, with the database frozen, offers the model nothing else, and the model cannot override the pin.
- One audit trail. Every app's calls land in one record, each entry naming the account it reached.
- One place to cut access. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. Removing a product manager stops their calls through Elaichi to every connected app, starting with the next one. Notion still holds their account, which you close in Notion or your identity provider.
Notion's page does not describe pinning a write to one database or a trail that spans other apps, and it has no reason to: its job is Notion.
What happens when the PM who connected a workspace leaves?
Their access ends with their membership, and the team's toolbox needs someone new to vouch for it. Each toolbox entry records who pinned it, and that is re-checked on every call. If that person loses use on the connection, is removed, or is suspended through SCIM, their entries stop resolving for every grantee until someone still present re-pins them. Offboarding lists those entries as a warning that does not block the removal.
Removing the PM also runs a preflight. It lists every connection they own, private and shared alike. A shared connection the team still depends on can go to another active member, which leaves every grant on it as it was. It is deleted only if the admin asks for that. Nothing transfers to the organization, to a team, or to the admin running the removal. A private connection that nothing beyond the PM depends on cannot be transferred and is deleted with them. A private connection that a shared toolbox depends on blocks the removal until an admin transfers it to a member. Wherever the connection lands, keep sharing the toolbox rather than the connection, so the pins still hold.
A SCIM deprovision suspends the member and never removes them. SCIM's active attribute carries a meaning that "is determined by the service provider" (RFC 7643). Whether the identity provider sends active: false or a delete, Elaichi sets the member to suspended. In Elaichi, removing or suspending a member revokes every live grant in the same transaction as the membership change. The PM's next call through Elaichi is refused. Removal, with its preflight, stays a separate step an admin takes in Elaichi, and the PM's Notion account is another.
Revoking a share or disconnecting an account also lands on the next call. A role or restriction change is the slow one: it takes about two minutes. How offboarding lands for an AI client explains the two speeds.
What does this cost a product team?
Elaichi has two plans, Gold and Black, and every workspace starts with a 14-day trial, no credit card to start. Checkout does collect a card, and it sets the paid trial to the remaining days rather than granting a fresh 14, so it is one continuous trial rather than two. Pricing shows the current price for your region. Billable seats are active memberships, minimum one. Suspended members do not count, and neither do the free-seat roles: Guest, Billing Admin and Auditor. That matters here, because a compliance reviewer can watch the Notion trail on an Auditor seat without costing a license. If a trial ends without checkout, the workspace pauses: plan-gated features lock, nothing is deleted, and subscribing picks up where it left off.
When does a product team not need this yet?
When there is one Notion workspace, a few people, and an agent that only reads. A control plane is overhead there, and Notion's own server covers it. Revisit when a second workspace appears, or when someone asks which account an agent wrote to and nobody can say. When an MCP gateway is premature lays out that decision.
One limit applies either way. The prompt-injection write gate lives in the Elaichi agent window and does not apply to a raw tool call. What holds instead is configuration the model cannot change: a hostile instruction inside a Notion page still cannot reach a restricted delete or the other workspace.
For the same rollout on a CRM instead of a wiki, see the sales team's Salesforce playbook. Scope by department sits on use cases, and the rest of the catalog is at connectors.
