If you wired a Model Context Protocol server into Claude, Cursor, or your own agent this year, you added a new integration to your stack. What most teams do not register is what kind of integration it is. An MCP server does not sit behind an API boundary the way an ordinary third-party service does. Its output, including its tool descriptions, flows straight into your agent's context window as trusted content, and in the common local case it runs inside your agent's process with your agent's privileges. It is closer to a browser extension than to a REST dependency.
This post is for founders and engineers at pre-seed and seed startups who are shipping agent features and connecting MCP servers to move faster. It is not a protocol tutorial. The official documentation covers the wire format. This is about posture: why every MCP server you connect should be treated as an untrusted third party, what went wrong across the ecosystem in the first half of 2026, and the specific controls a small team can put in place without a platform team.
The core claim is simple. In a normal service call, the data crosses a boundary you control. In an MCP call, the server's output becomes instruction inside your model's context. That inversion is the whole problem, and it is why 2026 has been a year of MCP disclosures.
Quick context: what MCP is in 2026
MCP is the open standard, introduced by Anthropic in late 2024, that lets AI applications connect to external tools and data through one uniform protocol. By 2026 it is everywhere. Claude, Cursor, VS Code, Windsurf, and Gemini-CLI all speak it, and there are thousands of community servers for GitHub, Postgres, Slack, filesystems, and more. The 2026-07-28 release candidate is the largest revision of the protocol since launch, with an authorization model that aligns more closely with OAuth 2.1 and OpenID Connect.
Adoption outran hardening. The same year MCP became the default integration layer for agents, researchers mapped a threat surface most adopters never modeled: poisoned tool descriptions, silent post-approval swaps, a systemic command-execution flaw in every official SDK, and a set of OAuth pitfalls the specification now explicitly forbids. Takeaway: MCP is production infrastructure now, so it needs a production threat model, not a demo-day one.
1. The trust boundary, not the wire format, is the risk
When your service calls Stripe, Stripe's response is data. Your code decides what to do with it. When your agent calls an MCP tool, the tool's description and its returned output land inside the model's context, and the model treats that text as part of its instructions. There is no clean boundary between "the server's data" and "what the agent should do next." CyberArk's research team put the consequence plainly in a 2026 write-up titled no output from your MCP server is safe: any field the server controls, tool names, descriptions, arguments, results, error strings, is a potential injection channel.
This is why the usual mental model fails. Teams apply API-dependency thinking to MCP: check the vendor, read the docs, trust the response schema. But the response is not consumed by deterministic code that ignores stray instructions. It is consumed by a language model that follows instructions by design. Wiz's 2026 MCP security overview frames prompt injection as the common thread across nearly every MCP attack, delivered through a poisoned description, a manipulated output, or untrusted data the model reads at runtime. Takeaway: model every MCP server as an untrusted third party with a direct line into your agent's decision loop, and design controls from that assumption.
2. Tool poisoning: instructions hidden where the user never looks
Tool poisoning is the cleanest illustration of the trust-boundary problem. A tool description is text returned by the server in response to a tools/list call. It enters the agent's context as trusted content, but the human operator almost never reads it. An attacker who controls a description can hide instructions inside it, and the model reads and acts on them. Invariant Labs coined the term in April 2025 and demonstrated a working attack: a malicious server sharing an agent context with a legitimate WhatsApp server used a poisoned description to silently read and export a user's entire message history.
The industry has since formalized the risk. It maps to ASI01, Agent Goal Hijack, in the OWASP Top 10 for Agentic Applications, because the attack redirects the agent's goal using content the user cannot see. The defense has to operate at the description layer itself. Validate tool descriptions against a known-good baseline, detect anomalous content, and alert when a description changes between sessions. Invariant Labs released mcp-scan, an open-source scanner that flags poisoned descriptions in your MCP configuration. Takeaway: read the tool descriptions your agent is trusting, and scan them on every registration, because that text is executable intent.
3. The rug pull: approved on Monday, malicious on Thursday
A rug pull weaponizes the gap between approval and execution. The MCP specification includes a notifications/tools/list_changed mechanism that lets a server push updated tool definitions after a client has connected. By default there is no re-approval trigger, no version pinning, and no content hash on tool definitions. So a server can serve a clean, benign description while a developer reviews and approves it, then silently deliver a malicious version later. Nothing in the base protocol forces the client to notice.
This is not theoretical, and it is worse when it rides the software supply chain. Researchers documented a widely installed email-server MCP package that pushed an update which silently blind-copied every agent-sent email to an attacker-controlled domain. It passed standard review at install time because the malicious behavior only appeared in a later version. Same pattern as a compromised npm dependency, except the payload is instructions to your agent rather than code in your bundle. The defense is version discipline: pin the exact server version, hash the tool definitions you approved, and force a human re-review when either changes. Practitioner opinion: treat MCP servers with the same change-control rigor you would apply to a production dependency, because that is what they are. Takeaway: approval is not a one-time event when the server can rewrite itself after you say yes.
4. The STDIO flaw that shipped in every official SDK
On April 15, 2026, OX Security disclosed a systemic vulnerability in MCP's STDIO transport, covered the next day by The Register. The finding: the official SDKs pass user-controlled configuration values in the command field directly to shell execution without sanitization, across the Python, TypeScript, Java, and Rust SDKs. The command runs on the host even when the target process fails to start as a valid MCP server. Anyone who can influence a server's configuration can achieve arbitrary command execution on the machine running it.
The scale is what made this a supply-chain event rather than a single bug. Per the OX Security and Cloud Security Alliance analysis, the affected SDKs account for more than 150 million package downloads, roughly 7,000 publicly reachable servers, and an estimated 200,000 vulnerable deployments, with at least 14 CVEs assigned including CVE-2026-30623. Affected clients included Cursor, VS Code, Windsurf, Claude Code, and Gemini-CLI. Anthropic, per reporting, confirmed the behavior is intentional and considers restricting which commands can appear in the command field to be the developer's responsibility. Practitioner opinion: intentional-by-design is cold comfort if any config value in your agent's path is attacker-influenceable, so the burden really is on you. Takeaway: never let untrusted input reach the MCP command field, allowlist the exact commands a client may spawn, and sandbox local servers.
5. Token passthrough and the confused deputy
Two OAuth pitfalls appear so often that the specification names and forbids them. The first is token passthrough: an MCP server accepting a token from a client without validating that the token was issued specifically for that server, then forwarding it downstream. The security guidance states that MCP servers must not accept tokens that were not explicitly issued for the MCP server. Passthrough bypasses audience checks, rate limiting, and request validation on the downstream API, and it poisons your audit trail because downstream logs show the wrong originator.
The second is the confused deputy. When an MCP proxy server uses a static client ID with a third-party authorization server, allows clients to dynamically register their own IDs, and the third party sets a consent cookie, an attacker can craft a link that reuses the existing consent cookie to skip the consent screen and redirect the authorization code to an attacker-controlled URL. The fix the spec requires is per-client consent enforced before the third-party flow, plus exact-match validation of every redirect_uri with no wildcards. Takeaway: validate token audience on every inbound call, enforce your own consent screen per client, and match redirect URIs exactly, per the authorization specification.
6. SSRF: your agent as a proxy to the metadata endpoint
MCP clients perform OAuth metadata discovery by fetching URLs the server supplies: the resource_metadata URL in the WWW-Authenticate header, the authorization_servers URLs, and the token and authorization endpoints. A malicious server can point any of these at internal resources. The highest-value target for a cloud-hosted agent is the link-local metadata endpoint at 169.254.169.254, which on AWS, GCP, and Azure can return IAM credentials and instance metadata. A single crafted discovery response can turn your agent into a credential-exfiltration proxy that sails past your network perimeter.
The specification is direct about the mitigations. Clients should require HTTPS for OAuth URLs outside loopback, and should block private and reserved IP ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, link-local 169.254.0.0/16, and loopback. It warns against hand-rolling IP validation, because encoding tricks in octal, hex, and IPv4-mapped IPv6 defeat naive parsers, and recommends routing agent egress through a proxy that blocks internal destinations. On the cloud side, enforce IMDSv2 so the metadata service requires a session token that a blind SSRF cannot easily obtain. Takeaway: constrain where your agent's process is allowed to make outbound requests, and never expose a raw metadata endpoint to a workload that talks to untrusted MCP servers.
7. Session hijacking across stateful servers
When you run multiple stateful HTTP MCP servers behind a shared queue or load balancer, session identifiers become a target. If an attacker obtains or guesses a session ID, two attacks open up. In the impersonation case, they make calls with the stolen ID and the server treats them as the legitimate user. In the injection case, they enqueue a malicious event keyed to that session on one server, and a second server polling the same queue delivers the payload to the real client as an asynchronous response. The client then acts on attacker-controlled content.
The specification sets hard requirements here. MCP servers that implement authorization must verify all inbound requests and must not use sessions for authentication. Session IDs must be secure and non-deterministic, generated with a secure random source, never sequential or guessable. And servers should bind the session to user-specific information using a key format like <user_id>:<session_id>, so a guessed session ID alone cannot impersonate a different user because the user identity is derived from a verified token, not supplied by the client. Takeaway: authenticate every request on its own merits, use cryptographically random session IDs, and bind sessions to a verified user identity.
8. Over-broad scopes multiply one stolen token
The blast radius of a compromised token is decided long before the compromise, at scope-design time. A common anti-pattern is to publish every possible scope in scopes_supported and request them all up front, or to use omnibus scopes like files:*, db:*, or admin:*. A token carrying broad scopes, once leaked through a log, a memory scrape, or local interception, enables lateral access and privilege chaining, and it is painful to revoke because revocation disrupts every workflow at once.
The specification recommends a progressive, least-privilege model instead. Start with a minimal scope set covering only low-risk discovery and read operations, then elevate incrementally through targeted WWW-Authenticate scope challenges when a privileged operation is first attempted. Servers should issue only the subset of scopes actually needed and accept down-scoped tokens. This keeps a stolen token's reach small and makes your audit log reflect real intent per operation. Takeaway: grant the narrowest scope that works, elevate on demand, and never bundle unrelated privileges to preempt a future prompt.
9. A hardening checklist a lean team can actually run
You do not need a platform team to get most of the value. Inventory every MCP server your agents connect to, in every environment, and treat the list as an attack-surface register. Scan tool descriptions with mcp-scan on registration and re-scan on change. Pin exact server versions and hash the tool definitions you approved, so a rug pull triggers a re-review instead of executing silently. Run local servers sandboxed: containers or restricted profiles, minimal filesystem and network access, stdio transport to limit reach, and no untrusted input anywhere near the command field.
On the identity side, validate token audience on every inbound request, enforce least-privilege scopes with on-demand elevation, and match redirect URIs exactly. On the network side, block private and link-local IP ranges from your agent's egress and enforce IMDSv2 so a discovery-time SSRF cannot harvest cloud credentials. Log every tool call and every tool-description change, because the description swap is the signal that a trusted server turned hostile. Practitioner opinion: the highest-leverage first move for a small team is the inventory plus mcp-scan, because you cannot defend a connector you have not written down. Takeaway: these are small, concrete controls, and doing five of them puts you ahead of most teams shipping agents in 2026.
The honest summary table
| Risk | What actually breaks | Minimum control for a lean team |
|---|
| Tool poisoning | Hidden instructions in a tool description hijack the agent's goal | Scan descriptions with mcp-scan on every registration |
| Rug pull | Approved server swaps in a malicious tool definition later | Pin versions, hash tool definitions, re-review on change |
| STDIO command injection | Untrusted config value runs a shell command on the host | Allowlist commands, never pass untrusted input, sandbox |
| Token passthrough / confused deputy | Wrong-audience token or skipped consent grants access | Validate token audience, per-client consent, exact redirect_uri |
| SSRF to metadata | Discovery URL points the agent at 169.254.169.254 | Block link-local and private IPs, enforce IMDSv2 |
| Session hijacking | Guessed session ID impersonates a user or injects events | Random session IDs, bind to verified user, auth every request |
| Over-broad scopes | One leaked token grants lateral, hard-to-revoke access | Least-privilege scopes, elevate on demand |
Stage-specific recommendation
Pre-seed. You are probably running local MCP servers in an IDE and one or two in a prototype. Do three things: write down every server you have connected, run mcp-scan against your configuration, and make sure no untrusted input can reach a server's command field. That is an afternoon of work and it closes the two attack classes most likely to hit you first, poisoning and the STDIO flaw.
Seed. You are shipping an agent feature to real users and connecting remote MCP servers over HTTP. Add identity discipline: validate token audience, enforce least-privilege scopes with on-demand elevation, and pin and hash the tool definitions you depend on. Put your agent workloads behind an egress policy that blocks link-local and private IP ranges, and confirm IMDSv2 is enforced on every instance an agent can reach.
Series A. You have multiple stateful servers and a growing connector catalog. Formalize it. Maintain an MCP server register as a first-class asset inventory, enforce per-client consent on any proxy, bind sessions to verified user identities, and wire tool-description-change alerts into your monitoring. At this stage the rug pull and session-hijacking classes matter, and both are detectable if you are logging the right events.
If you want a second opinion on your MCP and agent attack surface
MatrixGard runs a free 20-minute review of your agent and MCP integration surface for pre-seed and seed founders. Which servers you have connected, where untrusted input can reach a tool or a command field, your token and scope posture, and the two or three changes that most reduce your risk. My honest read in 20 minutes, no NDA required for the first conversation. Send a note.
Avinash S is the founder of MatrixGard. Fractional DevSecOps for pre-seed and seed startups across India, the GCC, the UK, and the US. Almost a decade of building, breaking, and securing cloud infrastructure for fintech, healthtech, and SaaS workloads.
Methodology note. Attack classes and required controls are drawn from the official MCP security best practices and authorization specification published at modelcontextprotocol.io. The STDIO command-injection disclosure, deployment counts, and CVE details are as reported by OX Security, the Cloud Security Alliance, The Register, and The Hacker News. Tool-poisoning and rug-pull descriptions follow public research from Invariant Labs and the Wiz and CyberArk security teams. Where I state practitioner opinion rather than the specification's text, I have labelled it inline. This is a risk-prioritization guide for lean teams, not an exhaustive MCP security standard, and it does not replace a formal threat model for your specific deployment.
