From TCP/IP to MCP: Security and Governance Lessons from Internet Protocols for Agentic AI

Introduction

AI agent protocols are emerging rapidly as a way to enable interoperability between agents, external tools and users. A protocol is a standardised set of rules governing the format and exchange of data between systems; in practice, the boundary between a ‘protocol’ and a ‘standard’ for technology is blurred, with protocols often becoming standardised through adoption. The predominant example, the Model Context Protocol (MCP), released by Anthropic in November 2024, has grown rapidly with over 170,000 supported tools [88] and backers including OpenAI, Amazon, and Google. MCP is increasingly referred to as being in the process of becoming standardised digital infrastructure [see e.g. 64].

These protocols functionally mirror those developed at the end of the 20th century that underlie the internet, with both facilitating communication and interoperability between heterogeneous systems. Inspired by this parallel, this paper draws lessons from internet protocols to inform the development of AI agent protocols. We focus on security and governance of protocols as areas where internet and agent protocols share structural similarities despite content-level differences. We explicitly exclude considerations of geopolitics in standard-setting, while acknowledging that standards and protocols development can be an active arena for advancing geopolitical power [30, 37].

While the comparison can be instructive, it is not perfect. In particular, internet protocols emerged from publicly-funded research over decades, while AI agent protocols have been developed commercially in months. However, the rapid rate of uptake of AI agent protocols only increases the timeliness of any lessons that can be learnt from the history of the internet. As these protocols become embedded in how AI systems interact with the world, decisions made now about their design, security, and governance will shape who benefits, who bears the risks, and who gets a say.

Throughout the paper, we draw on MCP as a running example due to its current position as the most widely-used and most-developed AI agent protocol. While other AI agent protocols are available, such as Agent2Agent and the Agent Communication Protocol, MCP offers the greatest evidence base from which to draw a comparison to internet protocols. When considering protocol governance, we primarily focus on the Internet Engineering Task Force (IETF) given its stewardship of the majority of internet protocols, including TCP, IP, HTTP, TLS/SSL, and DNS.

Authors’ Contact Information: Ben Bucknall, [email protected], University of Oxford, UK; Andrew Byrley, Independent, USA; Lewis Hammond, Cooperative AI Foundation, UK. Based on our analysis, we make two primary conclusions:

• Retrofitting security measures to existing protocols is challenging due to practical and economic challenges. Early internet protocols deprioritised security, contributing to a decades-long security debt. If AI agent protocols do not sufficiently prioritise security in the early stages of their development, they risk accumulating a similar security deficit that becomes increasingly costly to address as adoption grows.

• Internet protocols are embedded in a unique governance structure with formal mechanisms for accountability and community input, including at the highest levels of leadership, though whether these mechanisms translate to openness in practice is disputed. In contrast, AI agent protocols have emerged with a governance structure that centralises decision-making power in a small number of individuals, raising concerns about legitimacy in the case that these protocols become critical digital infrastructure.

Alongside sections motivating each of these conclusions (§ 3 and § 4, respectively), § 2 provides relevant background information and § 5 discusses the two conclusions, how they interact, and highlights concrete implications for key stakeholders.

Background

A Short History of Internet Protocols

The internet’s origins lie in the Advanced Research Projects Agency Network (ARPANET), a U.S. Department of Defense project first operational in late 1969, designed to enable resource-sharing between geographically dispersed research computers [58]. Critically, the host-to-host communication protocol was designed not by ARPA officials or by the contractors that built the network hardware, but by an informal group of graduate students who called themselves the Network Working Group (NWG) [68]. The NWG designed the Network Control Program (NCP), ARPANET’s first host-to-host protocol [25], which assumed a single, homogeneous network.

NCP was unsuitable for internetworking. In the early 1970s, DARPA was building packet radio and packet satellite networks that NCP could not accommodate due to differing packet sizes, latencies, and failure modes [21, 58]. This problem was solved in September 1981 by a pair of protocols: the Internet Protocol (IP) [70], a connectionless datagram protocol responsible for addressing and routing, and Transmission Control Protocol (TCP) [71], a reliable byte-stream transport. On January 1, 1983 NCP was permanently disabled on ARPANET and TCP/IP became the sole operational protocol [58]. By the time that commercial restrictions on internet traffic were lifted in 1995, TCP/IP was already the foundation of global networking [58], catalysed by the introduction of the World Wide Web in August 1991 [11].

The institutional home for internet protocol development, the Internet Engineering Task Force (IETF), grew directly out of this ARPANET community and was spun off as an engineering-focused task force in January 1986. The IETF’s cultural charter was reflected by David Clark at the 1992 Cambridge plenary: ‘We reject: kings, presidents and voting. We believe in: rough consensus and running code’ [23]. Unlike traditional standards-setting organisations, governments play no formal role in the IETF, and as such, it lacks national delegations, treaty obligations, and reserved government seats. We return to the details of the IETF’s governance structure, and its contrast with MCP’s, in § 4.1.

The primary vehicle for IETF standards development is the Request for Comments (RFC) series, which predates the IETF itself. The name ‘Request for Comments’ was deliberately chosen to signal informality, reflecting ‘the basic ground rules [...] that anyone could say anything and that nothing was official’ [26]. What began as informal notes among a handful of ARPANET researchers became the authoritative document series for internet standards. Along with technical specifications, RFCs also encompass governance and process documents,¹ philosophical statements,² ethical guidelines,³ humour,⁴ and the RFC process itself.⁵

