If MCP Is the New HTTP, We Need Its “HTTPS Moment” Now

October 5, 2025 hannesz 0

TL;DR: The Model Context Protocol (MCP) is quickly becoming the universal port that lets AI agents discover tools and act in the world—much like HTTP did for web apps. That’s exactly why an explicit, security‑first revision of MCP is urgent: default‑deny tool access, signed server provenance, mandatory authn/authz, ephemeral credentials, output validation, and tamper‑evident audit must move from “best practices” to normative parts of the spec. Otherwise, the ecosystem will relive the web’s first decade—retrofitting security after incidents, at huge cost.

What MCP is—concisely

MCP standardizes how AI applications (agents, IDEs, desktops) discover tools/resources and call them through a JSON‑RPC data layer over transports like stdio and streamable HTTP. Think “USB‑C for agents”: a uniform way to plug into data sources and actions. Windows is baking MCP into its agent platform; the official docs describe the primitives (tools, resources, prompts), lifecycle negotiation, and transport/auth guidance (OAuth recommended).

Microsoft’s security team puts it plainly: MCP is “essentially JSON‑RPC over HTTP,” which unlocks power but also raises risks like cross‑prompt injection, tool poisoning, and credential leakage—hence their push for proxy‑mediated communication, a central server registry, mandatory code signing, and least‑privilege enforcement.

If MCP ≈ HTTP, what the web taught us

The early web shipped fast and open—and insecure by default. We bolted on TLS, cookie flags, CSP, SameSite, CORS, SRI, permission prompts, and more after attackers had a field day. Agentic computing is at a similar inflection point. MCP integrates agents with file systems, calendars, ticketing, CI/CD, payments—operationally dangerous contexts if the protocol’s defaults aren’t defensive.

Security researchers are already flagging LLM‑specific classes of issues: prompt injection, insecure output handling, and supply‑chain/server poisoning. These map directly to MCP’s tool invocation pathway.

Threats unique to agent + tool ecosystems

  • Cross‑prompt injection (confused deputy): Untrusted content causes an agent to call a powerful tool outside user intent. On MCP, that can equal remote code execution via a server’s exposed capability.
  • Tool poisoning / supply chain: A popular but compromised MCP server steals tokens or exposes over‑scoped methods.
  • Authn/authz gaps: OAuth is optional today; ad‑hoc headers proliferate, leading to inconsistent identity and scope.
  • Credential leakage: Long‑lived tokens sitting in servers that agents can reach.

A security‑first MCP revision: proposals that should be normative

Call it MCP‑S or “MCP 1.x security baseline.” These aren’t bolt‑ons; they belong in the core spec and its conformance tests.

  1. Mandatory strong identity & provenance
    • Code‑signed servers (publisher identity) and immutable tool manifests (no runtime mutation of tool definitions).
    • Version pinning and revocation mechanisms tied to a trusted registry (OS or ecosystem). Microsoft is already modeling this approach on Windows.
  2. Default‑deny tooling with typed contracts
    • Tools must declare precise JSON‑Schema for inputs; clients must enforce schema validation and deny unlisted methods by default.
    • Server can only advertise tools at init; mid‑session changes require explicit re‑consent.
  3. Mandatory authentication & scoped authorization
    • Normative flows (e.g., OAuth/OIDC) with resource‑scoped, short‑lived tokens; bearer‑only or custom headers are non‑conformant except for localhost/stdio dev modes.
  4. Ephemeral credentials by design
    • Per‑tool‑call tokens minted just‑in‑time; no long‑lived secrets stored on servers by default.
  5. Proxy‑mediated enforcement point
    • All client↔server traffic passes a trusted proxy that can enforce policy, capture audit, and gate high‑risk actions with user consent or dual‑control. Windows’ MCP security architecture adopts this model.
  6. Output‑to‑action validation (LLM firewall)
    • Standardize an intent re‑derivation step: a non‑colluding validator checks that the planned tool call matches the user’s instruction and policy. OWASP’s LLM Top‑10 calls for this class of control.
  7. DLP/egress policy as a first‑class concept
    • Destinations allowlists, inline PHI/PII redaction, and regulated residency tags in the protocol (client declares jurisdiction; server enforces).
  8. Tamper‑evident audit & transparency
    • Signed, append‑only logs for each tool call (who/what/when/why), with a user‑visible action transcript for sensitive operations.
  9. Server capability caps & isolation hints
    • Standardized capability classes (“read”, “write”, “execute”, “network”) with recommended isolation levels so hosts can sandbox appropriately.
  10. Security profiles & conformance levels
  • Bronze/Silver/Gold profiles that map to required controls (e.g., “Bronze = OAuth + schema; Gold = code‑signing + proxy + ephemeral creds + DLP + audit”) to drive marketplace trust.

