MCP Server
An MCP server is a program that exposes tools, data resources, and prompts to an AI model through the Model Context Protocol, the open standard Anthropic published in November 2024. When an AI agent needs to read a file, query a database, or call an external API, it does so by invoking a capability that an MCP server advertises. The server sits between the model and the underlying system, translating the model's structured requests into real actions. Because an MCP server often holds broad credentials to the systems it fronts, its authorization model is a primary security concern for agentic deployments.
How an MCP server operates
An MCP server declares a set of tools (functions the model can call), resources (data the model can read), and prompts (templates the model can use). The host application connects to the server over one of the protocol's transports, either standard input/output for a local process or HTTP with server-sent events for a networked server. The model, mediated by the host, then calls the server's tools with structured arguments and receives structured results. A single agent commonly connects to several MCP servers at once, giving it reach into email, code repositories, ticketing, and internal databases through one interface.
Where the security boundary sits
The risk in an MCP server is the gap between the credentials it holds and the requests it will honor. A server with a broad database token will run whatever query an instruction tells it to run, including instructions smuggled in through a poisoned document or tool description. DeepInspect inspects the HTTP-transport traffic between an agent and a networked MCP server or model endpoint, enforcing identity-aware policy on each call and recording a per-decision audit record. Local STDIO-transport execution sits outside that HTTP boundary, so MCP server hardening (least-privilege credentials, tool-description validation) remains a separate control that runs alongside the gateway.
Related reading
- MCP Security Best Practices: Authorizing and Auditing Model Context Protocol Traffic
The Model Context Protocol gives an LLM a standard way to call tools, and over HTTP transport those calls are AI traffic you can authorize and audit. This covers the practices that matter at the request boundary: verify identity on every call, scope tools per role, treat tool descriptions as untrusted, fail closed, and log per decision. It also marks the line where local stdio servers fall outside a gateway.
- MCP Server Security: Hardening a Model Context Protocol Server You Operate
Running your own MCP server puts you in charge of who can reach its tools and what those tools can do. This guide covers server-side hardening: authenticating callers, authorizing each tool invocation, containing the confused-deputy risk, restricting tool egress, and deciding what belongs on the HTTP transport versus a locked-down local process. It closes with the enforcement layer that governs MCP traffic crossing the network.
- Model Context Protocol Security: How the MCP Transport Layer Changes the Inspection Boundary
The Model Context Protocol standardizes how an LLM client connects to tool servers and exchanges context, tool calls, and tool results. The transport layer carries the agent identity, the tool call payloads, and the tool return values. The inspection boundary an MCP deployment owes is the HTTP leg between the MCP client and the MCP server. This piece walks through the transport modes MCP supports, the inspection target on each, the identity-aware policy decisions the deployment commits per call, and the audit record format that survives an Article 12 review.