Agent class · Protocol chokepoint

Govern the protocol, not every agent.

Govern the pipes once. Govern every client.

This is the killer architecture. Put a governing gateway at the MCP or A2A boundary and every agent behind it inherits a ledger and ownership gates — no per-framework adapter, no SDK dependency. Govern the pipes once; govern every client. (The GOVENANT Audit itself ships as an MCP server.)

Agent-agnostic by design

GOVENANT does not govern “Claude agents” or “OpenAI agents.” It governs the evidence trail of autonomous work. Keep the runner (the tool you audit from) separate from the system under audit (your agents):

What runs the audit

ClaudeChatGPTClaude CodeCursorCodexVS CodeWindsurfCline

An AI client you already use reads the open instrument and drives the read-only sweep. This is the runner — not the thing being judged.

What gets audited — incl. MCP & agent protocols

Model Context Protocol (MCP)Agent2Agent (A2A)any MCP-speaking clienta governing MCP gateway (GOVCP)

Any agent system with an observable record of actions and outcomes — whatever built it. The agent never has to "support GOVENANT."

Ground truth: the database + actions + outcomes + duties + gates — the substrate, never the logs’ self-report.

Why govern MCP & agent protocols

Framework-independent leverage

Every agent that speaks the protocol inherits governance from the boundary — no per-framework adapter, no SDK dependency, no redeployment of the agents themselves.

The chokepoint is already there

Protocol boundaries are where tool calls and tasks already flow. A governing gateway makes that boundary an ownership gate and an append-only ledger — the two hardest substrate requirements, solved at the layer designed for interception.

Interop with receipts

Cross-vendor agent ecosystems only work if the work is provable across trust boundaries. A ledgered protocol boundary is how two organizations’ agents cooperate and both sides keep a record they trust.

Where this bites — a real scenario

A platform team standardizes 60 internal agents across five frameworks on MCP so any agent can reach any tool.

The challenge

Governance would mean 60 bespoke integrations — one per agent — and it still wouldn’t cover the next team’s agents. Tool calls flow through the protocol, but nothing ledgers them or checks ownership at the boundary.

What the record reveals

A governing MCP gateway ledgers every tool call and enforces ownership gates for every client at once. One integration, whole ecosystem: the record shows which agents call which tools, what verifiably resulted, and where an unowned call was stopped at the gate — framework-independent.

How it works

The substrate: The protocol boundary: every tool call and task already flows through it — the natural place for an append-only ledger and an ownership gate.

The path — Protocol chokepoint: Govern the pipe once (MCP/A2A gateway) and every agent behind it inherits a ledger and ownership gates — regardless of framework.

  1. Deploy the governing gateway in front of your protocol servers — clients connect to the gateway instead.
  2. Register exposed tools and tasks as levers with named owners; the gateway enforces the gate.
  3. The gateway writes the ledger: every call, task, and artifact with input, output, and outcome.
  4. Key duties to protocol-level outcomes (task completed with verified artifact, not just responded).
  5. Sweep the gateway’s substrate with the free Audit — every connected client is now in scope.

The full requirements live in the open standard (CC BY 4.0) — the substrate shapes, the acceptance tests, and the conformance ladder your record is measured against.

What you can claim

A governed protocol boundary lets every system behind it claim a real, inspectable ledger — and the gateway operator can publish its own conformance record to the registry with probe logs. As always: self-assessed, open to challenge, never “certified.”

Stacks that build MCP & agent protocols

Per-stack integration patterns for common ways to build MCP & agent protocols — each with its own natural hook into the substrate:

Building it a different way? Browse all integrations — or run the free audit from any MCP-capable tool.

Governing MCP & agent protocols — FAQ

Does a governing gateway add latency to every call?
A gate check and an async ledger write — the same class of overhead as authentication and logging, which every production gateway already pays. The outcome verification runs out-of-band against the record, not in the request path.
Is this a fork or extension of the protocol?
Neither. The gateway speaks the protocol unmodified in both directions; governance lives in the boundary’s own substrate. Clients and servers need zero changes.
Do my agents have to “support” GOVENANT?
No. GOVENANT governs the substrate — the record of what agents did and whether it verifiably delivered — not the agent. If the system of record around your agents can be read, or you can instrument the action boundary, they can be measured, whatever framework, model, or vendor built them.
What is “performed autonomy”?
Agents that look busy — fluent plans, satisfied logs — but don’t verifiably ship. Motion is not delivery. GOVENANT measures verified outcomes against the record, never the logs’ self-report.
What is GOVENANT, and who controls it?
An open standard for provable AI agent governance: three laws, a conformance ladder, and acceptance tests any implementation runs against its own record. Free to all under CC BY 4.0, with a citable companion paper (DOI 10.5281/zenodo.21440225), conformance self-assessed and published openly — no certifying authority.

More agent classes

All agent types · All integrations · Run the audit