The principal competitor to TCP/IP in the 1980s was the ‘Open Systems Interconnection’ (OSI) model, developed through formal international standards processes. OSI was developed by the International Organization for Standardization (ISO) and the International Telegraph and Telephone Consultative Committee (CCITT, now the ITU-T – the Telecommunication Standardisation Sector of the International Telecommunication Union). It enjoyed powerful institutional backing, being endorsed by the European Community, national post, telephone, and telegraph administrations (PTTs) [77], and major vendors including IBM and DEC [78]. Yet TCP/IP was already deeply entrenched in the research and university communities and its user base was growing rapidly [58].

The two efforts embodied different approaches to protocol development. The IETF’s process required that protocol proposals be accompanied by working implementations; specifications evolved through iterative testing and deployment, not committee negotiation. OSI, by contrast, aimed to produce complete, formally specified standards through a multiyear, delegation-based process involving national standards bodies before implementations existed. The consequences of these competing approaches were significant. The need to reconcile competing interests within ISO produced enormous specification complexity, which made interoperable implementation difficult in practice [77]. By the early 1990s, many of the ISO committees working on OSI standards were coordinating their own work over TCP/IP-based email – conducting their deliberations on the very infrastructure whose intended replacement they were designing [77]. Amplified by the explosive growth of the World Wide Web after 1993, displacement of TCP/IP became effectively impossible [77] and mandates for the adherence to the OSI model faded in both the US and EU. OSI as a deployed protocol suite effectively ceased to exist [77], although individual OSI-derived standards survived in specific niches.⁶

AI Agent Protocols to Date

Similarly to how internet protocols are specifications for mediating connections between individual users and machines, AI agent protocols specify the structure of how AI agents interact with external tools, human users, and each other. By standardising these interactions, protocols serve to make it easier for individual agents to reliably perform actions in the real world, while also providing the opportunity for attribution, oversight, and certification [22]. While protocol development for AI agents has progressed rapidly in recent years, the concept was discussed much earlier, for example in Wooldridge [94], who characterises protocols as defining “the ‘rules of encounter’ between agents.”

Numerous efforts to develop AI agent protocols are underway within government, industry, and academia. For example, the National Institute for Standards and Technology (NIST) in the US has launched an AI Agent Standards Initiative to promote the trusted adoption of AI agents and “cement U.S. dominance at the technological frontier”.⁷ So far, the initiative has supported a concept paper on ‘Software and AI Agent Identity and Authorization’ [14], and a request for comments regarding ‘Security Considerations for AI Agents’.⁸ Elsewhere, the ITU has started developing standards specifically focussed on AI agents [48], as has the China Academy of Information and Communications Technology [90]. Finally, while its standards to-date are not specifically focused on AI agents, much of the ISO’s work on AI – for example throught its ISO/IEC JTC 1/SC42 committee – is directly relevant [62].

A larger number of proposed protocols have come from industry and academic sources, variously focussing on agent-agent, agent-user, or agent-tool interactions [96]. While such proposals don’t have the explicit aim of defining a formal standard, as seen in the case of internet protocols, it is not uncommon for informal proposals to become de facto standardised if they secure enough buy-in among users and developers. Examples include Agent2Agent (A2A) and Agent Communication Protocol (ACP), released by Google in April 2025 and IBM in March 2025, respectively, both of which focus on inter-agent communication and collaboration [60, 89]. Others, such as AG UI, developed by CopilotKit focuses on the interaction between user interfaces and AI agent-based backends.⁹ While many of these examples are stewarded and supported by private industry actors, they take the form of open-source projects with a focus on developing functional implementations of protocols rather than abstract frameworks.

The Model Context Protocol (MCP) has emerged as the predominant AI agent protocol since its release by Anthropic in November 2024. Framed as a ‘USB-C port for AI applications’, MCP provides a standardised format for AI agents to interact with external tools as a way of addressing the previously fragmented landscape, where each pair of agent and tool might have a unique way of interacting [34, 96]. Following its release, MCP quickly gained traction within the community and corporate buy-in, notably with OpenAI supporting MCP across its products from March 2025.¹⁰ The MCP ecosystem has grown to include tens of thousands of servers – lightweight programs that expose tools to agents – and hundreds of thousands of distinct tools [88]. In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a subsidiary of the Linux Foundation, which it founded along with other companies including OpenAI and Google. We discuss the AAIF and its governance structure and implications further in § 4.

On the Comparison of Internet and AI Agent Protocols

Having provided an overview of the history of internet protocols and ongoing developments in AI agent protocols, we now discuss in more detail the motivation for making this comparison. We outline similarities regarding what purpose the protocols are intended to serve, how they’re developed, and by whom, as well as ways in which they contrast.

The similarity between internet protocols and AI agent protocols at a functional level is that both aim to address problems of interoperability and heterogeneity within their domains. In particular, TCP/IP standardised the format in which data could be transferred between computers of varying architectures, running different operating systems. In comparison, AI agent protocols standardise the format in which agents interact with users, tools, or other agents. For example, rather than AI agents needing to structure a tool call in a different way for each tool, MCP defines a single format that can be used with a large number of potential tools. As a result of this focus on interoperability and interconnectivity, both kinds of protocols are subject to network effects whereby the benefits of an individual adopting the protocol are proportional to the number of existing adopters [55, 65].

Furthermore, in both the case of TCP/IP and industry-led AI agent protocols, the specification is approved by a centralised authority, though amendments, updates, or extensions can be proposed by the broader community. The approved standard then serves as reference for implementation by third-parties that are nonetheless able to deviate from the specification. This means that the success of standardised protocols stems from soft power and network effects rather than any mandated use, and that the individual or group with power to define the specification exercises significant power over the ecosystem without any formalised authority.

