There’s a pattern emerging in the agent governance conversation that I think takes us in the wrong direction, and deserves to be challenged.
The argument is that existing protocols - like HTTP - were designed for humans, REST verbs can’t express agent intent, and we need new semantic methods at the protocol layer so agents can express what they’re trying to accomplish, not just what operation they’re performing on a resource.
I understand the appeal and why the sometimes-elaborate rhetoric proposing it seems to work. But this confuses what layer of the stack is responsible for what, and ignores history.
The credit card test
Consider credit card processing. The payment industry has some clear intent verbs: AUTHORIZE, CAPTURE, REFUND, VOID. Those words describe what ultimately happens, and nobody proposed replacing SOAP or REST with a “Payment Transfer Protocol” because HTTP “didn’t understand payment intent.” The transaction semantics live in the payload itself, the authorization lives in the credential, and the transport stays, well, dumb... Though “blissfully ignorant” is perhaps more appropriate. This approach has worked for decades at massive scale.
Nobody at Visa looked at this and said “POST doesn’t capture payment intent, so we need to add AUTHORIZE as an HTTP verb.” The transport moves the request, the payload carries the meaning, the credential carries the authorization. Three layers, each doing its job. Every proxy, load balancer, and WAF in the path handles the request normally because nothing about the transport changed.
Even though there’s more going on and potentially n moving parts thanks in part to the Anthropic-developed Model Context Protocol (MCP), the same logic applies to agent traffic. Whatever an agent is trying to accomplish is an application-layer concept. GET, POST, PUT, PATCH, DELETE describe operations on resources. Those aren’t broken; rather, they’re doing exactly what they were designed to do.
And if the argument is that HTTP’s method registry is frozen and can’t evolve, that’s not quite right either; in fact, it’s demonstrably false. PATCH was added via RFC 5789 [1], years after HTTP/1.1, through working group consensus. The process is slow because it should be slow. Extending a protocol that the entire internet relies on requires broad agreement that the extension is genuinely necessary at that layer. Application-intent verbs won’t clear that bar because they’re not operation semantics.
HTTP has been quietly extended this way for decades. OAuth moved from Basic Auth to Bearer tokens to DPoP proof-of-possession without ever leaving the protocol. W3C trace context headers added distributed tracing across services without changing how those services talked. MCP [2] is itself an extension built over HTTP via JSON-RPC, layering agent-tool conventions onto a transport that didn’t need to change. Every time someone claimed HTTP couldn’t handle X, the answer was an extension that fit within the existing protocol. Agent governance context is the next one, and those who are trying to engineer the future through another route are not truly participating in evolving the web.
The DKIM precedent
Governance context alongside agent requests is a different conversation entirely, and it’s the kind of opening where a platform or product can shim in and force itself to become indispensable. There are a lot of examples where this has proven a successful GTM strategy, but I don’t believe it’s good for the community as a whole.
Take the case of email: SMTP, POP, and IMAP all do the work of moving messages between systems. But in order to verify the origin of a message, we added DKIM [3]. It didn’t replace any of those protocols, but it DID add a cryptographic signature header to existing messages. Adoption was incremental; servers that understood DKIM got better trust signals and servers that didn’t kept working. Nobody had to upgrade everything at a single moment in time or pay to play.
DKIM didn’t change the protocol or add new email verbs. It added a signed header that travels with the message, and receivers who care about verification read it. Receivers who don’t, well, they ignore it. The email itself was unchanged and adoption was incremental, not all-or-nothing. And over time, DKIM became the foundation for DMARC policy enforcement built on top of its trust signals. In fact, it kind of paved the way.
The standards-based approach
This is not to say the new-protocol argument is completely without merit. Infrastructure-level identity visibility is a real concern, and if governance context lives only inside application payloads, proxies, gateways, and audit collectors can’t read it without parsing every request. Extending existing protocols with a Governance Envelope (GE) addresses this. It would carry signed, authenticated governance context in HTTP headers where any intermediary can inspect it. The transport sticks to its standard and the visibility happens at the header layer, the same place DKIM lives for email.
The envelope itself is transport-neutral. MCP is a natural first demonstration target because that’s where the agent ecosystem is currently converging, but the same pattern applies anywhere an agent crosses an execution boundary. That applies to MCP today, A2A and direct HTTP tool APIs, and whatever protocols come next. John Willis at Sustainable Future Tech independently arrived at the same architectural pattern, which he names the Governance Context Envelope (GCE), in AGCP Operating Model and Semantic Architecture [4]. Two practitioners landing on substantially the same architecture without coordination could be a coincidence, but I don’t think it is.
Agent governance context can work the same way. Agent identity, delegation chain verification, cumulative risk state, and provenance links can travel alongside existing MCP tool invocations as signed context, verified by servers that participate, invisible to servers that don’t. Each of these is produced by an existing standard: SPIFFE/SPIRE for identity, OAuth claims for delegation, NGAC attributes for cumulative risk, and OpenTelemetry for provenance traces. The enforcement stays at the MCP server, where it already has the authority to allow or deny tool execution.
Validation happens at the moment the MCP server is asked to invoke the tool, not when the envelope was generated. State changes between proposal and execution, obviously, because delegations expire, scopes get consumed, and cumulative sensitivity, well, accumulates from other invocations in the session. The envelope carries context among other things, but an enforcement decision needs to be tested against whatever the canonical auth-auth state is at invocation. I.e.: An envelope that was admissible ten seconds ago doesn’t survive into a tool call by inheritance.
But the single-invocation case is the easy one. Real workflows chain tool calls, and each link in the chain introduces its own considerations, like a cumulative sensitivity that didn’t exist at the start of the session, delegation that may have been valid for step one but is being stretched into step six, and provenance that needs to remain inspectable back to the originating intent. Chaining is a deeper problem than this article tries to solve, and John Willis at Sustainable Future Tech develops the formal semantics for what happens when multiple tool invocations contend at an enforcement boundary in his AGCP execution governance work [5]. The envelope composes with that model naturally, because the envelope is the context any such boundary needs to do its job.
The governance depth scales with the action’s consequence level. A low-risk MCP server doing calendar queries just checks the token, but a high-risk server handling financial transactions validates the full envelope. The server decides how much context it needs, configured per instance. The Governance Envelope makes business rules changeable at the speed of policy, not at the speed of transport protocol adoption.
Some action categories sit outside this depth-scaling logic entirely. Behavior manipulation, untargeted biometric aggregation, and the rest of the EU AI Act Article 5 list are categorically prohibited, and the server denies them without envelope inspection. This is also the “intolerable risk” defined in ISO 31000 (the vocabulary standard used by the ISO 42001 AI management standard).
And if the envelope is absent entirely (the agent doesn’t support it, or the governance infrastructure hasn’t been deployed yet), the server falls back to standard OAuth token validation or just prevents the transaction if configured as such. Governance degrades gracefully instead of failing silently.
What this looks like compared to alternatives
The new-protocol approach requires everyone to adopt before anyone truly benefits. The platform-native approach works inside one vendor’s walls. The Governance Envelope approach rides on existing infrastructure, is verified by servers that participate, is invisible to servers that don’t, and creates no vendor dependency.
The credential (OAuth token) carries the authorization. The envelope carries the governance context that informs enforcement decisions. The server reads both. One enforces. The other makes enforcement smarter. Together, authorization with sufficient context becomes governance.
The envelope approach also leaves room for whatever comes after agents and MCP.
Where this goes
The standards already exist. OAuth 2.1 carries authorization. SPIFFE/SPIRE provides cryptographic workload identity. NGAC provides attribute-based policy evaluation. OpenTelemetry provides trace context for cross-system audit correlation. None of them need to be replaced. They need to be composed at the MCP server enforcement boundary, with a Governance Envelope that carries the context they produce.
Just as DKIM didn’t replace email and credit card transactions didn’t require new verbs, governance headers don’t replace REST.
There’s also a question of ownership. HTTP, OAuth, TLS, SPIFFE, and NGAC were all built by communities of practitioners who shared a problem. None of them came with a patent portfolio underneath waiting to capitalize upon adoption. The moment a protocol layer carries IPR encumbrances, it becomes a tollbooth on infrastructure that should stay public. Agent governance infrastructure should be unowned, like the web it runs on, and fortunately IETF tends to have a similar view when considering proposals for working groups.
The agent governance stack should be built the same way the web was built. Small pieces, loosely joined [6]. Not another monolithic protocol that asks the entire internet to change so one vendor’s narrow vision of governance can work.
CREDITS: Claude Sonnet 4.7 for editorial review; Gemini for banner image generation.
References
[1] Dusseault, L. & Snell, J. (2010). “RFC 5789: PATCH Method for HTTP.” Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc5789.html
[2] Anthropic. “Model Context Protocol Specification (2025-11-25).” https://modelcontextprotocol.io/specification/2025-11-25
[3] Crocker, D., Hansen, T., & Kucherawy, M. (2011). “RFC 6376: DomainKeys Identified Mail (DKIM) Signatures.” Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc6376.html
[4] Willis, J. (2026). “AGCP Operating Model and Semantic Architecture: Proposal Schemas, Governance Context, Canonical State, and Commit-Bound Execution Semantics for Autonomous Systems.” Zenodo. https://doi.org/10.5281/zenodo.20330062
[5] Willis, J. (2026). “AGCP: A Deterministic Execution-Layer Governance Control Plane for Autonomous and Programmatic Systems.” Zenodo. https://doi.org/10.5281/zenodo.19323672
[6] Weinberger, D. (2002). Small Pieces Loosely Joined: A Unified Theory of the Web. Perseus Books.
Brian Fending is the founder of Ordovera Advisory, where he works on AI governance architecture for mid-market and mission-driven organizations. ordovera.com