Protocol and the Control Hidden Inside Decentralization
Alexander R. Galloway's Protocol is an early and still useful theory of network power. Its central lesson is that decentralization does not remove control. It relocates control into standards, addresses, interfaces, naming systems, defaults, and the technical rules that decide what can connect.
For this review, a protocol is not just a technical convention. It is a rule layer that makes connection possible by defining valid actors, messages, addresses, permissions, formats, errors, and handoffs. The political question is who can inspect that layer, who can change it, who is logged by it, and who has a practical path out.
The Book
Protocol: How Control Exists after Decentralization was first published by MIT Press in hardcover in 2004, with paperback and ebook editions following in 2006. MIT Press lists it in the Leonardo series and describes it as a study of whether the internet is best understood as open communication or as a regulated technical bureaucracy.
Galloway's argument is direct: the internet's founding condition is not pure freedom but protocol. The network works because machines agree to rules. Those rules do not merely carry information. They define what counts as a valid address, packet, request, route, domain, format, connection, and failure.
This makes the book unusually valuable for readers who want to understand power after the obvious center disappears. The old question asks who commands the network. Galloway asks how command persists when no single visible commander is necessary.
Current Context
As of June 23, 2026, the word protocol is no longer a historical metaphor for AI governance. The Model Context Protocol is documented as an open standard for connecting AI applications to external systems; its tools and resources mechanisms let servers expose actions and contextual data to clients. Its authorization specification brings OAuth-style resource-server and client roles into the agent stack. That is exactly the kind of rule layer Galloway trained readers to see.
NIST's AI Agent Standards Initiative, announced on February 17, 2026, puts the same issue into standards language: autonomous agents need secure operation on behalf of users and interoperability across digital systems. The Linux Foundation's Agent2Agent project and its 2026 version 1.0 materials frame agent discovery, agent cards, authentication, task state, and protocol bindings as production infrastructure, not speculative fiction.
The practical conclusion is narrow but important. A protocol can increase interoperability without proving that a deployment is safe, fair, private, or accountable. The governance work starts after the connector exists: which actor gets authority, which scopes are granted, how credentials expire, what gets logged, what untrusted content can influence, and how a user or institution can revoke the pathway.
Protocol Power
Protocol power is quiet because it looks like compatibility. IP, DNS, HTML, routing policy, file formats, authentication standards, API schemas, platform policies, model endpoints, and agent tool registries all promise interoperability. They also impose grammar.
RFC 791 describes Internet Protocol as a way to transmit datagrams between hosts across interconnected packet-switched networks, with rules for addressing, fragmentation, and gateway behavior. RFC 1034 describes DNS as a distributed database with a hierarchical naming structure. IANA's root-zone materials make the hierarchy operational: the DNS root zone is the highest level of the naming hierarchy, with root name servers configured as 13 named authorities and operated through a global anycast infrastructure.
That technical modesty is exactly why Galloway matters. A rule that decides what counts as a valid packet, name, route, credential, tool call, or response does not need to sound ideological to organize the possible. It allocates power by deciding who can speak, how identity is represented, where failure is detected, what gets dropped, what remains invisible, and which actors can later revise the rule.
Decentralization Is Not Escape
Protocol is most useful when it punctures the romance of decentralization. A distributed network can still be governed. It may be governed less by a throne and more by standards bodies, root-zone processes, browser vendors, cloud providers, identity layers, app stores, certificate authorities, API gateways, model providers, and defaults that ordinary users never inspect.
Galloway's signature example is the contrast hiding inside the book's own list: packet networking versus naming. IP is designed for forwarding datagrams across interconnected networks rather than for routing every communication through one command center. DNS, by contrast, gives human-readable names a hierarchy. The system is distributed in operation, but its resolution model still depends on root-zone data and root-server authorities. Galloway's compact phrase is that DNS "vertically stratifies" the horizontal logic of packet exchange.
That pairing compresses the thesis. Decentralization at one layer does not abolish hierarchy; it can move hierarchy to a layer most users never see. The same pattern now appears in platform governance: an application may advertise open APIs while a private console controls keys, rate limits, moderation policy, ranking, account suspension, regional routing, and export. See the site's platform governance and vendor governance pages for the operational version of this problem.
The 2004 review in Neural read Galloway this way: technical standards enable large-scale infrastructure while also shaping the forms of expression that can appear inside it. That is the right emphasis. A protocol is not only a pipe. It is a social filter that has been made operational.
This is why the book has aged better than many early internet texts. It was written against utopian claims about the liberating network, but its deeper object is not the early web. Its object is any system where governance hides inside the condition of participation.
The AI-Age Reading
AI makes Galloway's argument newly practical. A model ecosystem is full of protocols: prompt formats, API schemas, tool-call conventions, context windows, system messages, safety classifiers, model-card templates, authentication scopes, eval thresholds, content provenance formats, memory export rules, and agent permission layers.
These are not neutral wrappers around intelligence. They shape what the system can remember, which tools it may invoke, how it identifies a user, what counts as an allowed request, when a human must approve an action, and how an institution can audit what happened afterward.
The agent-native internet intensifies the issue. When software agents browse, negotiate, purchase, schedule, submit forms, write code, and operate other software, protocols become behavioral law. The important control point may not be the visible chatbot. It may be the permission token, browser automation interface, MCP server, A2A agent card, API gateway, payment rail, logging standard, or policy file that decides what counts as a valid action.
The model router is a working example: a layer most users never see, quietly choosing which provider, version, and policy actually answers a request. The tool-server trust boundary is another. A connector that can read files, call APIs, or run commands is not a passive bridge. It is an authority surface.
Governance and Safety
The governance test for a protocol is not whether it feels open. It is whether the rule layer can be inventoried, constrained, observed, and changed without pretending that the interface is the whole system.
Every consequential protocol should have a register entry: owner, version, participating actors, allowed transports, authentication method, authorization scopes, data classes, write powers, retention class, logging fields, revocation path, exception process, and migration or exit plan. For agent protocols, the register should also identify who may install new servers, who may approve tool discovery, which actions require a human gate, and how untrusted content is isolated before it reaches model instructions or tool parameters.
Safety follows from that inventory. Use least-privilege scopes, short-lived credentials, explicit approval for consequential writes, server allowlists, sandboxing for code or browser control, and logs that are strong enough for incident review without becoming a second privacy breach. OWASP's MCP Top 10 is useful here because its risks are protocol-shaped: token exposure, scope creep, tool poisoning, command execution, insufficient authorization, missing audit telemetry, shadow servers, and context over-sharing.
This makes agent observability, agent identity, sandboxing, prompt-injection defense, data minimization, and AI assurance part of protocol governance rather than documentation afterthoughts. A system that cannot show who acted, through which rule layer, with which authority, against which data, is not governable in practice.
Resistance and Its Limits
Galloway does not present protocol as a sealed machine. MIT Press notes that the book turns to hackers, viruses, cyberfeminism, internet art, and tactical media as examples of subversion inside network culture. The point is not escape from rules but pressure on the rule-making layer.
That distinction matters. A hack is not only a breach. It can be a demonstration that the system's categories are contingent: a different route, a malformed request, a fork, a refusal, a parody interface, a new client, a reverse-engineered standard, a protocol extension, an interoperable export, or a public exploit that makes hidden assumptions visible.
In AI systems, the constructive form of resistance is often boring and institutional: protocol test suites, portable logs, independent clients, documented appeal paths, public-interest standards work, permission receipts, model-route records, content-provenance checks, and procurement terms that preserve exit. These are not romantic gestures, but they change who can contest the rule layer.
But resistance can also be absorbed. Once a platform standardizes the workaround, monetizes the deviance, or converts the fork into a feature, the gesture becomes another option in the menu. Protocol power is hard to fight because it can translate opposition into compatibility.
Where the Book Needs Friction
The book's weakness is that its conceptual strength can sometimes outrun institutional specificity. Not all standards operate alike. An open internet standard, a private API, a safety policy, a browser default, a biometric database, and a model vendor's tool schema each distribute authority differently.
That difference matters for governance. Some protocols are publicly documented and can be implemented by many actors. Some are controlled by firms. Some are shaped by states. Some are nominally open but practically dominated by infrastructure incumbents. Some are standards in name and chokepoints in practice.
The book also predates cloud hyperscalers, app-store governance, OAuth at platform scale, content moderation infrastructure, commercial model routing, and agent protocols. That does not make the argument obsolete. It means the reader has to carry the thesis into a thicker institutional world. Open protocol design, private deployment, vendor policy, legal compliance, and operational safety are related but not interchangeable.
Academic reception shows the book as part of a broader debate rather than a final theory. Convergence published Greg Boiarsky's review in 2006, and PhilPapers records James Tobias's 2005 review in Radical Philosophy. The continuing usefulness of the book is not that every sentence settles the politics of networks. It is that it gives readers a durable question: where has control moved when the center is gone?
What This Changes
Protocol is a book about the governance layer beneath the interface.
Modern systems often arrive as surfaces: chat windows, feeds, dashboards, companions, identity portals, workplace tools, moderation queues, and agent consoles. The surface invites users to think in terms of content and intention. Galloway pushes attention downward to the rule system that makes the surface possible.
That shift is essential for AI-era literacy. It is not enough to ask whether a model gave a good answer. Ask which protocol carried the request, what memory was attached, what identity was assumed, what tools were available, what safety layer intervened, what logs were retained, what vendor gained dependency, and who can change the rules without the user's consent.
The practical lesson is simple: audit the grammar of participation. Any system that defines the terms of connection also defines a politics. Decentralized language, open rhetoric, and friendly interfaces do not cancel that politics. They often make it harder to see.
Source Discipline
The sources below should be read by type. MIT Press is evidence for the book's publication metadata and publisher framing. RFCs, IANA materials, MCP specifications, A2A specifications, and NIST pages are primary or official sources for protocol facts and current standards context. OWASP is a security-community risk framework, not a certification that any MCP deployment is secure.
Vendor or project documentation proves that a rule layer exists and describes how its authors say it should work. It does not prove that a specific deployment is safe, fair, private, or resistant to misuse. Those claims require local evidence: configuration review, permission registers, logs, red-team tests, incident drills, appeal records, and exit tests.
This review does not claim that AI systems are conscious, divine, or artificial general intelligence. Its concern is narrower and more verifiable: protocols can turn model output into institutional action, and that makes protocol governance a safety issue.
Related Pages
- Model Context Protocol
- Agent-Native Internet
- Agent2Agent Protocol
- Tool Use and Function Calling
- Agent Tool Permission Protocol
- Agent Prompt Hardening
- AI Agent Identity
- AI Agent Observability
- AI Agent Sandboxing
- The Tool Server Becomes the Trust Boundary
- The Agent Log Becomes the Receipt
- The Agent Becomes a Service Account
- The AI Browser Becomes the Control Surface
- The Platform Society and Public Values
- Vendor and Platform Governance
Sources
- MIT Press, Protocol: How Control Exists after Decentralization, book metadata and publisher description, reviewed June 23, 2026.
- RFC Editor, RFC 791: Internet Protocol, September 1981, reviewed June 23, 2026.
- IETF Datatracker, RFC 1034: Domain Names - Concepts and Facilities, November 1987, reviewed June 23, 2026.
- IANA, Root Zone Management and Root Name Servers, reviewed June 23, 2026.
- Anthropic, Introducing the Model Context Protocol, November 25, 2024, reviewed June 23, 2026.
- Model Context Protocol, What is the Model Context Protocol?, Tools, Resources, Authorization, and Security Best Practices, reviewed June 23, 2026.
- NIST, Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation, February 17, 2026, reviewed June 23, 2026.
- Linux Foundation, launch of the Agent2Agent Protocol project, June 23, 2025, and A2A version 1.0 adoption update, April 9, 2026, reviewed June 23, 2026.
- A2A Protocol, technical specification, reviewed June 23, 2026.
- OWASP Foundation, OWASP MCP Top 10, reviewed June 23, 2026.
- Neural, "Protocol, how control exists after decentralization", April 21, 2004, reviewed June 23, 2026.
- Greg Boiarsky, Convergence: The International Journal of Research into New Media Technologies, review of Protocol, 2006, reviewed June 23, 2026.
- PhilPapers, James Tobias, review of Protocol in Radical Philosophy, 2005, reviewed June 23, 2026.
Book links are paid affiliate links. As an Amazon Associate I earn from qualifying purchases.
- Amazon, Protocol by Alexander R. Galloway, affiliate listing reviewed June 23, 2026.