Tool Filtering

A personal AI agent is an AI system that acts on behalf of one individual, learning their preferences over time and executing multi-Tool filtering is the practice of limiting which tools an AI agent can discover or use based on the agent’s identity, the user it represents, applicable policy, and the circumstances of the request.

In the Model Context Protocol (MCP), tools are functions that an MCP server makes available to an AI application. They may allow an agent to retrieve records, query databases, modify files, send messages, create tickets, execute code, or perform other actions.

An MCP client ordinarily learns about these capabilities through a tool-listing request. Tool filtering can restrict that list so the agent receives only the tools appropriate for its role, user, environment, or task. A corresponding control should also evaluate each attempted tool invocation before the MCP server processes it.

Tool filtering therefore has two related forms:

• Discovery filtering: Restricts which tool definitions are presented to the agent.
• Invocation filtering: Permits or denies an attempted tool call at runtime.

Discovery filtering reduces the choices available to the model. Invocation filtering supplies the security boundary.

How Tool Filtering Works

An MCP server may expose many tools through a single connection. A customer-service server, for example, might offer separate tools for reading an account, issuing a refund, changing an address, and closing an account.

Without filtering, every connected agent may receive the entire tool catalog, even when its work requires only one or two functions. Tool filtering narrows this catalog according to established rules.

A typical process includes the following steps:

1. The MCP client requests a list of available tools.
2. The control point identifies the agent and, when applicable, the user directing it.
3. Policy evaluates relevant attributes, which may include:
   • Agent or workload identity
   • User identity, role, or group
   • Target MCP server
   • Requested tool
   • Deployment environment
   • Device or workload posture
   • Time, location, or other runtime conditions
   • Content inspection findings
4. The client receives an approved tool list, with prohibited or unsuitable tools removed, blocked, or modified.
5. Each subsequent tool call is evaluated again before it reaches the MCP server.
6. The decision is recorded with the identities, requested tool, policy result, and other transaction details.

The second evaluation is essential. An agent may attempt to call a tool by name even when that tool did not appear in its discovery response. A secure implementation must therefore enforce policy when the tool is invoked, rather than relying exclusively on the filtered listing.

Why Tool Filtering Matters

AI agents select and invoke tools according to prompts, model reasoning, retrieved material, and application instructions. Each additional tool gives the agent another means of affecting enterprise systems.

An agent that needs to read a support ticket does not necessarily need permission to delete it. An agent that prepares a payment should not automatically have authority to approve one. If both tools appear in the same catalog and share the same credentials, an erroneous or manipulated instruction may cause the agent to exceed its intended function.

Tool filtering helps organizations:

• Reduce the number of sensitive functions exposed to an agent.
• Apply least privilege at the level where agent actions occur.
• Separate read-only tools from tools that create, alter, or delete data.
• Tailor available tools to the agent’s role and the user’s authority.
• Limit the consequences of prompt injection or faulty agent behavior.
• Preserve clearer records of which tools an agent could discover and invoke.
• Require additional review or approval for consequential actions.

These controls are especially important when one MCP server offers numerous tools behind a common endpoint. Permission to connect to the server should not be treated as blanket permission to use every capability it exposes.

Tool Filtering and Authorization

Tool filtering and authorization address different parts of the access process.

Filtering shapes the tool catalog presented to the agent. Authorization determines whether a particular request may proceed. The distinction matters because tool descriptions influence model behavior, while authorization protects the underlying resource.

A sound control model applies both:

• The agent sees only tools relevant to its permitted work.
• Every tool call receives a fresh authorization decision.
• The MCP server or gateway rejects calls that do not satisfy policy.
• Credentials issued for one server, user, or purpose cannot be reused elsewhere.
• Logs preserve the agent, user, tool, destination, and decision involved.

Filtering can reduce exposure and guide tool selection, but it should not be regarded as a substitute for enforced access control.

Tool Filtering and Content Inspection

Tool definitions contain names, descriptions, and input schemas that help an AI model decide when and how to use a tool. A compromised or poorly governed MCP server can place misleading instructions within this material, a technique commonly described as tool poisoning.

Content inspection can examine tool listings for suspicious instructions, sensitive information, or prohibited material. Depending on the inspection system and policy, the control point may allow, block, or modify the listing before it reaches the agent.

This content-based process complements identity-based filtering:

• Identity and access policy determines who may reach the MCP server or invoke a protected capability.
• Content inspection examines what appears in tool listings, tool inputs, and tool outputs.
• Runtime enforcement applies the resulting decision before the interaction continues.

Neither process resolves every risk alone. Identity does not establish that tool content is safe, and content inspection does not establish that the requesting agent is authorized.

Common Challenges With Tool Filtering

• Discovery without enforcement: Removing a tool from the returned list may discourage its use, but it does not prevent a direct invocation unless the server or gateway also checks the call.
• Overly broad server permissions: A policy may permit access to an MCP server while leaving every tool behind that server available.
• Changing tool catalogs: MCP servers may add, remove, or revise tools. Policies and inventories must account for those changes.
• Ambiguous tool descriptions: Poorly written descriptions can cause an agent to select an unsuitable tool even when the catalog has been filtered.
• User-agent attribution: A user-driven agent may require access based on both the agent’s identity and the user’s authority.
• Inconsistent enforcement: Filtering performed only in an agent interface can be bypassed if another client connects directly to the MCP server.
• Insufficient audit detail: Server-level logs may show that an agent connected without identifying the particular tool it attempted to use.
• Content-based attacks: A permitted tool listing may still contain malicious or deceptive instructions.

How Aembit Helps

Aembit places its MCP Identity Gateway capability, part of its IAM for Agentic AI Platform, between agents and MCP servers, providing a central point for identity validation, policy evaluation, credential handling, content inspection, and audit.

1) Agent and User Identity Validation

Aembit verifies the MCP client and authenticates the user through the organization’s identity provider. For user-driven agents, these signals provide the Blended Identity context needed to evaluate both parties to the request.

2) Policy Enforcement for MCP Access

The MCP Identity Gateway evaluates Aembit access policies before forwarding an MCP request. Policies determine which authenticated agents and users may connect to protected MCP servers and resources.

3) Inspection of Tool Listings and Calls

When Content Security is configured, the gateway sends MCP tool listings, tool-call inputs, and tool-call outputs to the selected inspection service. The service returns an allow, block, or transform verdict, which Aembit enforces in the request path.

This permits organizations to block a dangerous tool listing, remove or redact prohibited content, or prevent a risky invocation from continuing.

4) Credential Isolation

Aembit obtains and presents the appropriate MCP server credential without disclosing that credential to the agent. Credentials remain separated by user and destination, reducing the chance that access granted for one connection can be reused for another.

5) Centralized Audit Records

Aembit records the agent identity, user identity, target MCP server, requested tool or resource, policy decision, and relevant content-security result. Security teams can review these records in Aembit or forward them to a SIEM.control.