Tool access policy

Tool access policy lets administrators stop every agent in an Organization, or in one Team, from discovering, enabling or running specific builtin tools, an MCP server (and every tool it offers), individual MCP tools, or custom tools. It saves repeating a per-agent denial on each agent, and agents created later are covered without any extra step.

Owners, Admins and Security Admins change the policy, after reconfirming their identity. Agent Admins and Auditors can read it. Team Admins cannot change it, because they could otherwise lift a restriction placed on their own Team; they can still deny tools for individual agents.

Deny a tool

Open Governance → Policies → Tool access. Choose Entire Organization or a Team, find the tool, and choose Deny. Each tool shows its blast-radius severity and what it can reach, so you can start with the critical and high entries such as code execution, browser and HTTP tools.

The denial applies from each agent's next tool call. It does not cancel a call that is already running. If the tool was enabled on an agent, it stays recorded but is hidden and cannot run; it returns if you allow the tool again.

Deny an MCP server, MCP tool or custom tool

Use the tabs above the list to switch from Builtin tools to MCP servers, MCP tools or Custom tools.

• MCP servers lists the platform, Organization and Team servers the policy can see. Choose Deny on one, or type a server name. Every tool the server offers disappears from the agent's tools and search, whatever its name. A server that is removed and added again with the same name stays denied, and so does a listed server that is later renamed. Servers that platform administrators provide to every agent can be denied for your Organization or one Team without affecting other Organizations.
• MCP tools denies one tool by the full name agents see, such as mcp_crm_delete_record. If the provider renames the tool, the old entry no longer matches it; deny the server instead when that matters.
• Custom tools denies every custom tool with that name in the selected scope. It does not delete the tool. Deny create_custom_tool as a builtin tool to stop agents writing new ones.

You can deny a name that does not exist yet, for example a server you plan to connect later. Entries that do not match any known server, tool or custom tool are marked Not matched; they start working as soon as something carries that name. Members' personal servers are not listed, so deny those by typing the name.

How scopes combine

An agent's blocked tools are everything denied by the installation's intelligence tier, its Organization, its Team and the agent itself. A lower scope can never allow what a higher scope denied:

• A Team page shows Organization denials as locked.
• Lifting a Team denial leaves any Organization denial in force.
• Agent settings → Tool access shows Organization and Team denials as read-only, with their source.

Team denials follow the agent's Team: if someone who manages both Teams moves an agent to another Team, it takes on the target Team's denials instead. Organization denials do not change with a move.

Organization denials cover all Organization-owned agents, including Team agents and private workspace agents. Personal agents outside an Organization are not covered.

What agents see

A denied tool is removed from the agent's tool list and search results. If the agent still tries to call it, the reply says the tool is denied by your Organization or Team policy and not to retry. Which administrator acted and any other policy detail stay out of the agent's context.

Core tools that let an agent finish a turn or reach people, such as chat and human input, cannot be denied.

Permit only selected capabilities

When your operator has enabled it, Tool allowlist appears on the same policy page, in Agent settings → Tool access, and in staff System Settings. It starts in Inherit without adding an allowlist, preserving existing behavior. Organization security administrators publish Organization, Team and agent policies; staff publish installation policy.

Security administrators can manage an individual agent's allowlist from its Governance agent profile → Access & connections → Tools when agent audit profiles are available. This uses tool-policy permissions; it does not require general agent-settings access.

Choose Only selected tools, select exact capability revisions, enter a reason, and choose Preview affected agents. Review newly permitted and blocked tools, inherited blockers, schedules and queued work, then Review publication and confirm. A changed policy, owner, catalog or known workflow configuration requires a fresh preview. Previews show policy effects; they cannot predict every workflow dependency or provider permission.

Installation, Organization, Team and agent allowlists intersect. Every active list must approve the capability, and every existing denial still wins. An empty list permits only core controls. Choosing Inherit removes this scope's allowlist and can expand authority; higher restrictions remain. The research starter fills a draft with webpage requests, file reads and report writes. Review it like any other selection.

New tools, changed schemas, changed server/authentication context and new executable releases need renewed approval. Individual remote HTTP MCP tools and published OpenAPI operations can be selected. A new server UUID or operation revision receives no approval from its predecessor. Unavailable or changed approvals remain visible for review. Refresh MCP catalogs through the existing integration administration tools; publishing a policy does not start a local MCP process.

Custom-tool creation and execution, command-based MCP and computer-relay MCP are unavailable through restricted platform paths. Shell, Python, HTTP, browser and delegation tools retain their broad authority when selected. An allowlist does not establish read-only behavior or approved-code-only execution; external credentials, destinations and network controls still apply independently. Provider read-only annotations do not prove safety.

The seven core controls retain chat/application replies and attachments, human questions, plan/result records, filtered discovery and turn completion: send_chat_message, request_human_input, search_tools, update_plan, sleep_until_next_trigger, end_planning, submit_application_result. They do not grant denied tools. Core-only agents can still write internal records and transmit authorized replies.

New admissions, including deferred browser, email and OpenAPI execution, recheck policy. Narrowing does not cancel admitted calls, general-code processes or downstream effects. Use separately authorized halt controls for containment. A policy-storage or enablement failure refuses non-core tools; disabling authoring never lifts published restrictions. Activation remains closed until the operator has qualified and drained every execution component. Ask your installation operator about deployment qualification; sandbox software and destination controls have separate activation requirements.

Audit and evidence

Every change is recorded in the Organization security activity log as a policy event with the actor and the before and after tool lists. Each affected agent's configuration history also shows the change, and the agent audit blast radius shows the tool as dormant with its source scope.

Imports, exports and templates

Organization and Team grants stay with their scope. Restricted exports use archive version 3, which older importers reject. They and cloned templates carry restriction intent without granting the source capabilities. Imported agents and template hires receive a core-only agent policy and remain inactive pending destination administrator review. Destination inheritance applies immediately. Agent ownership transfer is refused while restricted; reviewed workspace moves require tool-policy management authority.

What this does not cover

• A server added under a different name is a different server until you deny it too. Denying a server does not stop the platform connecting to it for discovery, only agents using it.
• Denying one code tool does not remove sandbox code execution while other code tools or custom tools remain allowed.
• Approved-operations-only execution is a later phase. A selected tool can provide an alternate route to an operation another tool would have performed.
• The installation-wide intelligence tier blacklist is separate and operator-managed. If its lists cannot be loaded, agents keep using the last loaded lists for up to an hour and then lose every tool except the core loop tools until the lookup recovers.