Eigma
EN 中 DE
Coding Agents From First Principles 打开 Eigma
目录 MCP servers and their boundaries

Workspace setup

MCP servers and their boundaries

A connected server's boundaries are specified, not enforced. The Model Context Protocol says so in its own words: it "cannot enforce these security principles at the protocol level", and leaves consent flows, authorization and access control to implementors1. Its architecture does define a real isolation rule, that a server should not be able to read the whole conversation or see into other servers, with the full history staying in the host and the host enforcing the boundaries2. Capabilities are negotiated explicitly at initialization and both sides must respect what was declared for that session2.

Which obligations are binding is worth reading carefully, because the strong requirements and the party that carries them do not line up with intuition.

Requirement Level Carried by
Validate inputs, rate limit, sanitize outputs MUST server
Refuse tokens not issued for this server MUST server
Treat tool annotations as untrusted MUST client
Show tool inputs and confirm sensitive calls SHOULD client
Keep a human able to deny an invocation SHOULD host
Show a local server's exact start command, for one-click local configuration MUST client

The untrusted-annotation rule is the one to internalise. Descriptions of tool behaviour, annotations included, are to be treated as untrusted unless they come from a server you trust1, and clients must do the same3. Tools are model-controlled by design, and the specification asks for a human able to deny an invocation while mandating no particular interaction model3. Local servers are ordinary binaries on your machine running with the client's privileges, which is why a one-click install must show the exact command in full and require approval4.

The boundary is the non-interactive case and the unmeasured remainder. In Claude Code, project-scoped servers from untrusted workspaces prompt for approval in an interactive session but load without prompting under a print or SDK run5, so a review you rely on may simply not happen in automation. Two things this volume could not source: there is no figure for how often tool-description injection is actually observed in the wild, and no documented account of the context cost of a connected server's tool definitions, so the claim that servers crowd the tool list is left unasserted here. Cross-tool comparison is also out of reach, since no equivalent gating documentation was available for Cursor or Copilot.

参考文献

  1. [1]Model Context Protocol specification
  2. [2]MCP architecture
  3. [3]MCP server tools
  4. [4]MCP security best practices
  5. [5]Claude Code MCP documentation
测验

  1. Who enforces the Model Context Protocol's security principles?

    • The host and the implementations
    • The protocol itself, at the transport layer
    • The server, through its capability declaration

    The specification says it cannot enforce these security principles at the protocol level and leaves consent, authorization and access control to implementors, while the host enforces the isolation boundaries.

  2. Server obligations in the specification are written as MUST, while much of the client-side security guidance is only a ____.

    • SHOULD
    • MUST NOT
    • MAY

    Validating inputs, rate limiting and refusing tokens issued elsewhere are server MUSTs, while showing tool inputs and keeping a human able to deny an invocation are only SHOULDs.

评论

还没有评论，来说第一句吧。