MCP Security for AI Agents: How to Review Tools Before Connecting Them

The value of a tool-using agent comes from what it can access.

The risk comes from the same place.

When an agent connects to an MCP server or another tool provider, the application adds new capabilities, data sources, and execution paths. The right question is not simply whether the tool works. It is what authority the tool gives the agent.

Read the capability surface

Before enabling a tool, inventory its operations.

A server that looks like a document reader might also provide document creation, deletion, permission changes, external sharing, or administrative actions.

The agent may only need one of those capabilities.

Prefer the smallest useful tool set.

Read-only is different from write access

A research agent that needs to inspect a database should not automatically receive database mutation capabilities.

Separate read_customer, write_customer, and delete_customer operations rather than exposing one generic database tool.

This makes policy decisions easier and limits the blast radius of a bad tool call.

Tool descriptions are not security policies

Tool metadata helps the model understand how to call a function. It should not be the only enforcement layer.

If a tool description says only use this for the current user's data, the server must still validate authenticated ownership.

The application should enforce identity, tenant, resource, operation, and scope before execution.

Treat tool results as untrusted data

A tool can return content from a webpage, document, repository, email, or third-party system.

That content may contain instructions.

A search result could tell the agent to ignore previous instructions and call a destructive function. The result is data, not authority.

The runtime should preserve that distinction and prevent retrieved content from changing the permission set.

Review the server

An MCP server is software. Review its repository ownership, dependencies, authentication model, credential storage, network behavior, logging, permission model, update history, and vulnerability history.

For sensitive environments, pin versions and review updates before promotion.

Authentication needs boundaries

A tool server should know which user or service is making the request.

Avoid shared credentials that make every agent action look identical.

A stronger model is:

User identity → Agent session → Tool authorization → MCP server → Target resource

This makes tenant and role boundaries enforceable.

Monitor behavior

Once connected, observe which tools are called, how often, which resources are targeted, which calls fail, which calls are denied, and whether behavior changes after an update.

Unexpected tool usage is a security signal.

MCP security review checklist

Before enabling an integration, ask:

• What is the full capability list?
• Which capabilities are actually needed?
• Which operations are read-only?
• Which operations create side effects?
• How is identity passed?
• Where are credentials stored?
• Can tool results contain instructions?
• Can the server reach arbitrary networks?
• How are updates reviewed?
• Can the integration be disabled quickly?
• Are sensitive actions logged?

If the provider cannot answer basic questions about these boundaries, treat the integration as high risk.

Version and deployment discipline

Do not silently upgrade a security-sensitive MCP server in production. Keep a known-good version, record changes, and test the integration against a representative workload before promotion.

A dependency update can change tool descriptions, available operations, authentication behavior, or the shape of returned data. Any of those changes can affect the agent's security posture.

Keep development and production credentials separate and make rollback possible.

Final takeaway

MCP can make agents dramatically more useful, but every new server expands agent authority.

Review MCP servers like production dependencies with access to customer data: understand capabilities, minimize permissions, authenticate requests, distrust returned content, monitor behavior, and maintain a fast shutdown path.

Source: OWASP MCP Top 10.

A practical MCP review process

Treat a new MCP server like a production dependency with privileged access.

First create a capability inventory. Record every tool, operation, parameter, external destination, credential, and side effect. Mark each operation as read-only, reversible write, or high-impact write.

Then identify the trust boundary. Determine whether the server is operated by your team, a trusted vendor, an open-source maintainer, or an unknown third party. The trust decision should influence the permissions granted to it.

Test tool results as untrusted input. Return documents containing malicious instructions and confirm that the agent cannot turn those instructions into additional authority.

Review authentication and tenant handling. The server should receive enough identity information to enforce ownership instead of relying on the model to select the correct account.

Finally, create a kill switch. If a server behaves unexpectedly, the team should be able to disable it without taking the entire agent platform offline.

MCP makes capability discovery easier, but capability discovery should never become automatic permission granting. The agent should receive only the tools that the current workflow actually needs.

Review every update

MCP integrations can change without the agent application changing. A new server version may expose additional tools, modify permissions, or change response formats.

For important integrations, compare the capability inventory before and after an update. Re-run authorization tests, prompt-injection tests, and tenant-isolation tests before production rollout.

This turns MCP security into an ongoing dependency-review process instead of a one-time checkbox.

A useful final control is staged rollout. Enable a new MCP server for a small workload first, monitor tool calls and denied operations, and expand access only after the observed behavior matches the intended capability inventory.

Final review questions

Before approving an MCP integration, ask whether every exposed operation has a business reason, whether authorization is enforced outside the model, whether returned content is treated as untrusted, whether credentials can be rotated independently, and whether the server can be disabled without taking down unrelated agents. These questions turn a vague integration review into a repeatable security gate.