Build a security view of every tool call before you add more tools. Model Context Protocol (MCP) is a protocol that lets an AI application discover and call external tools and data services. A tool-using agent is an AI application that selects a tool and supplies its arguments to complete a task. This connection improves usefulness, but it also turns tool descriptions, call arguments, credentials, and returned data into security-relevant parts of one system.
For a development team, the question is not whether an MCP server is remote or local. The question is which identity, permission, and evidence apply when the agent causes a tool to act. The course will help you operate that boundary without losing auditability or control.
At Northbridge Health, the CareOps Agent can use JiraMCP, DriveMCP, and a local KubeAdminMCP. A malicious instruction can enter through metadata that looks like ordinary tool information, influence the agent’s selection, and reach an upstream service under the MCP server’s credentials. The visible outcome may be a normal file retrieval, while the underlying authorization path exceeds the requesting engineer’s access. Trace where the request gains authority and where evidence disappears:
Simulated — attack chain:
Tool metadata is the description, parameter schema, and annotations that explain a tool to the agent. Because the agent reads this material as context, an attacker who changes it can attempt to steer actions across connected servers. Tool output and copied ticket text carry the same risk when they enter the agent context.
A server with a broad service credential creates a second problem. The upstream service may see the server identity rather than the engineer who requested the action. This is a confused deputy, where a component uses its own authority for a request that should have been limited by the caller’s authority. The incident record shows how these weaknesses combine:
Simulated — internal incident note: