Block model providers and unapproved agents

A workflow for AI Agent Security

Everything is allowed by default: each policy or access control blocks specific actions, and anything nothing covers is permitted. That means an empty policy list is an unrestricted environment, and every new AI tool that appears is allowed until you act on it. This workflow shows you how to block a model provider, block an unapproved agent, and control the MCP servers your agents can use.

Scope of this guide

This workflow covers four ways to apply control: blocking an LLM endpoint, a policy rule against a model provider's traffic, blocking a named agent, and setting access on an MCP server. It does not cover managing list contents or the details of every rule condition.

Prerequisites

You have administrator access to the tenant.
You have completed a first-pass inventory, so you know which agents, LLM endpoints, and MCP servers are in use.
You have agreed which model providers, agents, and MCP servers your organization approves.

Steps

Step 1: Check what is already covered

Go to Protection > Policies.
Select the BeyondTrust Managed tab to see the curated policies BeyondTrust supplies and maintains. Check whether one already covers what you intend to block.
Select the Customer Managed tab and review the Status column. A policy at Off blocks nothing, and a policy at Audit records without blocking, whatever its name says.

Step 2: Block a model provider's host

Go to Visibility > LLM Endpoints.
Find the provider's host and select Set access.
Choose Blocked for devices in these tags, then add the tags whose endpoints must not reach the host.
Select Save block.

The block applies on Windows and macOS endpoints. A Windows endpoint blocks only when its coding-agent traffic is redirected to the inspection proxy, so confirm Windows traffic redirect is on for those endpoints under Settings > Administration > Fleet defaults.

To lift the block later, select Set access again, choose Not blocked, and select Clear block.

Step 3: Block a model provider with a policy rule

Use a policy rule instead of an LLM endpoint block when you need to audit first, or to match more than the host.

Go to Protection > Policies and select New policy.
Enter a Policy name and a description, then select Build the rules.
Under Enforcement mode, choose Audit.
Select the subject and choose Any AI agent.
Select the action and choose opens a network connection to block the destination outright, or makes an HTTPS request to match on method, path, and content.

opens a network connection matches the raw connection before any TLS, so it works whether or not traffic is inspected, but it can only block a destination. makes an HTTPS request checks a host-only rule as soon as the connection starts, but matching on method, path, or content needs decrypted traffic, so it works only where TLS inspection applies.
Enter the provider's host as the target.
Select Review & test, check the replay results, then select Save policy and Publish policy.
Attach the policy to the endpoints it should cover: select the policy on the Policies page, select the Attachments tab, then select Attach to endpoints or Attach tags. A published policy reaches only the endpoints and tags it is attached to.

Step 4: Block an unapproved agent

Go to Visibility > AI Agents.
Select the agent you want to stop to open its details panel.
Select Block agent….

The button is unavailable until the agent's executable path has been observed on an endpoint, because the block works by stopping that executable from running.
Review the rules in the Create blocking policy? dialog, then select Block agent.
Attach the new policy to the endpoints that need it: open it from the Policies page, select the Attachments tab, then select Attach to endpoints or Attach tags.

The policy blocks from the moment it is attached. It is created at Block rather than Audit, so attach it to a small group first if you are not certain nobody relies on the agent.

Step 5: Control the MCP servers agents can use

AI Agent Security controls MCP servers one at a time. There is no allow-list setting that blocks every server you have not named, so a server that first appears after you finish this step is allowed until you set access on it.

Go to Visibility > MCP Servers.
Select a server you have not approved to open its details panel.
Check its tools and recent activity before you act. A server with no calls in 30 days is unused, so blocking it is unlikely to disrupt anyone. A server with recent activity needs the opposite consideration.
Select Set access.
Choose the access level: Allow, Monitor, Require approval, or Block. The options are described below.
Choose All tools, or Only these tools and select the tools.
Under Apply to, choose All endpoints, or These tags and add the endpoint tags.
Select the button that confirms your choice, such as Block [server name] or Start monitoring.
Repeat steps 2 to 8 for each server outside your approved set. For a server that has not been discovered yet, select Add server on the MCP Servers page and describe it.

The access levels work as follows:

Option	Description
Allow	Removes any control. Every tool call is permitted.
Monitor	Records tool calls and blocks nothing.
Require approval	Stops matching tool calls, but a developer working through a coding agent gets a link to request a time-bounded exception and approve it.
Block	Stops matching tool calls.

Choose Monitor first for any server you are not certain is unused, and move it to Block once you have reviewed what it recorded.

Verify the results

Confirm each new policy shows the status you intend in the Status column, and Block once you are ready for it to block. On the MCP Servers page, check the Access column for every server outside your approved set, and check the Enforcement gaps card, which counts servers whose control is not yet enforcing on every endpoint.

Then have a developer attempt a blocked action, such as reaching the blocked model provider, launching the blocked agent, or calling a tool on a blocked MCP server, and confirm it fails.

Next steps

Move each policy from Audit to Block once you have reviewed what it caught.
Review the Exception Requests queue for legitimate actions your new controls are blocking.
Re-check Visibility > MCP Servers and Visibility > AI Agents regularly for tools that appear after your controls are in place.