MCP Architecture and Where Risk Concentrates
Model Context Protocol defines a client-host-server architecture: a host application, typically an AI assistant or agent runtime, connects to one or more MCP servers through a client component embedded in that host. Communication between client and server occurs over JSON-RPC 2.0, using either a local stdio transport or a remote HTTP-based streaming transport.
MCP servers expose functionality to the connecting agent through three primitives: tools, which are executable functions the agent can invoke; resources, which are readable data the server can inject into the model's context; and prompts, which are reusable prompt templates supplied by the server. At connection time, a server advertises its available tools, including names, descriptions, and input schemas, and the agent uses this metadata to decide when to call a given tool.
For a security engineer, three areas concentrate most of the practical risk. First, tool execution logic runs entirely on the server side, so approving an MCP server is effectively approving that server's own code and infrastructure, not just its declared schema. Second, the scope of data exposed through resources is set by the server implementation rather than constrained by the protocol itself, so two servers built for the same task can expose very different amounts of underlying data. Third, authentication strength varies by transport: local stdio servers commonly rely on process-level trust with no independent authorization layer, while remote HTTP servers use token-based authorization, with the specification referencing OAuth 2.1 concepts for this transport in a later revision. These are structural characteristics of the protocol, not implementation defects, but they mean the protocol alone provides no guarantee about the actual behavior of any given server.
Governance and the Approval Workflow
MCP server approval should follow a documented workflow rather than an ad hoc review. Each server's tools and resources should be mapped to a specific business use case and data classification before access is granted; approving a server because it is popular or vendor-supplied skips the step that actually determines risk. Because MCP's core specification does not mandate a standardized audit-trail or compliance logging format, the responsibility for verifying auditability sits with the reviewing team, not the protocol.
Approval is not a one-time event. Tool definitions and permission scopes can change after a server has been deployed, outside of any formal change-management process, since the server operator controls what is advertised at connection time. A defined re-audit cadence, tied to the same checks used during initial approval, is necessary to catch this kind of scope drift.
MCP-specific review criteria are more effective when aligned with existing enterprise AI risk frameworks, such as NIST's AI Risk Management Framework governance functions, rather than treated as a separate exception process. This keeps MCP approval inside established risk ownership and incident-response structures, including clear attribution of which team owns response when an agent's tool call produces an unintended action.
Runtime governance after approval. Runtime governance platforms, including Trussed AI, address the portion of this problem that sits after approval: enforcing least-privilege scopes on approved MCP servers at the point of tool invocation, and producing audit logs that map tool calls to specific agent identities and sessions. This does not replace the pre-approval audit described above; it operates on servers that have already passed it.