At an ecosystem level, both internet and AI agent protocols are advanced by a range of organisations and institutions. As taxonomised by Biddle [13], these include ‘formal standards development organisations’ (SDOs) such as the ISO and ITU and ‘consortia’ – industry-led organisations that lack government recognition or authority – such as the IETF and AAIF. Biddle [13] also discusses ‘single promoter standards’ – standards that are developed and promoted by a single company. Anthropic’s initial development of MCP can be seen as an example of this category.

Alongside the similarities, there are also numerous differences worth noting. First, while early internet development was overwhelmingly supported and funded by the US Department of Defense through DARPA, (implemented) AI agent protocols are almost entirely the result of private, corporate funding. As such, while the internet was initially intended as an inherently national security-relevant technology, rather than one used by the broad public, companies developing AI agent protocols may view them as a commercial asset, product, or service. Indeed, MCP, the first widely-adopted AI agent protocol, was initially developed by a single private company.

Second, AI agent protocols have experienced a dramatically faster rate of uptake than the internet. Stein [88] identifies over 70,000 potential MCP servers as of February 2026 – approximately 15 months after MCP’s initial launch. In comparison, it took approximately two decades for the internet to reach a comparable number of hosts [97]. This may be a direct result of the difference in initial purpose noted above, in that the internet was initially a closed community of academics developing defence infrastructure. While the user base of AI agent protocols remains highly technically-literate, there is uncertainty regarding whether this will shift to encompass a broader, less-technical subset of the general public, as was seen for the internet.

Overall, while these differences mean that the analogy is imperfect, the structural similarities between internet and AI agent protocols – both at the functional and ecosystem level – suggest that the comparison is informative. In the following two sections we compare the development of internet and AI agent protocols, particularly with regards to their security properties and governance structures.

The Challenges of Retrofitting Security

In this section we discuss the history of internet security, and how excluding security as an initial design goal created challenges when it came to retroactively implementing security measures – that is, technical defences against the misuse of the internet for malicious ends. We also provide a brief overview of security in MCP, arguing that, if neglected in these early stages of MCP’s development, implementing security will face similar challenges. As a way of structuring the discussion, we introduce two complementary categories of practical and economic challenges to retrofitting security.

Practical challenges occur when, despite the existence of secure protocols, implementation is bottlenecked by material constraints. This may be due to implementation costs or performance trade-offs. For example, performing cryptographic verification can introduce a small but real computational overhead to communication protocols [63]. Having to retroactively implement security to existing protocol suites raises additional practical challenges, such as minimising service disruption, as well as ensuring interoperability and backwards-compatibility [8]. Moreover, maintaining backwards compatibility with insecure legacy systems can itself introduce new attack vectors that exploit continued support for deprecated protocol versions [49].

Economic challenges occur when implementing security, while not theoretically or practically challenging, is disincentivised or inhibited. For example, uptake of secure protocols may be slowed by collective action problems whereby, despite manageable implementation costs, the benefit to each actor is negligible unless all other actors also implement the secure protocol [9, 41, 57, 91]. Anderson and Moore [4] provide an influential overview of the economic factors at play in information security, arguing that ‘incentives are becoming as important as technical design in achieving dependability.’ These challenges are compounded when security must be retrofitted, as secure protocols must then compete with insecure alternatives that are already broadly deployed. For example, actors may anchor on the cost of an insecure ‘status quo’, making them less likely to pay extra for security, even if they would have paid the higher price if no alternative was available [52, 69, 74, 81].

The Internet’s Persistent Security Deficit

As discussed in the previous section, the modern internet emerged out of a small and closed network of trusted users, predominantly in academia, in the 1970s [29]. At the time, personal computers were not yet commonplace, and ‘public or home access [to the internet] seemed implausible’ [29 p. 683]. As such, security was not considered to be a priority. On the contrary, it was deemed to be both infeasible and undesirable [35]:

A community of scholars should not have to build walls as high as the sky to protect a reasonable expectation of privacy, particularly when such walls will equally impede the free flow of information. Besides, attempting to build such walls is likely to be futile in a community of individuals possessed of all the knowledge and skills required to scale the highest barriers.

A watershed moment came in November 1988 when the then-Cornell graduate student Robert Morris developed and released a self-replicating computer program (what’s now termed a ‘worm’) on the internet, disabling over 6,000 computers¹¹ [29, 35]. The ‘Morris Worm’, as it has since become known, exposed the weaknesses in relying on interpersonal trust and academic integrity for securing a growing network. Around the same time, Steve Bellovin published a paper outlining multiple ‘serious security flaws inherent in the [TCP/IP suite of] protocols’ [10]. For example, since TCP/IP lacked a method for verifying the stated source address of packets sent over the network, attackers could impersonate a trusted host and, in combination with predictable protocol behaviour, execute commands on remote systems without authentication [10]. Over the ensuing decade, internet user numbers rose rapidly, catalysed in part due to the advent of the World Wide Web in the early 90s, with many new users coming from outside the academic communities which comprised much of the early user base. As a result, the heavily trust-based model on which the early internet operated became outdated. Combined with commercial and corporate interest in e-commerce, the need for greater internet security was becoming apparent [29]. Costly worms and viruses underscored this need, and remained commonplace into the 2000s, with examples such as the ‘Love Bug’ virus (2000), ‘Code Red’ (2001), and ‘Mydoom’ (2004) requiring billions of dollars to combat [29].

In spite of the rising costs of security vulnerabilities, adoption of more secure protocol variants has historically proven sluggish. One prominent example is that of retrofitting encryption to the Hypertext Transfer Protocol (HTTP) – the protocol underlying the World Wide Web. HTTP/1.0 was published as a standard in 1996 as RFC 1945 [11], having gained broad adoption during its draft status. However, HTTP did not natively support encryption, meaning that all information transferred using it was liable to man-in-the-middle attacks such as eavesdropping, tampering, or forgery.

Around the same time, Netscape was developing the Secure Sockets Layer (SSL), a proprietary protocol for cryptographically securing the transmission of data over TCP connections, with HTTP being the primary motivation. SSL was later adopted by the IETF, rebranded to Transport Layer Security (TLS), and published in RFC 2246 in 1999 [31]. ‘HTTP over TLS’ or simply ‘HTTPS’ was standardised in 2000 as RFC 2818 [75]. Despite all technical pieces being in place by the late 1990s, HTTPS adoption remained confined to a narrow set of use cases – primarily financial transactions, where payment card industry requirements mandated its use [65]. The broader web remained unencrypted for two decades. In 2017, half of the most popular websites were still HTTP by default, and most smaller websites did not support HTTPS at all [38]. The barriers to greater uptake identified in the literature were practical and economic rather than technical. For example, it was costly to acquire a TLS certificate – a prerequisite for allowing users to connect using HTTPS – and deployment was a ‘notoriously difficult process’ [12] deemed to be ‘far too complex even for people with proficient knowledge in the field’ [53]. With unencrypted HTTP as the entrenched default and minimal direct costs to web servers for not providing secure connections, the additional burden of deploying HTTPS proved prohibitive for many smaller actors. It took structural changes such as Let’s Encrypt providing a cheaper and simpler method for acquiring TLS certificates [1], browsers warning users when connecting to insecure websites [39], and the US government requiring all federal websites to support HTTPS by the end of 2016 [84] to finally make the use of HTTPS widespread.

While many similar cases have been individually documented, when read together they exhibit a common pattern of widespread adoption of secure internet protocols being hindered by practical and economic challenges, long after the technical substrate was in place. IPv6, despite being standardised as a successor to IPv4 in 1998 [27], still only serves around 50% of internet users¹² due to a lack of backwards compatibility imposing significant costs on early adopters [30, 55, 95]. Domain Name System Security Extensions (DNSSEC) – the suite of protocols that adds cryptographic attestation to the directory that maps domain names to IP addresses – was introduced in 2005 [5, 6, 7], yet remains at single-digit adoption rates,¹³ partly due to collective action problems [65]. Finally, Resource Public Key Infrastructure (RPKI) [59], a solution to insecurities in the Border Gateway Protocol (BGP), has only recently attained 50% coverage, with adoption slowed by similar organisational challenges [42].

A common theme among all these examples (HTTPS, IPv6, DNSSEC, RPKI) is that, despite the technology being functional, practical and economic considerations – such as coordination problems and large upfront costs to first-movers – considerably slowed the uptake of security. Often this was further hindered by secure protocols having to compete with existing but insecure alternatives, which could increase switching costs, demand backwards compatibility, or serve as an anchor against which performance is measured. In many cases it took structural changes in the form of regulatory mandates [84], free or automated tooling [1], and changes to default behaviour by major platform providers to achieve widespread use of secure protocols [39]. As we argue in the following section, there is reason to believe that these dynamics will generalise to AI agent protocols.

Security Challenges for AI Agent Protocols

Despite its relative nascency, MCP has already experienced a number of security issues and flaws, and a considerable amount of research has been carried out analysing its security profile (see e.g. 3, 24, 36, 43, 46, 73, 98). For example, Hou et al. [46] formalise a threat taxonomy according to four potential attacker types: malicious developers, external attackers, malicious users, and security flaws. Notably, they find that, ‘despite the rapid adoption of MCP, its ecosystem is still in the early stages, with key areas such as security, tool discovery, and remote deployment lacking comprehensive solutions’ [46]. Examples of the security issues highlighted include ‘command injection’, where an attacker inserts malicious logic into a server’s source code, and ‘unauthorized access’ attacks where attackers are able to interact with systems beyond intended permissions due to ‘weaknesses in authentication, transport, or session management’ [46]. Instances of these vulnerabilities have been observed. For example, an unofficial Postmark email MCP server ‘built trust over 15 versions’ before secretly adding a backdoor that ‘BCC’d emails to an external server.’¹⁴

While MCP acknowledges potential security issues, current approaches to dealing with risks to safety and privacy place the responsibility on downstream developers and end users. For example, the protocol specification states that ‘users must explicitly consent to and understand all data access and operations’ and that ‘users must retain control over what data is shared and what actions are taken.’¹⁵ Furthermore, while the MCP registry – an official and open catalog of publicly available MCP servers – includes a ‘community-driven mechanism for moderation’,¹⁶ it defers security opportunities such as ‘source code scanning’ and ‘tool poisoning countermeasures’ to later iterations of the registry.¹⁷

