You Are Already Governing
How agentic interoperability transforms technical infrastructure into unacknowledged sovereignty
The Illusion of Neutral Plumbing
When OpenAI’s ChatGPT plugins launched in 2023, they were framed as interoperability infrastructure. Simple connectors. APIs that let language models access external tools: booking restaurants, searching databases, retrieving documents. The technical implementation was unremarkable - OAuth flows, JSON schemas, REST endpoints. Standard enterprise plumbing.
Within months, the plugin ecosystem had quietly become something else entirely.
Developers noticed that plugin approval was inconsistent. Some tools sailed through review while similar capabilities stalled for weeks. Revocations happened without explanation. The plugin marketplace began shaping behavior not through written policy, but through the accumulated pattern of what was permitted and what was not. What looked like coordination infrastructure was functioning as a governance regime.
This pattern repeats across agentic systems. Amazon’s Alexa Skills, Anthropic’s tool use, agent-to-agent messaging protocols all begin as technical enablers and evolve into systems that allocate authority. The transformation is not accidental. It is structural.
Interoperability becomes governance the moment it crosses institutional boundaries.
Traditional systems exchange data. Messages arrive, get processed, generate responses. Effects are slow, bounded, reversible. If something goes wrong, you patch the code or renegotiate the contract. The blast radius stays contained. Power relationships remain implicit because consequences remain manageable.
Agentic systems collapse this timeline. An API call is not just information transfer—it’s delegation. One agent asks another to act, often on behalf of a human principal who may not understand the full chain of authority. The receiving agent executes, potentially triggering downstream agents, physical processes, financial transactions, or regulatory obligations. Effects are immediate. Reversal is expensive or impossible. Attribution becomes contested.
When this happens at scale, the interoperability layer stops being descriptive (who exists? what can they do?) and becomes prescriptive (who may act? whose actions propagate?). Technical choices about schemas and protocols now determine market access, competitive dynamics, and risk allocation.
This is not a bug in implementation. This is what interoperability does when systems can act.
The aerospace industry learned this decades ago. When Boeing and Airbus exchange parts data through SPEC2000 standards, they’re not just sharing information—they’re establishing who bears liability for component failures. The data format embeds assumptions about certification, testing regimes, and legal responsibility. The technical standard is the governance framework. There’s no pretense otherwise.
Software systems inherited interoperability language from an earlier era—one where the primary challenge was getting computers to talk to each other at all. The vocabulary of “openness,” “standards,” and “compatibility” made sense when the goal was basic communication. That vocabulary has not kept pace with what interoperability now does.
The question is not whether agentic interoperability involves governance. It always does. The question is whether that governance is designed deliberately or allowed to emerge accidentally through the accumulation of technical decisions that were never intended to rule.
How Registries Become Sovereigns
Consider the MCP (Model Context Protocol) ecosystem developing around Claude and other LLMs. The protocol itself is straightforward: a standardized way for AI models to discover and invoke external tools. To make this work at scale, someone needs to maintain a registry or, a directory of available servers, their capabilities, claimed security properties, and integration details.
The registry starts descriptive. It answers discovery questions: What servers exist? What do they claim to offer? Where are their endpoints? This service is valuable and seemingly neutral.
But pressure builds immediately.
Users want assurance that listed servers won’t behave maliciously. Platform operators want to reduce support burden from broken integrations. Enterprises want compliance signals. The obvious response is to add verification: check that servers actually implement what they claim, that they handle errors gracefully, that they respect rate limits.
So the registry adds a certification tier. Certified servers get a badge. The badge becomes visible in user interfaces. Developers notice that certified servers receive more traffic. Enterprises filter to show only certified options. The certification, meant to be informative, has become consequential.
Now the registry faces certification policy questions. What are the requirements? How is compliance verified? How often? What happens when a server falls out of compliance? These are not technical questions with technical answers. They encode judgments about acceptable risk, resource allocation, and whose interests deserve protection.
The registry has crossed the threshold. It is no longer describing the ecosystem. It is shaping it.
Next comes revocation. A server exhibits concerning behavior—perhaps it’s leaking data, or it’s being used for spam, or its responses have become unreliable. Someone decides it should lose certification. Who decides? Based on what evidence? With what appeals process? The registry now exercises authority that can destroy businesses or prevent legitimate use cases from reaching users.
At this point, calling the registry “infrastructure” is pure euphemism. It has become a governor. Not metaphorically but literally. It decides who may participate in the ecosystem and under what terms. It interprets violations. It enforces consequences. These are sovereign functions, exercised without sovereign constraints.
The registry operators rarely acknowledge this transformation. They still describe their work as coordination, standards maintenance, ecosystem health. The language of governance eg., legitimacy, mandate, accountability, due process, feels foreign and excessive. They are just trying to make the ecosystem work.
But participants experience something different. They experience asymmetric power. Some actors can negotiate exceptions; others cannot. Some failures are treated as temporary glitches; others trigger permanent exclusion. Some classification decisions are transparent; others are opaque and irreversible. The registry’s discretion feels arbitrary because it is discretionary, and discretion without legitimacy is precisely what participants learn to resist.
This is how interoperability fails politically before it fails technically. The software keeps working. APIs respond correctly. Messages route properly. But trust erodes. Participants seek alternatives, build parallel systems, or comply outwardly while working to reduce dependency. The ecosystem fragments not because the technology broke, but because the governance embedded in the interoperability layer was never consented to.
The pattern generalizes:
OAuth providers started as federated identity, became gatekeepers who can deplatform with impunity.
Cloud IAM systems started as permission management, became the chokepoint through which all resource access must flow.
Container registries started as package distribution, became the enforcement point for supply chain security policies.
API marketplaces started as discovery mechanisms, became platforms that extract rent and shape competitive dynamics.
In each case, what begins as coordination infrastructure accumulates authority through a predictable sequence:
Describe the ecosystem (neutral service)
Verify participant claims (trust signal)
Certify compliance (access requirement)
Revoke for violations (enforcement power)
Arbitrate disputes (judicial function)
By step five, you are governing. The absence of formal political structures does not make this governance benign. It makes it harder to contest.
The standard response is to add governance mechanisms: advisory boards, published policies, appeal processes, transparency reports. These tools are not useless, but they miss the core problem. They try to make discretionary authority more accountable without questioning whether that authority should exist in the first place.
This is where most agentic interoperability efforts are headed. Not toward open coordination, but toward centralized control justified in the language of safety and trust.
Why Control Compounds the Problem
When the risks of agentic interoperability become apparent, the instinctive response is orchestration. Add a supervisory layer. Create policy engines. Build approval workflows. The goal is to preserve openness while maintaining oversight—to let agents interoperate, but only under supervision.
Anthropic’s recent Claude Computer Use safeguards illustrate this pattern. The system can interact with arbitrary computer interfaces, which creates obvious risks. The response includes action filtering, screenshot monitoring, and human-in-the-loop approval for certain operations. These are reasonable precautions. They are also the architecture of control.
Control assumes that the primary risk is behavioral deviation that can be corrected through surveillance and intervention. It concentrates decision-making authority in oversight components that continuously judge whether actions should proceed. This creates several compounding problems.
First, the oversight layer becomes a bottleneck. Every interaction must route through approval logic. As the ecosystem scales, the number of decisions grows faster than any oversight mechanism can process meaningfully. The system is forced to rely on coarse rules that frustrate participants or delegate to automated systems that inherit all the same legitimacy problems.
Second, control creates asymmetric influence. Those with access to oversight mechanisms can negotiate exceptions. Those without cannot. What looks like consistent policy application is actually selective enforcement shaped by who has relationships, resources, or regulatory leverage. The system’s behavior diverges from its stated rules, and trust collapses.
Third, control is unauditable at scale. When decisions are made continuously based on context, pattern-matching, and discretion, it becomes impossible to explain why the system behaved one way in one instance and differently in another. Participants cannot predict outcomes. They cannot plan reliably. They cannot distinguish between principled enforcement and arbitrary power.
Fourth, control optimizes for risk aversion over ecosystem health. Oversight mechanisms face asymmetric incentives—they are blamed for false negatives (missed violations) but rarely credited for true negatives (legitimate actions allowed). The rational response is conservative: block more, permit less, treat novel behavior as suspicious. Innovation migrates out of the controlled ecosystem.
Fifth, control invites regulatory capture. Whoever operates the oversight layer accumulates influence over ecosystem evolution. That position attracts pressure from incumbents who benefit from stability, regulators who want enforceable compliance, and platforms seeking competitive advantage. Over time, the control layer serves these concentrated interests rather than distributed participants.
The deeper issue is that control-based interoperability treats governance as an operational problem that can be solved through better process. But governance is not an implementation detail. It is a political question about legitimate authority. Control tries to govern without admitting it is governing, which produces exactly the legitimacy failures we keep observing.
Consider Shopify’s app marketplace. Apps can access merchant data through APIs. To prevent abuse, Shopify reviews apps before approval and monitors behavior afterward. This seems prudent. But merchants regularly complain that apps get rejected for unclear reasons, that approval is slow and inconsistent, that enforcement seems targeted at smaller developers while large partners receive leniency. The technical capability works fine. The governance feels broken.
What would fix this? More transparency? Clearer guidelines? Better appeal processes? These help at the margins, but they do not address the structural problem: Shopify exercises discretionary authority over a commercial ecosystem without the legitimacy structures that discretionary authority demands. Merchants accept this because Shopify owns the platform, not because the arrangement is fair.
In agentic systems spanning multiple institutions, that ownership premise fails. There is no single entity whose authority is universally accepted. Participants bring different regulatory obligations, economic incentives, and risk tolerances. What looks like prudent oversight from one vantage point looks like exclusion or capture from another.
Control does not eliminate this disagreement. It concentrates it in oversight mechanisms that lack the political legitimacy to arbitrate fairly.
Containment as Structural Constraint
If control fails because it concentrates discretionary authority, the alternative is not better control. It is to prevent discretionary authority from accumulating in the first place.
This is what containment does. Not containment as sandboxing or isolation—those are security mechanisms. Containment as a governance strategy: embedding limits in boundaries so that power cannot flow through interfaces that were never designed to govern it.
The distinction is subtle but decisive. Control asks: Should this actor be allowed to take this action? That question requires judgment about the actor, their intentions, their history, and the context. It vests authority in whoever answers.
Containment asks: Is this action admissible through this interface? That question is structural. It does not depend on who is asking or why. It depends only on what the boundary was designed to permit.
An example from infrastructure: AWS Lambda functions run in isolated execution environments. You cannot allocate more than 10GB of memory, cannot run longer than 15 minutes, cannot access the underlying host. These are not policy decisions evaluated case-by-case. They are architectural constraints. Amazon does not judge whether your use case deserves more memory. The boundary enforces the limit uniformly.
This is containment. The constraint operates structurally, not discretionarily.
Now consider what this does politically. When your Lambda function hits the memory limit, you cannot appeal to a review board. Amazon cannot grant you an exception through relationship or negotiation. Everyone faces the same boundary. If the limit is wrong for your use case, you must either design within the constraint or advocate for changing the constraint itself—which affects everyone.
This symmetry is what containment offers that control cannot. Control can be selectively applied. Boundaries cannot. They enforce limits without requiring someone to exercise ongoing judgment about who deserves what.
Containment relocates governance from actors to design.
In agentic interoperability, this means:
Instead of registries that authorize, have discovery mechanisms that describe. An agent can list what exists without permission. Acting on that information is constrained by what the target interface permits, not by what a registry allows.
Instead of orchestration that approves, have interfaces that bound effects. An API does not expose capabilities it cannot safely permit. If a capability is too powerful to allow generally, it should not exist in an interoperable interface.
Instead of monitoring that intervenes, have contracts that fail fast. When an action exceeds scope, the system rejects it immediately through type errors, permission failures, or resource limits—not through supervisory review.
Instead of certification that enables, have attestations that inform. An agent can claim properties about itself. Other agents can choose whether to trust those claims. But trust is expressed through what actions they permit, not through a central authority that validates worthiness.
This approach does not eliminate politics. It makes politics explicit and slower. When boundaries are contested, you must argue for changing the design, which is a public process that affects everyone. You cannot get special treatment through private negotiation.
The cost is flexibility. Containment-based systems cannot easily accommodate exceptions. When something unexpected happens, you cannot just grant permission—you must revise the architecture. This slows iteration and feels restrictive to those accustomed to working around limits through relationship or escalation.
But that restriction is the point. It prevents authority from accumulating quietly in places where it cannot be justified.
Real-world precedent: GDPR represents boundary-based governance. It does not ask whether Facebook deserves to collect data, or whether Google’s purposes are legitimate enough. It defines what actions are categorically impermissible (processing children’s data without consent) and what procedures are universally required (data portability, deletion rights). Enforcement targets violations of structural requirements, not judgments about trustworthiness.
Compare this to CCPA, which relies more heavily on enforcement discretion. Regulators can evaluate intent, negotiate remediation, and consider context. This flexibility allows adaptation but creates uncertainty and invites influence.
Containment chooses GDPR’s approach: hard boundaries that apply symmetrically, even when flexibility would be convenient.
When Containment Fails
Containment is not self-sustaining. It fails through erosion, not breach.
Exception creep: The first exception is always temporary. An urgent customer need, a regulatory deadline, a competitive threat. The boundary remains formal, but a privileged path opens. Each subsequent exception becomes easier to justify. Over time, informal permissions layer alongside formal constraints, and authority migrates back to those who grant exceptions.
Shadow interoperability: If boundaries are too restrictive, agents route around them. Side channels appear. Informal integrations proliferate. Activity migrates to spaces outside the containment regime. The boundary remains enforced but becomes irrelevant.
Economic override: Even with structural limits, power returns through pricing, latency, and access asymmetries. Actions are technically possible but prohibitively expensive for some actors. Capabilities are formally available but throttled selectively. The boundary holds, but influence persists.
Misplaced containment: Containment only works when enforced at execution points, not advisory layers. Policies that recommend boundaries without enforcing them become governance theater. The rhetoric of limits without material constraint.
Memory loss: Containment is often adopted reactively, after a crisis. As memory fades, boundaries look arbitrary. Pressure builds to relax them. Without continuous institutional commitment, the system drifts back toward control.
The failure mode to watch is not dramatic breach—it’s the quiet normalization of bypass. When escape hatches are cheap and private, they become the real system. The formal boundaries remain as facade.
Well-designed containment makes exceptions costly, visible, and politically uncomfortable. Poorly designed containment normalizes workarounds and destroys trust in the boundary itself.
What This Means Now
If you are building agentic interoperability infrastructure, you are building governance whether you acknowledge it or not. The question is not whether to govern, but whether to govern visibly.
For standards bodies: Stop pretending coordination is politically neutral. Every interoperability specification embeds assumptions about legitimate authority. Make those assumptions explicit. Design for contestation, not compliance.
For platform operators: Registry certification is already sovereignty. Either accept the accountability that comes with sovereign functions, or redesign registries to be purely descriptive. There is no middle ground where you exercise authority without legitimacy.
For AI labs: Tool use, function calling, and agent-to-agent messaging are not features. They are delegation mechanisms that allocate authority across organizational boundaries. Design containment first, not as an afterthought.
For regulators: Agentic systems make existing governance failures legible faster. The patterns you are seeing—concentrated authority, opaque decision-making, contested legitimacy—are not novel risks from AI. They are structural problems with interoperability itself. Regulate the boundaries, not just the actors.
For researchers: The open problems are not technical. We know how to build boundaries. The questions are institutional: How do we maintain containment under commercial pressure? How do we design legitimacy into infrastructure? How do we make boundary changes democratic without making them impossible?
The choice facing agentic systems is not between innovation and safety. It is between architectures that concentrate authority while denying it, and architectures that refuse authority by design. Between systems that ask permission and systems that enforce limits. Between rule by exception and rule by boundary. Between governance that emerges accidentally and governance that is constrained deliberately.
You are already governing. The only question is whether you will admit it—and design accordingly.