492 Exposed MCP Servers: The Agent Security Industry Is Repeating 2016's Ethereum Node Mistake

Contrary to the framing that dominates the conference circuit, the most important number in enterprise AI security is not a model benchmark. It is 492 — the reported count of Model Context Protocol servers found running in production without authentication. No session token. No mutual TLS. A tool endpoint that any autonomous agent can call, and therefore that any attacker impersonating one can call. I have seen this exact posture before. In 2016 I worked a forensic audit of Ethereum nodes with the JSON-RPC interface bound to 0.0.0.0 and no auth layer — dozens of them, sitting on public cloud ranges, executing wallet operations for anyone who typed a curl command. Three years later the same teams shipped "enterprise-ready" infrastructure with the identical failure. The surface mutates. The authentication error does not. The trigger for this piece is Salesforce's Dreamforce 2026 pre-coverage, which leans on a trio of 2026 events: a Hugging Face intrusion by roughly 700 rogue OpenAI agents, an Aurora ransomware crew allegedly arming Cursor's coding agent, and those 492 exposed MCP servers. Read it as a signal, not as evidence. None of those events carries a citation. Two "2026" CVEs — CVE-2026-59822 for an MCP authentication bypass and CVE-2026-42271 for command injection — are asserted as past fact in a piece nominally forecasting a September 2026 conference. Either the text is post-dated, or it is speculative writing generated ahead of the events it claims to describe. I cannot verify it, and I will not pretend to. So I will treat the events as a hypothesis about where the attack surface is heading, and interrogate the structural claim underneath them: that OAuth-based session identity is the wrong primitive for autonomous agents. That structural claim is correct. It is the only part worth the ink. To situate it: MCP is Anthropic's open standard for connecting a language model to external tools and data. The design is deliberately unopinionated about trust. A server exposes tools, a client calls them, and the transport may be local or remote. The protocol specifies message shapes. It does not specify how a server proves it is authorized to be called, or how a client proves it is what it claims to be. That is left to the implementer. And implementers, under ship-fast pressure, left it out. This is the same division of labor that produced the smart contract era's most expensive bugs: the substrate defines possibility, the developer defines safety, and the developer almost always optimizes for time-to-demo. The protocol doesn't fail you. The silence where a standard should be does. One structural bias is worth flagging before the teardown. Conference-preview content is written from the host's point of view, and the host here is a platform vendor. So the piece frames agent security as a Salesforce story, when the parties most exposed are the identity and access management vendors — Okta, Microsoft Entra, CyberArk, Ping — whose entire product lines assume a human as the principal and a session as the unit of trust. That assumption is now wrong, and those vendors, not Salesforce, carry the reengineering burden. The article never mentions them. Nor does it mention the SOC analysts whose triage model breaks the moment agents generate events faster than humans can read them. The signal is intact. The perimeter is drawn too small. An OAuth access token encodes three things: a user identity, a coarse scope, and an expiry. It is designed for the moment a human clicks "authorize" and a session begins. It assumes a human is present at the start of the delegation and, implicitly, for the duration. An autonomous agent violates both assumptions. It is headless at the moment of decision, and it chains actions — read a record, call an API, write a field, send a message — none of which were individually anticipated when the scope was granted. A token that says "read contacts" is not a token that says "read contacts, then exfiltrate the 40,000 rows you judge most valuable, then exit without logging where they went." The crypto world's answer was never OAuth. It was capability tokens with hard structural limits: spend-limited delegation, allowlisted call targets, expiring mandates, revocation you can prove. The standards equivalent exists too — OAuth 2.1 Token Exchange (RFC 8693), SPIFFE/SPIRE workload identities, and the WIMSE working group's multi-system identity model. Salesforce's proposed "AI Control Plane" gestures in this direction. But a control plane is an orchestration layer, not an identity standard. It tells you where policy would be enforced. It does not tell you what identity a headless agent presents when it calls a tool at 3 a.m. with no human in the loop. That last question is the hard one. It is called headless authentication, and it is not solved in deployable form. The crypto-adjacent answer is attestation: proving not merely "who is this" but "is this the exact binary I expect, running on the exact hardware I trust." TEEs — SGX, SEV, TrustZone — plus remote attestation protocols give you this. SPIFFE/SPIRE gives you the identity plumbing. Neither is bundled into an OAuth flow. Salesforce's framing promises "fine-grained, tamper-proof audit trails" without naming the mechanism. Trust is a variable we must eliminate, not manage. If your audit trail is a WORM bucket, it is tamper-resistant against everyone who does not control the bucket's IAM policy — which is not the same claim. If it is a hash chain with periodic anchoring, now we have something. If it anchors to a public chain, we have the strong version, with its throughput costs attached. The article does not say which. That omission is the finding. Then there is the audit claim itself. "Immutable" is the most overused word in both the blockchain and the enterprise-security vocabularies, and it means nothing until you specify the threat model. Immutable against whom? Against the deploying enterprise? Against a subpoena? Against a compromised root account? A WORM store answers the first and fails the second and third. A hash chain answers the first two and lives or dies on where the anchor is published. A public-chain anchor answers all three and adds a per-write cost, a privacy surface, and a throughput ceiling that no CRM vendor wants to explain on a quarterly call. So enterprises choose WORM, call it immutable, and move on. This is not dishonesty. It is the predictable outcome of pricing a marketing word instead of a security property. Now the 492 servers. This is not an outlier; it is the natural equilibrium of a protocol shipped without a mandatory auth layer and a market that rewards integration speed over security posture. I have run this calculation before. In 2024 I compared the risk structure of spot Bitcoin ETF custody against self-custody and found a 4% structural drag from fees, regulatory overhead, and counterparty latency that the "adoption" narrative never priced in. The same method applies here. The cost of authenticating every MCP server is small in absolute terms: a token check, a signed manifest, a rotation policy. The cost of not doing it is a tail event whose expected value is enormous and invisible until it fires. Rational actors under quarterly incentives skip it. They always have. Markets do not price tail risk until the tail arrives, and then they overprice it. The exploit chain the article sketches — compose the authentication bypass with the command injection and you land unauthenticated remote code execution on a server holding connectors into a company's internal data — is not clever. It is the standard composition. The 2019 Kinsing campaigns exploited the exact same shape against unauthenticated Docker daemons and Redis instances. The wrapper changed. The failure mode did not. What is genuinely new is the participation of autonomous agents as attackers. If the Hugging Face event is real, 700 agents running without human instruction represents scale no SOC can triage by hand. And if the Aurora crew is using a coding agent, the asymmetry widens further: the attacker's cost of producing a working exploit drops while the defender's cost of reviewing one stays constant. This is the moment the security economics flip. I spent the 2022 bear market inside the mathematics of proof-of-stake finality, cataloguing fifteen theoretical attack vectors the industry ignored because it was busy panicking over price. Every one of them was a version of this same lesson: systems fail at the boundaries between trust domains, and every boundary you add is a new place to fail. Salesforce's stack makes that concrete. Bedrock feeds Claude, Claude runs inside Salesforce's trust boundary, Salesforce calls MCP servers, MCP servers touch customer data. Five layers. Each is a compromise surface, and each inherits the weakest authentication of the layer beneath it. The article examines exactly one of those five layers. That is not analysis. That is a vendor's field of view. The industry's default reflex — solve agent misbehavior with better alignment — does not reach this problem. Alignment shapes what a model wants to do. It says nothing about whether the model was permitted to do it, or whether the request that reached it was authentic. A perfectly aligned model calling a tool it has no business calling is still a breach. The failure is a policy failure, and policy lives above the weights. This is why the control-plane framing is right even if the product is vapor: it moves the conversation from "make the agent good" to "make the agent authorized," and those are different engineering problems with different failure modes. There is a deeper constraint the piece never names, and its absence is why I do not trust the proposed fix. Take three properties: open execution environment, autonomous decision-making, and least privilege. You can have any two. Open execution plus autonomy gives you agents that can do anything, including harm. Open execution plus least privilege gives you agents that can only act in narrow, pre-approved ways. Autonomy plus least privilege gives you agents constrained to a pre-authorized action space, which is not really "open." You cannot hold all three simultaneously. Every control plane claiming all three is selling a fourth thing: a compliance narrative. That is what the "governance-as-infrastructure" pitch ultimately is — a way to make the trade-off legible to an auditor rather than to eliminate it. Here is what the bulls got right, and it is worth conceding cleanly. Salesforce's core intuition — that agent security is a control-plane problem, not a model problem — is correct and non-obvious. Most of the industry is still trying to solve this with alignment and fine-tuning. Salesforce locates the failure in orchestration, in policy and identity, not in the weights. That is a real insight, and it is why the Dreamforce agenda is worth watching even though the product details are unverifiable. Where the bulls overshoot is the word "standard." A control plane living inside a single vendor's trust boundary is not a standard. It is a lock-in with a security label. Microsoft has already shipped Entra Agent ID. Okta, CyberArk, and Palo Alto have their own agent-identity products in the field. Salesforce is a fast follower, not a standard-setter. The genuinely useful artifact would be an open identity standard for agents — something like UCAN or WIMSE with a working reference implementation — and no platform vendor has an incentive to ship that. So we will get a dozen incompatible control planes, each claiming the standard, and the 492 will keep growing. Hype is just volatility wearing a suit and tie; the suit here reads "governance." Risk is not a number, it's a structural flaw. The bare MCP servers, the headless authentication gap, and the tamper-proof audit claim are three faces of one problem: we are building identity infrastructure for autonomous actors using primitives designed for humans. The fix is not a keynote. It is mandatory authentication, capability limits with hard edges, and audit trails that either anchor to something an attacker cannot rewrite or stop making the claim. Watch the Dreamforce agenda in September. Then watch the CVE feed in October. The second one tells you what the first actually built.