If not addressed in the near-term while MCP is still scaling, implementing solutions to many of these security weaknesses may prove challenging due to the practical and economic effects discussed in the previous section. There has already been a case in which practical considerations, in the form of backwards-compatibility, played a role in MCP’s evolution. Authorisation through OAuth [45] was first introduced to MCP as an optional feature in the March 2025 specification as a way of handling authorisation for accessing restricted servers.¹⁸ Initially, the specification relied on Dynamic Client Registration (DCR) [50] as a way of allowing clients to register with servers at runtime [67]. However, DCR was seen to place too much onus on developers of MCP servers who often didn’t have the necessary expertise to implement it correctly [28]. In a study of real-world remote MCP servers that implement authorisation, Zhou et al. [99] found that 96.6% of tested servers exhibited a flaw with DCR, such as allowing attackers to intercept authorisation codes. As such, the November 2025 MCP specification moved towards an alternative approach – Client ID Metadata Documents (CIMD) – but retains support for DCR as a fallback for the purposes of backwards compatibility.¹⁹ As MCP continues to grow, similar dynamics are likely to recur, with the difficulty of migrating to improved approaches – and the security costs of maintaining legacy ones – only increasing with adoption.

Furthermore, in April 2026, OX Security disclosed that the use of stdio transport for launching MCP servers as local subprocesses passes the command given in a client’s configuration directly to the operating system without validation. This can facilitate arbitrary code execution if an attacker is able to influence the configuration [85]. Since this logic is built into the official MCP SDKs, it is inherited by all servers that are built on them. One of the proposed protocol-level fixes was to implement manifest-only execution, meaning that a client would only launch verified servers rather than executing an arbitrary command string. However, Anthropic responded by stating that this is not a vulnerability in MCP, since its trust model assumes that client configurations are trusted, and so the responsibility is on the host application’s developer to implement safeguards. This position was clarified in an update to MCP’s security policy.²⁰ The proposed fix would have broken the launch path for every existing stdio server, requiring server authors to publish conforming manifests and client implementers to enforce them, with the cost of coordination rising as the ecosystem grows.

Despite this section’s focus on practical and economic security challenges, it is worth noting that, for many issues in AI agent security, we do not yet have robust technical solutions. Many of the observed vulnerabilities of MCP discussed above stem from weaknesses in agents themselves in the face of ‘agent traps’ [40]. For example, tool poisoning relies on LLMs’ susceptibility to jailbreaking. These are analogous to social engineering attacks such as phishing, which exploit the human user rather than the protocol, but which the protocol nonetheless enables. In the internet case, however, the attacker-defender dynamic is grounded in the relative stability of human psychology. For example, innate human susceptibility to scams tends not to vary much. The same cannot be said of AI agents, whose underlying models are @referencesанӡа frequently updated. This means that the attack surface the protocol must contend with is itself shifting on the timescale of months, but also that security advances could come through updates to agents themselves. Combined with the field’s still-limited understanding of LLM robustness [56], this makes the residual risk that persists after protocol-level security measures less predictable than its internet-era analogue. Authentication, authorisation, and verification remain essential for MCP, but they are unlikely to be sufficient.

Discussion

Above, we have argued that AI agent protocols are likely to face similar practical and economic challenges to implementing security measures as seen in the case of internet protocols. This argument largely follows from the observation in § 2.3 that both internet and AI agent protocols are subject to network effects – once users have adopted a particular version of a protocol, updating the entire ecosystem to a newer, more secure version naturally encounters a coordination problem. While it is possible that MCP has already reached this stage given the tens of thousands of servers already in use, we do not empirically establish any existing security deficit in MCP. Rather, we have argued that the conditions under which such a deficit could emerge are present, and suggest empirical studies of security in the MCP ecosystem as valuable future work.

If it is the case that network effects are slowing the adoption of security in MCP, what can be learnt from internet protocols? The example of HTTPS discussed above points towards three events that spurred adoption: easy and free tooling (Let’s Encrypt), changes to default system behaviour (browsers warning when connecting via non-encrypted HTTP), and mandated adoption (US federal websites requiring encryption). This suggests potential analogous interventions that could incentivise the uptake of secure AI agent protocols. For example, protocol developers or third-parties could develop public tooling that makes scanning and certification of MCP servers free and automated. Official MCP software development kits (SDKs) could include default behaviour that alerts the user if their agent is connecting to a tool server that has not been verified or certified. Major enterprises or government agencies could require that critical servers are verified or certified. Ultimately though, these interventions are able to incentivise the uptake of secure protocols only once they have been technically defined and incorporated into the protocol specification – something that, for many critical security features, is still lacking.

Governance and Legitimacy in Protocol Development

In this section, we explore and compare the governance and decision-making structures adopted by the dominant protocol development bodies responsible for developing internet and AI agent protocols – namely, the Internet Engineering Task Force (IETF) and Agentic AI Foundation (AAIF), respectively. We find notable differences in approach. While the IETF has evolved over decades to adopt participatory approaches to both low-level protocols development and high-level strategic planning, the AAIF and MCP have adopted structures that centralise decision-making authority in a small number of industry representatives, with few inroads for community participation at the highest level.

Internet Protocols: The IETF

As introduced in § 2.1, the IETF serves as the predominant body in internet standards and protocols development, with protocols including TCP/IP, HTTP, and SSL/TLS [44]. Initially formed in 1986 as a working group for the expanding set of internet users, particularly at universities, the IETF quickly gained traction and became open to all interested individuals within two years of its foundation [79]. This focus on openness, along with technical merit and action through broad consensus, has since been codified through RFCs as formal structures and processes for the body [see e.g. 2, 15–17, 54, 80].

The openness of the IETF is represented by the fact that ‘there is no membership in the IETF.’²¹ Participation, for example by signing up to a working group, is open to any interested individual. While all participation is considered by the IETF to be on a voluntary and individual basis, tech companies can, and do, employ individuals to contribute full-time, with many key protocols being proposed by contributors from a handful of companies [44 p. 38]. Decisions are made by rough consensus – often indicated by humming – rather than formal voting procedures, with working group chairs responsible for deciding when consensus is reached and ensuring that objections are addressed [76].

