What are the three key principles of MCP's security model in revision 2026-07-28?

## What the specification names MCP's security section opens with a short list of principles every implementation is expected to honour. As of revision **2026-07-28** there are exactly **three**. **User Consent and Control.** Users must explicitly consent to, and understand, the data that is accessed and the operations that are performed on their behalf. They must retain control over what is shared and what is invoked, and implementations are expected to surface that clearly rather than bury it in configuration. **Data Privacy.** A host must obtain the user's explicit consent before exposing their data to a server, and must not transmit resource data somewhere else without consent. Data should be protected with appropriate access controls. **Tool Safety.** Invoking a tool is arbitrary code execution on the other side of the connection, so it deserves caution and explicit consent. Descriptive text and behavioural hints a server supplies about its own tools describe intent, not fact, and a client must treat them as untrusted unless the server itself is trusted. ## The fourth principle that is gone Almost everything written about MCP before mid-2026 lists a fourth principle, *LLM Sampling Controls*, which said users should approve any request for the host to run a model completion on a server's behalf, and that a server should not see the whole prompt or conversation. That principle was **deleted in 2026-07-28**, in the same revision that **deprecated Sampling** (migration guidance: integrate directly with LLM provider APIs). Reciting four principles is the fastest way to reveal that you learned MCP from pre-2026 material. Sampling has not vanished — it is deprecated, still in the spec for at least twelve months, and reachable as a `CreateMessageRequest` inside a multi-round-trip input request — but the human-review concerns it carried now sit under **User Consent and Control** rather than under a principle of their own. ## Principles, not conformance requirements The spec says plainly that MCP cannot enforce these principles at the protocol level. That is a statement about what a wire protocol can do. A JSON-RPC schema can require fields, reject malformed params with `-32602`, define error codes such as `-32021` `MissingRequiredClientCapabilityError`, and mandate header/body agreement. It cannot verify that a human read a dialog, that a checkbox was ticked, or that the data placed in a tool argument was data the user meant to share. No message shape can certify a human decision. So the specification converts the principles into guidance for implementors: build robust consent and authorization flows, document the security implications of what you expose, implement appropriate access controls and data protections, and follow security best practices. Note that in **2026-07-28 the security best-practices document moved out of the specification** and into the documentation tutorials — quoting it as normative spec text is a factual error. ## Why the host, specifically The roles make the answer inevitable. The **host** is the application the user is actually using: it owns the user relationship, the interface, the model's context window, and the set of clients. A **client** is a per-server connector living inside the host, with no policy of its own. A **server** sees only what the host chose to put in the request it received — it cannot read the whole conversation and cannot see into other servers connected to the same host. Only the host is positioned to ask a human anything, and only the host knows what the request would expose. Every principle therefore lands on the host as the enforcement boundary, with the protocol supplying material for its decisions. ## Consent is not attached to a connection A second thing 2026-07-28 changed matters here. MCP is now **stateless**: every request is self-contained and carries its own protocol version and capabilities, servers MUST NOT rely on prior requests over the same connection, and an open connection such as a stdio process is explicitly "not a conversation or a session". The `initialize` handshake, `notifications/initialized`, protocol-level sessions and the `Mcp-Session-Id` header were all removed. Consequently a grant cannot be modelled as "this session is approved". It lives in the host's own state, keyed to the user and the server's identity, and is applied to each outbound request the host decides to make. ## What the protocol does contribute It contributes structure and identity rather than enforcement: per-request `io.modelcontextprotocol/protocolVersion` and `io.modelcontextprotocol/clientCapabilities` so a server never guesses what it is talking to; `clientInfo`/`serverInfo`, both explicitly self-reported and untrusted; behavioural hints on tools that clients must treat as untrusted unless the server is trusted; and, for remote servers, an OAuth 2.1 profile with audience-bound tokens and a prohibition on token passthrough. Those give the host evidence. Deciding on it is still the host's job. ## Interview traps Naming four principles; saying the protocol "requires" consent; putting enforcement in the server or in the client library; describing consent as granted at connection time; and citing the best-practices document as part of the specification.