A reference flow (how “MCP‑S” would feel)

sequenceDiagram
  participant User
  participant Agent (Host)
  participant PolicyProxy
  participant MCP Server
  participant Validator

  User->>Agent (Host): Task request
  Agent (Host)->>PolicyProxy: Propose tool call + input (JSON)
  PolicyProxy->>Validator: Re-derive intent & check policy (non-colluding)
  Validator-->>PolicyProxy: OK / Block + rationale
  PolicyProxy->>MCP Server: Call with **ephemeral** scoped token
  MCP Server-->>PolicyProxy: Result (+ signed audit record)
  PolicyProxy-->>Agent (Host): Result + audit pointer
  Agent (Host)-->>User: Action + transparent transcript

Design notes:

  • The server’s tool set and schema are signed, pinned at init; changes require re‑consent.
  • All tokens expire quickly; no standing credentials.
  • PolicyProxy is pluggable (OS‑provided, enterprise‑provided, or both).

Interop pressure is rising—so is security pressure

Two parallel trends are turning MCP from “interesting” to “inevitable”:

  • Platform adoption (Windows’ “Agentic OS” path with a registry and security requirements).
  • Ecosystem gateways/meshes (e.g., Agentgateway, now at the Linux Foundation) that add governance and observability between agents and tools. These exist because policy/security are not yet built into MCP defaults.

At the same time, Agent2Agent (A2A) is becoming a Linux Foundation project, which will multiply cross‑agent communications—and the blast radius—unless security baselines land in the tool layer too.

Migration path that won’t break developers

The MCP docs already define version negotiation during initialization. Use it. Ship security features behind explicit capability flags—then flip the profiles to required as the ecosystem catches up:

  1. Now: Make security capabilities discoverable + easy to adopt (libraries, defaults).
  2. Next: Mark weak auth/unsigned servers as deprecated in registries.
  3. Finally: Require signed manifests + OAuth + proxy‑mediated audit for inclusion in first‑party catalogs/OS registries.

This is exactly how the web nudged sites to HTTPS and modern headers—via deprecation, default warnings, and distribution channels.

A short checklist for builders

  • [ ] Sign server code + manifest; pin tool list at init.
  • [ ] Use OAuth/OIDC; mint ephemeral per‑call tokens.
  • [ ] Enforce strict JSON‑Schema on inputs; default‑deny.
  • [ ] Route calls through a policy proxy; log every action.
  • [ ] Add a validator LLM to check intent→action alignment.
  • [ ] Implement egress/DLP rules and residency tags where needed.
  • [ ] Publish a human‑readable transcript for sensitive actions.

Closing thought

If MCP is our HTTP, then the “HTTPS moment” should not wait a decade. We already know the failure modes; the standards and platform hooks are emerging; gateways exist because demand is here. A security‑first MCP revision—identity, policy, ephemeral credentials, validation, audit—will let agentic apps scale without repeating the web’s painful security retrofit. That’s better for users, for developers, and for every platform betting on agents.

Sources & further reading