Once an AI agent is authorized to connect to an MCP server, it can see and call every tool that server exposes. That’s fine when a server does one narrow job. But most real-world MCP servers – GitHub, Slack, Jira, internal platforms – bundle dozens of tools together, and not all of them carry the same risk. An agent that only needs to read data shouldn’t be one hallucinated tool call away from triggering a delete, a payment, or an admin action just because it happens to live on the same server.
That’s the gap MCP Tool Access Control from Aembit closes.
Introducing MCP Tool Access Control
MCP Tool Access Control moves the Aembit IAM for Agentic AI platform from server-level access to tool-level authorization. Administrators can now define exactly which tools an agent is allowed to discover and which tools it’s allowed to execute – without standing up a separate server or proxy for every risk tier.
It works as two independent controls inside an Aembit access policy:
- Visibility (Discovery): Filters the list of tools an agent sees when it calls tools/list, so anything outside its policy simply doesn’t appear.
- Invocation: Validates every tools/call request against policy before it reaches the server, blocking anything outside the agent’s allowed set – even if the agent already knows the tool’s name.
Built to Scale With Your Tool Catalog
Manually ‘allow-listing’ every tool doesn’t hold up once a server exposes dozens of them, so tool access control supports two ways to define policy:
- Exact tool names for precise, one-off rules.
- Glob patterns (e.g.,
get_user*,admin_*) for convention-based rules that automatically cover new tools as they’re added – allow everylist_*call while blocking everydelete_*one, in a single rule.
And because these rules are scoped by the same blended identity Aembit already uses across the platform – user identity, group membership, and workload/agent identity – a developer and a support agent can share the same AI assistant and the same MCP server, yet end up with entirely different tool access.
Defense in Depth, By Design
A few implementation details worth calling out:
- Fail-closed by default. If a policy is missing or malformed, the gateway blocks the call or returns an empty tool list – it never fails open.
- Bypass-proof. The invocation check runs independently of the visibility check, so an agent can’t work around discovery restrictions by guessing a hidden tool’s name and calling it directly.
- Positioned early in the chain. The gateway evaluates tool filtering before deeper inspection layers such as CrowdStrike AIDR, so coarse-grained “Should this agent even see or call this tool?” decisions are resolved before finer-grained content inspection runs.
- Granular audit events. A new application.mcp.contentSecurity.toolFilter event records exactly which rule matched and why – not just that a call was blocked, but the reasoning behind the decision.
Why It Matters
- Least privilege for AI agents. Read access no longer implies write, delete, or admin access just because tools share a server.
- Audit-ready by default. Every filtered discovery and every blocked call is logged with the policy decision behind it – the kind of evidence regulated industries need to show.
- Policy that scales with your tool catalog. Glob-based rules mean new tools inherit sensible defaults instead of falling through the cracks until someone remembers to update an allow-list.
How Are Customers Using Tool Filtering?
A large retail customer that has an autonomous agent, as well as first-level customer support representatives, processing refunds and replacement part shipments wanted to restrict access to various MCP tools. Both agent and reps have access to a couple of MCP servers, each with over 30 MCP tools that allow read, write, update, and delete functions. However, due to the limited scope of the tasks, the Aembit administrator wanted to limit the AI agents used to only three specific MCP tools. The admin created a policy that was agent-based and group-based to only allow for the view and invocation of these tools. All other tools were hidden.
What’s Next
Phase 1 focuses on tool names and patterns. The same architecture is built to extend to MCP’s own tool annotations – like readOnlyHint and destructiveHint – so future phases can weigh not just which tool is being called, but how risky that action actually is.
Get Started
MCP Tool Access Control is available now in the Aembit MCP Identity Gateway, part of the Aembit IAM for Agentic AI platform.
Start with a free Aembit tenant to configure your first policy, or talk to an engineer to walk through it with our team.
Common Questions About MCP Tool Filtering
What is MCP tool filtering?
How is tool filtering different from server-level MCP access control?
• It controls which tools an authorized agent can see in its tool list.
• It controls which tools an authorized agent can actually call.
• It applies these two controls independently, so a tool can be visible but not callable, or callable without appearing in the discovered list.
What happens to a tool that isn’t listed in a policy?
Does tool filtering require changes to my MCP client or server?
What happens if a tool-filtering policy fails to evaluate?
tools/list response returns an empty or reduced list, and the affected tools/call request is blocked. Tool filtering is designed to never fail open.