While the technical ground work is carried out within working groups, there is a large amount of higher-level strategic and administrative work required to keep the IETF running (see Figure 1). This is the purview of a number of bodies including: the Internet Architecture Board (IAB), the most senior technical body that sets long-term technical direction; the Internet Engineering Steering Group (IESG), which is responsible for the protocol development process, including providing final approval for RFCs; IETF Administration LLC (IETF LLC) which serves as the legal, financial, and operational centre; and the IETF Trust which manages the IETF’s intellectual property [80].

One of the most distinctive features of IETF’s governance is the Nominating Committee (NomCom). Composed of 10 randomly selected²² contributors serving year-long terms, the NomCom has broad powers and responsibilities for appointing members to leadership positions across the IETF structure, including the boards of the IAB, IESG, and IETF LLC [54]. Eligibility for the NomCom is subject to certain criteria, but can be satisfied, for example, by attending three of the past five IETF meetings [32]. Furthermore, upon petition by 20 IETF members meeting the same eligibility criteria, a Recall Committee can be established according to the same processes as the NomCom with the power to recall (i.e. remove) any member of the IESG, IAB, or other NomCom-appointed leader by three-fourths majority [54].

However, despite adopting a formal governance structure that emphasises open participation, the IETF has received criticism, including for alleged corporate capture due to companies’ employing individuals to participate in the standards setting process ‘as individuals’ [44]. Furthermore, analysis has shown that formal openness may not translate to decentralisation, with 32%-42% of RFC drafts between 2010 and 2019 authored by the top 10% most influential contributors [51]. Critics have further pointed towards ‘cultural barriers to openness’ in the IETF, including ‘confrontational working practices’ that exclude input from non-profit organisations [19].

AI Agent Protocols: MCP and the AAIF

In this subsection, we provide the first comprehensive analysis of the governance structure surrounding MCP following this donation to the LF, drawing on charters, tier structures, and public governance documentation. We compare the structure that has emerged since MCP’s founding donation to the Agentic AI Foundation (AAIF) in December 2025 to other LF directed funds, namely the Cloud Native Computing Foundation (CNCF) and the PyTorch Foundation.

MCP itself follows a largely standard open-source project governance hierarchy consisting of: a pair of ‘lead maintainers’, a ‘lifetime appointment’ which holds ‘ultimate authority over MCP’s direction and governance’; a group of six ‘core maintainers’, holding ‘final decision-making authority for MCP’s technical direction’; and a broader community of ‘maintainers’, ‘members’, and ‘contributors’ (in descending order of responsibility) [87]. There is ‘no formal requirement’ for becoming a contributor, other than contributing to MCP in any form [87]. While the positions of ‘member’ and ‘maintainer’ are broadly attainable on a meritocratic basis, the core maintainer role is ‘intentionally limited’ to ensure a ‘coherent technical vision while the project scales’ [87]. Roughly in line with the ‘Benevolent Dictator For Life’ (BDFL) model of open-source governance, the lead maintainer role is ‘a lifetime appointment reserved for project founders’ which is only assumed through succession rules if an existing lead maintainer leaves the role [86].

The AAIF is a ‘directed fund’ under the Linux Foundation (LF) which stewards MCP alongside five further projects: OpenAI’s ‘AGENTS.md’ and Block’s ‘goose’, which were donated at launch, as well as ‘agentgateway’, ‘Agent2Agent’ (A2A), and ‘Agent Router’ which joined in June, August, and September 2026, respectively.²³ The AAIF has a membership base of mostly private companies with some academic institutions, as is standard for LF directed funds. These members are organised according to tiers which provide differing levels of representation and input into high-level decision-making in exchange for increased membership fees. In the case of AAIF, these tiers are called ‘platinum’, ‘gold’, ‘silver’, and ‘associate’.²⁴ The eight platinum members have the largest influence over the governance and direction of the AAIF and are currently: AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI.²⁵ The AAIF charter specifies a ‘Platinum Member Cap’ mandating that ‘at no time may there be more than eight (8) Platinum Members.’²⁶ The current eight platinum members, as well as the platinum cap, have been in place since the launch of the AAIF.²⁷

The AAIF is managed by a Governing Board (GB) holding responsibility over the budget, overseeing outreach, and reviewing proposals for additional projects to the foundation.²⁸ Each platinum member is entitled to appoint a single representative to the GB, and gold members are collectively represented by a single representative. Silver and associate members have no representation on the GB – a notable departure from other LF directed funds, including the PyTorch Foundation and the CNCF (see Table 1).²⁹ Alongside the GB, the AAIF establishes a Technical Committee (TC) for the purpose of overseeing best practices and the technical vision of the foundation.³⁰ As for the GB, each platinum member of the AAIF is entitled to appoint one representative to the TC.³¹ There is no representation for gold, silver, or associate members on the TC, which again departs from other LF directed funds. For example, gold members of the PyTorch foundation have one representative on the ‘Technical Advisory Council’ per three members, which are selected by the gold members themselves (see Table 2).

Membership Tier	AAIF	CNCF	PyTorch
Platinum	1 representative from each member	1 representative from each member	1 representative from each member
Gold	1 representative	1 representative per 5 members, up to a maximum of 3	1 representative per 3 members
Silver	None	1 representative per 10 members, up to a maximum of 3	1 representative per 10 members, up to a maximum of 3
Other	None	The chair of the Technical Oversight Committee; The chair of the End User Technical Advisory Body; Two committers elected from CNCF projects	1 Associate member representative; 1 representative from the Technical Advisory Council

