Trust Zones in an MCP Exchange
A tool result is data the server chose to send, not a message the host already trusted. Draw the zones before you draw the arrows. Locate the trust zones in an MCP exchange (user and host, client, server, upstream systems, and the model) and say which ones the host controls outright. Explain why tool descriptions, annotations, icons, results, resource contents, and discovery instructions are untrusted input the moment they enter the model's context. Treat clientInfo and serverInfo as self-reported, display-only identity that a trust decision must never rely on. Recognize and refuse an instruction embedded inside one server's content that asks the host to call a different server's tool. Apply the local-server consent rule from SEP-1024 and the stdio and DNS-rebinding rules that keep a local MCP deployment from becoming an attacker's foothold. A host that supports tools has agreed to let a model act through code it did not write. The servers behind that code range from a script a teammate published last week to a hosted product run by a company the user has never met, and every one of them can be connected with the same few lines of configuration. Once connected, a server is a full participant in the conversation: it names its own tools, writes its own descriptions, and decides what text comes back from…
Trust Zones in an MCP Exchange: A tool result is data the server chose to send, not a message the host already trusted. Draw the zones before you draw the…
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.