The Cold Economics of Commoditizing Complements
When a technology titan gives away a wildly popular piece of software, don't mistake it for charity. It isn’t altruism. It’s calculated strategy.
In June 2002, software developer Joel Spolsky published Strategy Letter V, outlining a core rule of software markets: demand for any product increases when the price of its complements drops. A complement is anything you buy alongside a primary product—like gas for cars, or operating systems for hardware. Smart tech vendors do not just wait for complements to get cheaper; they actively commoditize them. If you can force the cost of a complement down to near zero by turning it into an open standard or free tool, customer spending concentrates directly in your high-margin core business.
This economic law explains today's artificial intelligence market. When major developers see open protocols like the Model Context Protocol (MCP) or Agent2Agent (A2A) distributed without licensing fees, they are watching economic commoditization in real time. Raw model weights are becoming interchangeable, while the real commercial battle moves to enterprise workflows, platform gravity, and data governance.
Historical Lessons from IBM, Microsoft, Google, and Git
We have watched this exact strategy unfold for decades across enterprise computing.
Back in the early 1980s, IBM published open specifications for the IBM-PC architecture in its Technical Reference Manual. IBM wanted to commoditize PC add-in hardware and expansion cards to expand the total market for personal computers. But Microsoft pulled off a sharper strategic move: by licensing MS-DOS non-exclusively to OEM manufacturers, Microsoft turned PC hardware into an ultra-low-margin commodity while capturing massive profits on operating system licenses.
Fast forward to 2017. As Matt Asay observed in InfoWorld's analysis of AI competition, Google did not open-source Kubernetes and TensorFlow out of pure generosity. Google was playing catch-up to Amazon Web Services and Microsoft Azure. By making container orchestration and machine learning frameworks free and ubiquitous, Google created a massive gravity well for containerized applications, betting that a significant portion of those workloads would ultimately land on Google Cloud Platform.
The same dynamic built GitHub. Git itself is free and open-source software, but GitHub built a multi-billion-dollar enterprise platform by capturing the surrounding collaboration layer, code reviews, access policies, and developer workflows. The underlying protocol costs nothing; the enterprise workflow engine carries the margin.
Why Anthropic, Google, and OpenAI Donated MCP and A2A
The current push around AI communication standards follows the same script.
On November 25, 2024, Anthropic open-sourced the Model Context Protocol (MCP), a universal two-way standard connecting AI assistants to data repositories, content systems, and development environments. Instead of building custom connectors for every system, developers could deploy MCP client applications to connect with MCP servers built for Google Drive, Slack, GitHub, Git, Postgres, and Puppeteer. Early adopters like Block, Apollo, Zed, Replit, Codeium, and Sourcegraph immediately integrated MCP to help AI agents retrieve contextual data.
By mid-2026, MCP reached nearly 100 million monthly SDK downloads across more than 10,000 active servers. Rather than trying to lock down MCP as a proprietary interface, Anthropic donated the protocol to the Linux Foundation’s Agentic AI Foundation. Google took a similar route with its Agent2Agent (A2A) protocol, handing governance to the Linux Foundation alongside founding members AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow. OpenAI joined the steering committee, supported remote MCP servers inside its Responses API, and contributed AGENTS.md.
Why would fierce model competitors unite behind open standards? Because frontier model benchmark leadership shifts weekly. Raw model weights provide a fragile moat, and relying solely on token pricing is a losing game as inference costs drop (a dynamic we analyzed in our breakdown of hidden enterprise AI economics). Instead, tech giants are standardizing the communication layer to strip out integration friction, driving enterprise workloads directly into their proprietary orchestration engines and cloud platforms.
What Every Security & Compliance Analyst Must Monitor in Enterprise Stacks
For any working security & compliance analyst, protocol commoditization shifts where enterprise risk concentrates. When open standards like MCP and A2A make integration effortless, enterprise data moves faster between internal systems and third-party models—creating new operational risks similar to those seen when hyper-scalers expand enterprise cloud footprints. That acceleration demands stricter security & compliance oversight.
If an autonomous agent can instantly query Postgres databases, read files from Google Drive, and pull internal chat logs in Slack, traditional perimeter defenses fail. A security & compliance analyst must audit where authorization boundaries exist, how non-human identities get managed, and whether logging captures every automated data fetch.
Consider how enterprise environments handle these connections:
- Enterprise environments running suites like Microsoft 365 depend on central administrative portals such as the security & compliance center office 365 to enforce data loss prevention (DLP), conditional access, and audit logging across user and agent sessions.
- Storage and backup setups, such as a security & compliance analyzer veeam deployment, require strict immutability checks so that connected AI tools cannot alter or exfiltrate backup recovery points.
- Operations teams deploying AI agents must verify that open protocol connectors enforce existing role-based access control (RBAC) rules rather than executing tasks under over-privileged service accounts.
Open standards make swapping models trivial, but they concentrate risk in the integration plane. If an agent uses MCP to retrieve sensitive records across multiple corporate tools, auditing that cross-system activity becomes the primary objective for security & compliance teams.
Building a Modern Cloud Security Incident Response Playbook
When open protocols eliminate friction for data movement, your cloud security incident response playbook must adapt to agentic threats. Incident response plans cannot rely on traditional assumptions where data transfers only happen through manual user clicks, especially as organizations face escalating AI cybersecurity threats across agentic infrastructure.
A modern incident response workflow for AI-driven infrastructure requires four practical steps:
- Protocol Telemetry Ingestion: Capture all MCP and A2A JSON-RPC message traffic at network and host boundaries. Log every tool request, server response, and prompt payload to an immutable SIEM system.
- Identity & Token Verification: Confirm that remote MCP endpoints validate OAuth 2.0 tokens and session scopes on every single call. Treat every agentic request as an untrusted machine identity interaction.
- Automated Quarantine & Revocation: Update incident response playbooks to trigger immediate API token revocation and MCP server isolation routines. When an AI agent displays suspicious data harvesting behavior, automated defenses must sever the protocol connection without taking core business apps offline.
- Post-Incident Forensic Audit: Cross-reference agent actions against enterprise compliance tools—including security & compliance auditing inside Office 365, database query logs, and backup infrastructure—to verify whether unauthorized data exposure occurred during the session.
Understanding why tech companies give away protocols helps security teams focus on what matters. The protocol is free, but keeping enterprise systems safe and compliant remains the real work.