Membership Tier	AAIF: Technical Committee (TC)	CNCF: Technical Oversight Committee (TOC)	CNCF: End User Technical Advisory Body (End User TAB)	PyTorch: Technical Advisory Council (TAC)
Platinum	1 representative from each member	N/A	1 representative from each platinum end user member32	1 representative from each member
Gold	None	N/A	1 representative per 5 gold end user members, up to a maximum of 3	1 representative per 3 members
Silver	None	N/A	1 representative per 10 silver end user members, up to a maximum of 3	None
Other	None	Governing Board elects 6; End user Members elect 2; Non-sandbox project maintainers elect 1; Existing TOC Members elect a further 2	At least 3 by end users at large; 1 or 2 TOC members (each of whom must be employed by an end user member); 1 or more additional representatives from end user members	One representative from each ‘TAC project’

Comparison and Discussion

Given this overview of both IETF’s and AAIF/MCP’s governance structures, the clearest difference is between the ways in which senior leadership positions are filled. Whereas all but one member of AAIF leadership are representatives of a permanent set of eight private companies and MCP leadership is by invitation only (and currently consists wholly of employees from those same eight companies), a large number of IETF leadership are elected by a random draw of engaged, rank-and-file contributors. Furthermore, while AAIF and MCP contain no pathways through which unpopular leadership can be removed by the community, IETF leadership largely serves two-year fixed terms, and can be removed by a similarly random selection of contributors. Overall, while employees of private companies are represented in both

IETF and AAIF/MCP leadership, the differences in governance structures mean that those engaged in the former are able to be held accountable to their actions by the broader community in ways which aren’t seen in AAIF/MCP.

It may be argued that the comparison is invalid: the IETF and AAIF are products of very different circumstances, working in different contexts. One could also argue that the IETF is a unique and distinctive organisation that is not without its flaws, and therefore, aiming to replicate it is misguided. However, we do not argue that governance structures employed by the IETF should be reproduced exactly in the case of the AAIF or MCP. Rather, it provides an informative demonstration of potential frameworks for promoting openness and participation in protocol development. Furthermore, when comparing the AAIF to other LF directed funds, such as CNCF and the PyTorch Foundation, a number of noteworthy differences are apparent – including the differences in GB and TC representation referenced above. First, the ‘platinum cap’ observed in the AAIF above is not found in other directed funds. Second, the AAIF charter specifies a ‘startup period’ lasting three years within which amendments to the charter, the adoption of new rules or policies, an increase to the ‘platinum cap’, and the approval of additional projects can be vetoed by platinum members that have contributed projects to the AAIF.³³ This ‘startup period’ also appears to be unique to the AAIF. Finally, it is worth pointing out a number of features of the CNCF that are absent from the AAIF. The CNCF charter includes a ‘values’ section, that explicitly lists ‘neutrality’ as a core value, stating that the CNCF ‘avoid[s] influence, biased behavior, “pay-to-play” decision-making, and other activities that favor one project, individual, or organization over another’ (CNCF Charter, §3(c)). The CNCF also allows for members to be designated as ‘end user’ organisations, which explicitly excludes companies developing or distributing CNCF technologies, with a separate board (the ‘End User Technical Advisory Body’) reserved solely for such members (CNCF charter, §7-8).

When it comes to MCP itself, stewardship explicitly takes the form of a ‘Benevolent Dictator For Life’ (BDFL) model with the two lead maintainers holding ultimate decision-making authority. Since MCP’s donation to the AAIF, its governance structure has become increasingly formalised, including the provision that only lead maintainers are able to propose amendments to the governance structure [86]. At time of writing, there is also a notable amount of overlap between the MCP core maintainers, the AAIF GB, and the AAIF TC. In particular, an MCP lead maintainer is the chair of the TC, the TC co-chair is an MCP core maintainer, and a third individual is simultaneously an MCP core maintainer and a representative on both the TC and GB.³⁴ In contrast, Kubernetes, a project under the CNCF, has a seven-member steering committee elected to two-year terms by active contributors to the project.³⁵ A closer comparison is PyTorch, which, while also adopting a BDFL structure, includes a provision such that a super-majority of core maintainers can choose to remove the lead maintainer.³⁶

The picture that emerges is one in which numerous design choices, each of which might seem inconsequential in isolation, collectively centralise decision-making authority in a small number of tech companies and their employees, with limited routes to community accountability or representation. This pattern is not unprecedented in the AI industry: Widder et al. [93] observe that

some companies have moved to embrace ‘open’ AI as a mechanism to entrench dominance, using the rhetoric of ‘open’ AI to expand market power while investing in ‘open’ AI efforts in ways that allow them to set standards of development while benefitting from the free labor of open source contributors.

In this context, the donation of MCP to AAIF warrants scrutiny. The donation does not affect MCP’s BDFL model and lack of mechanism for removing lead maintainers, the platinum cap restricts engagement with the AAIF at the highest levels, and the three-year startup period in the AAIF charter means that structural amendments to the foundation can be vetoed by any of Anthropic, Block, or OpenAI. This is noteworthy given the absence of any acknowledgement or policy regarding potential conflicts of interest or a ‘values’ section of the charter – as seen for CNCF.

While we do not make any claim that this authority is being abused, we note that it does create the possibility of unaccountable use of this power in ways that may not be in the broader community’s interest. Concretely, lead maintainers could steer the protocol in a direction that favours their own models or infrastructure, or block functionality that benefits competitors. Less dramatically, leadership could refuse to implement important functionality if it is not aligned with the interest of their employer(s), including some security measures.

