Notion AI Agents Security for Custom Agents and Custom MCP Connections
Notion Custom Agents run on schedules, Slack messages, database changes and finished meeting notes, with their own permissions rather than yours. Since Notion 3.7 on September 15, 2026 they can also take action in GitHub and other tools through custom MCP connections and hand work to sub-agents. Notion built real safeguards. The gaps sit in three tool settings and in what the Business plan does not log.
Direct answer
Notion Custom Agents are reasonably secure by default: they start with no access, write tools default to Always ask, and Notion pauses on URLs that were not in the prompt. The risk grows when a builder switches a write tool to Run automatically or Always allow, connects a custom MCP server, or chains sub-agents. Audit logs and SIEM connections are Enterprise only. Keep write tools on Always ask until a policy layer checks each call.
Try it live
Watch AgentShield block an attack in real time.
Pick a scenario and drive the inspection lane yourself. No signup needed.
Run a request
Runs the live engine on your text. Nothing is stored, no account needed.
Inspection lane
INSPECTINGPolicy trace
High-risk action held for approval
Audit trail
- § · → → →
The risk
A US software company on the Notion Business plan builds a release agent in September. It runs when a meeting note from the weekly release review is finished, reads the decisions, and since the 3.7 update it opens and labels GitHub issues through a custom MCP connection authenticated with a personal access token pasted into a header. During testing every GitHub write asked for confirmation, which got tiresome, so the builder switched the server to Always allow. Two weeks later a contractor joins the meeting and pastes a vendor changelog into the notes. The agent reads it on its next run. Nobody approves anything, because nothing asks.
How AgentShield handles it
Keep Notion for what it does well: the workspace, the agent builder, page-level permissions, the Agent Directory and its URL checks. Put AgentShield between Notion and the tools that write. Point each custom MCP connection at the AgentShield MCP gateway instead of the vendor server, keep the real GitHub, CRM or ticketing credentials in the gateway, and let a per-tool, per-argument policy decide what runs, what waits for a named approver and what is refused, with every decision logged outside Notion.
The controls
The controls that secure which MCP tools a Notion Custom Agent may run and who approves first.
What Notion enforces for Custom Agents, and what it leaves to your configuration
Notion Custom Agents are autonomous agents that live in a Notion workspace, run on triggers or on request, and read and write Notion pages, Slack channels and connected tools with permissions of their own. They reached general availability on May 4, 2026, run only on the Business and Enterprise plans, and are billed in Notion credits on top of seats. Notion lists the price as 10 US dollars per 1,000 monthly Notion credits (checked on notion.com/pricing, October 2, 2026).
Notion has put more thought into agent security than most workspace vendors. Its engineers describe "a build-from-nothing security model where agents start without access to most resources", and the product shows warnings when an agent is given private pages, email, calendar or third-party connections. The useful question for a buyer is which of those protections stay on once a team starts automating. Here is the map we use.
| Control | What Notion provides | Default or catch | What is left to you |
|---|---|---|---|
| Agent access | Access granted page by page and app by app | The agent has its own permissions, so a user can reach data through it that they cannot open directly | Deciding who may use each agent, not only what it can read |
| Write tools on MCP connections | Always ask, Run automatically or Always allow per tool | Always ask is the default for writes; Always allow removes every future prompt for that server | Keeping writes gated once the testing phase is over |
| Custom MCP servers | Admin switch, OAuth or header authentication | A header token is whatever the builder pastes, often a personal token | Scoping the credential and the server it unlocks |
| Links and web access | Pause and confirm on URLs not in the original prompt; web search can be turned off | Content the agent already reads is not a URL | Inspecting pasted and synced text for instructions |
| Audit log | Agent configuration and access changes recorded | Audit log is an Enterprise plan feature | A record of each tool call on Business, and of arguments on any plan |
| Data retention | No training on customer content | Zero data retention with LLM providers is Enterprise only | Knowing which plan your agents run on |
Read the third column and you see the pattern. Notion's defaults are careful. The exposure comes from the settings people change after the agent works, and from which plan the workspace is on.
Notion 3.7 custom MCP connections and sub-agents, what changed in September 2026
Two Notion releases in September 2026 widened what a Custom Agent can reach. On September 9, workspace owners on Business and Enterprise gained control over which AI models Custom Agents may use, and agents gained a trigger that runs them as soon as an AI Meeting Note is finished. On September 15, Notion 3.7 shipped three changes that matter to anyone responsible for what agents touch.
First, custom MCP connections. In Notion's words, "You can now connect GitHub, Amplitude, and other tools with the Custom MCP connection so you can grab context, check performance, or take action in the tools your team already uses." It is in beta on Business and Enterprise. Second, sub-agents: "Now a Custom Agent can call other Custom Agents as sub-agents, each with its own instructions, context, access, and model." Third, Skills, reusable instructions that can also be downloaded as SKILL.md files for other coding assistants.
| Date | Release | Why it matters for security |
|---|---|---|
| February 24, 2026 | Custom Agents launch in beta | Agents with their own permissions and triggers enter workspaces |
| May 4, 2026 | General availability, Notion credits, admin controls | Spend caps, creation permissions and the Agent Directory arrive |
| September 9, 2026 | Model controls, meeting note trigger | Agents run unattended on content many people can write into |
| September 15, 2026 | Notion 3.7, custom MCP beta, sub-agents, Skills | Agents can act in outside tools and delegate to other agents |
Each change is sensible on its own. Together they move a Custom Agent from a workspace helper that edits pages to an automation that can open issues, change records and message people in other systems, started by events nobody watches, and able to hand the job to a second agent with a different set of access grants. A prompt injection in a meeting note or a synced page now has somewhere to go.
Sub-agents deserve a specific check. Each sub-agent keeps its own access, so the parent agent's settings do not tell you the full reach of a run. Map the chain: which agents can call which, and which of them hold write tools set to anything other than Always ask.
Always ask, Run automatically and Always allow on Notion MCP tools
Every tool on a Notion MCP connection carries one of three execution settings, and they decide more about your exposure than any other control in the product. Notion's documentation defines them this way: Always ask "requires a user to approve or cancel an action before it executes", Run automatically "allows the tool to execute without requiring confirmation from the user", and Always allow "permanently approves all tools from a server and removes future confirmation prompts".
Always ask is the default for write tools, and Notion's own guidance is to leave writes there while testing and switch them to Run automatically one at a time. Anyone with Can edit or Full access on the agent can change these settings. Notion's prompt injection guidance adds two instructions worth copying into your internal policy: "Enable human confirmation for non-read-only tools" and "Only add external MCP servers you trust."
Three practical limits follow from how the settings work:
- The setting is per tool, not per value. A GitHub tool that can close one issue can close a hundred. There is no built-in way to say "run automatically for labels, ask for anything that deletes" inside one tool.
- Always allow is per server. One click approves every tool the server exposes today, and any tool its maintainer adds later.
- Unattended runs and confirmations pull in opposite directions. Notion's MCP documentation says tools work with all trigger types, including scheduled runs and runs started by Notion or Slack events. It does not describe who answers an Always ask prompt when nobody started the run. Test that in your workspace before you depend on it, because the pressure to switch a scheduled agent to Run automatically is exactly how the gate disappears.
| Requirement | Notion tool settings | Policy at a gateway |
|---|---|---|
| Hold only writes above a threshold or on certain repositories | No, the setting covers the whole tool | Yes, per tool and per argument |
| Approver is a named person with the right role | Whoever is using the agent at that moment | A named approver group, recorded with the decision |
| Same rule for every agent and sub-agent that uses a server | Set separately on each agent | One policy for every caller |
| Rule survives a builder switching to Always allow | No | Yes, the gateway still checks the call |
Our human approval for AI agents page shows what an approver sees and how holds expire.
Notion AI agents security on the Business plan compared with Enterprise
Custom Agents run on both paid team plans, but the security tooling around them does not. Notion's pricing page lists audit log, zero data retention with LLM providers, SCIM provisioning, advanced security controls and the security and compliance connections for DLP and SIEM under Enterprise. Notion's security article confirms that key configuration and access changes to Custom Agents land in the audit log for Enterprise admins.
That matters because many US teams that adopted Custom Agents did it on Business, where agents are available and the audit log is not. On Business you can see an agent's settings and its run history in the product. You cannot pull a tamper-evident record of who changed a tool from Always ask to Always allow, or ship agent activity to your SIEM through Notion's own connectors.
| Situation | What we would do |
|---|---|
| Agents only summarize and edit Notion pages, no MCP, no Slack writes | Buy nothing. Notion's page permissions and warnings are enough. |
| Enterprise plan, agents write to Slack and Notion only, compliance wants a record | Buy nothing extra. Use the Notion audit log and your SIEM connection. |
| Business plan, agents write to GitHub, Jira or a CRM through custom MCP | Add a gateway that logs and gates each write, since the plan has no audit log |
| Any plan, scheduled or meeting-triggered agents with write tools on Run automatically | Add per-argument policy and named approvals before the next run |
| Sub-agent chains where a child agent holds payment, deletion or customer messaging tools | Gate those tools outside Notion so the chain cannot skip the check |
Two of those five rows say buy nothing, and we mean it. The case for a runtime layer starts when a Notion agent can change something outside Notion without a person looking first.
How to put AgentShield in front of Notion custom MCP connections
Your team keeps building agents in Notion the way it does now. The change is where the MCP connections point and where the write credentials live.
- Inventory agents that act. Open the Agent Directory and list every Custom Agent with a write tool on an MCP connection, Slack write access or a sub-agent that has either. Note each trigger.
- Find every Always allow. For each MCP connection, record which tools are on Run automatically and which servers are on Always allow, and who last changed them.
- Route MCP through the gateway. Replace the vendor server URL in each custom MCP connection with an AgentShield MCP gateway endpoint. Notion still authenticates with OAuth or a header token, but the token now unlocks only the gateway, and the real GitHub or CRM credential stays with us.
- Write policy per tool and argument. Allow reads broadly, let low-risk writes run, hold deletes, merges, bulk changes and anything with a dollar value for a named approver, and deny what an agent should never do. Rules live in AI agent permissions management and apply to every agent and sub-agent that calls the server.
- Inspect what agents read. Meeting notes, synced pages and pasted vendor text are untrusted input. AgentShield checks content for injected instructions before a tool call acts on it, see prompt injection protection.
- Keep the record outside Notion. Every allowed, held and denied call is written to the AI agent audit trail with the agent, the trigger, the arguments and the approver, which covers the Business plan gap and gives Enterprise teams argument-level detail.
Teams running agents in more than one workspace tool should also read our Microsoft 365 Copilot security and MCP server security pages, since the same gateway policy covers them.
FAQ
Common questions about notion custom agents security.
Are Notion custom agents secure?
They start from a careful baseline: no access until granted, write tools default to Always ask, and Notion pauses on unexpected URLs. Risk rises when builders switch write tools to Run automatically or Always allow, connect custom MCP servers with broad tokens, or chain sub-agents. Audit logs are Enterprise only, so Business workspaces have less visibility.
How much do Notion custom agents cost?
Custom Agents require a Business or Enterprise plan, and runs are billed in Notion credits on top of seats. Notion lists 10 US dollars per 1,000 monthly Notion credits, checked October 2, 2026. Admins can set workspace and per-agent spending caps, and Notion pauses agents on unusual spend.
Do Notion custom agents need approval before acting?
Only if the tool is set to Always ask, which is the default for write tools on MCP connections. Anyone with Can edit or Full access on the agent can switch a tool to Run automatically or a whole server to Always allow, which removes the prompt. Notion also asks before visiting URLs that were not in the prompt.
Can Notion custom agents connect to MCP servers?
Yes. Pre-configured MCP connections are available on Business and Enterprise, and since Notion 3.7 on September 15, 2026 custom MCP connections are in beta, letting agents act in tools such as GitHub and Amplitude. A workspace admin must enable custom servers first. Authentication is OAuth or a header token.
Can someone use a Notion agent to see pages they cannot access?
Yes, and Notion says so. Custom Agents have their own permissions, and Notion warns that anyone who can use an agent might access information through it that they could not access directly. If the agent has write access, users can make edits through it too. Limit who can use each agent.
Does Notion have an audit log for custom agents?
On the Enterprise plan, yes. Key configuration and access changes to Custom Agents are recorded in the Notion audit log. Business workspaces do not have the audit log. Neither plan records the arguments of each MCP tool call in a tamper-evident store, which is what a gateway adds.
What are Notion sub-agents?
Since Notion 3.7, a Custom Agent can call other Custom Agents as sub-agents, each with its own instructions, context, access and model. A parent agent can delegate triage or reporting to a child agent and combine the answers. For security reviews, map the whole chain, because each sub-agent keeps its own access.
Does AgentShield work with Notion custom agents?
Yes, through Notion custom MCP connections. You point each connection at an AgentShield MCP gateway endpoint, keep the real tool credentials with us, and every tool call is checked against a per-tool, per-argument policy, held for a named approver when needed, inspected for injected instructions and logged. Notion itself stays unchanged.
More use cases