Potential responses to these concerns include that a concentrated power structure is necessary to ensure the stability and coherence of MCP governance and strategy while the project is rapidly scaling, and that this will be relaxed once the rate of development slows. However, other than the aforementioned ‘startup period’ in the AAIF charter, there is no mention of any governance structures being time-limited. Furthermore, actions taken by leadership, such as restricting the right to propose governance amendments to lead maintainers, mean that any decision to increase accountability and representation can only be made by two people [86]. Alternatively, one might argue that contributors and community members that are unhappy with the governance structures are free to work on an alternative project, or fork the repository to proceed in a different direction. However, while such defection is theoretically possible, given MCP’s current scale and extent of corporate adoption, direct competition is likely infeasible in practice, and is further hindered by the fact that many potential corporate backers of an alternative protocol already support MCP through the AAIF. Additionally, this argument assumes that only contributors have a valid interest in how MCP is governed. However, given that MCP is often referred to by its own stewards as becoming ‘critical infrastructure for AI’ [64], it is not unreasonable for individuals who are not involved in its development to be concerned with how it is governed.

Ultimately, there is a question of legitimacy when it comes to who gets to control ‘critical infrastructure’, whether relating to the internet, AI, or otherwise. As highlighted by DeNardis [30], ‘if technical standards make public interest decisions, the questions of who sets technical standards and how they set them are highly relevant.’ While the IETF – a technocratic, small (on the order of thousands), and unrepresentative subset of the population that’s responsible for infrastructure used by billions – may not be a paragon of democratic legitimacy, its adoption of unique governance mechanisms aimed at increasing participation and accountability can provide inspiration for individuals and organisations leading the development of AI protocols. Should MCP achieve its stated aim of becoming ‘critical infrastructure for AI’ with the current governance structures in place, this would represent a significant concentration of authority over a technology with far-reaching implications, grounded primarily in the speed of its adoption.

Discussion

Overall, the preceding two sections combine to paint a cautionary picture. If steps are not taken early to implement security, the ecosystem may burden itself with a persistent security deficit with ever-increasing costs of retrofitting. This security deficit may emerge alongside entrenched governance structures that preserve corporations’ primacy with regards to long-term decision-making, while public statements emphasise community input and participation.

Notably, these conclusions may be in tension: it is plausible that the more concentrated power structure of MCP/AAIF is beneficial or even necessary for ensuring the security of MCP, since key design features that enhance security could hypothetically be prioritised from the top down. The concepts of input and output legitimacy, introduced by Scharpf [82] in the context of the European Union, and Schmidt [83]’s extension to ‘throughput’ legitimacy may be a relevant framing here, having been applied to internet governance in [66]. Input legitimacy refers to the extent to which governance is ‘by the people’ – i.e., that subjects’ views, preferences, and beliefs are taken as inputs to the governance processes. In contrast, output legitimacy refers to the extent to which governance is ‘for the people’ – i.e., that the actions or decisions taken as a result of a governance process serve subjects’ interests. Throughput legitimacy adds an intermediate layer, concerning the processes by which governance decisions are made, for example, whether they are transparent and accountable. In this paper, while we make no assessment of MCP or AAIF’s output legitimacy, instead observing multiple features of their input and throughput legitimacy. Whilst MCP’s openness to contributions from the broader community may in some cases lead to increased input legitimacy, AAIF’s cap on the number of platinum members and restricted representation on its governing board may decrease input legitimacy. Regarding throughput legitimacy, MCP’s transparency on account of it being developed open source is counteracted by limited mechanisms for holding leadership accountable for design decisions. Schmidt [83] argues further that a lack of throughput legitimacy can serve to ‘delegitimate both input and output’. In the case of MCP, this would imply that output legitimacy, perhaps in the form of increased security, could be undermined by an illegitimate development process.

In this paper we have largely focused on MCP as an archetypal case study for AI agent protocols due to its status as the most widely adopted AI agent protocol. However, the broad effects observed here concerning the practical and economic challenges of retrofitting security, and the nature of governance and representation, are generalisable regardless of the specific project in question. Should MCP become defunct or outcompeted by an alternative, we believe that whatever project takes its place will have to contend with similar security considerations. While the discussion of governance structures in § 4.2 and § 4.3 is specific to MCP and the AAIF, we focus on these structures because of MCP’s rapid uptake among users and business – making the question of how it is governed particularly consequential.

Our conclusions carry several practical implications. First, policymakers should accept that de facto standardisation can come from sources outside of traditional SDOs and policymaking institutions. NIST’s recent AI Agent Standards Initiative, which actively engages with industry-led protocols development reflects a growing acknowledgement of this reality.³⁷ Ignoring such developments while following traditional formal standards setting processes risks being outcompeted by more nimble, industry-led efforts. Second, claims of projects being ‘open, neutral and community-driven’ should be approached with a critical eye, and judgements should be based on how such projects operate in practice, rather than public statements. Third, the observed difficulty with which security was retrofitted to internet protocols should be taken as a lower bound for that which could be faced by the ecosystem of AI agent protocols. Finally, there is an important unanswered question of designing protocol governance structures that are simultaneously nimble and maintain sufficient representation and accountability for community interests, including security, to be taken seriously. We encourage protocol developers, policymakers, and affected communities to proactively engage in debate and experimentation on this issue.

Acknowledgments

The authors would like to thank Alan Chan, Maike Osborne, Amin Oueslati, Patricia Paskov, Huw Roberts, Chris Schmitz, Merlin Stein, and Marta Ziosi for comments and feedback.

References