Governing The Ai Agent Stack

1.45MB ∙ PDF file

Download

Download

Garry Tan got frustrated. He vibe-coded a Playwright CLI wrapper in 30 minutes, 100 lines, worked 100x better than the MCP version. Perplexity shipped their flagship agent product without MCP entirely. Someone analyzed 1,400 public MCP servers and found most were thin wrappers around CLI tools that agents could already call directly.

The LinkedIn post making the rounds this week documents all of this and concludes: MCP isn’t dying, but the idea of wrapping every API in its own server and calling it an integration strategy is dead.

They’re right about the symptoms. They’re diagnosing the wrong disease.

What MCP Actually Broke

The post cites the numbers correctly. A typical MCP server dumps 13,000 to 18,000 tokens of tool metadata into context. The equivalent CLI approach does the same job in 225 tokens. That’s 80x overhead. Seventy-eight percent of MCP implementations have no proper authorization. Every server reinvented auth from scratch. Every deployment became a silo.

But here’s what the post doesn’t ask: why did this happen?

It happened because MCP was designed to answer one question — “how does an AI agent call a tool?” — and the ecosystem tried to use it to answer a completely different question: “how should data move between parties who don’t fully trust each other, under legal obligations, with consent that can be withdrawn, leaving a proof trail that satisfies a regulator?”

MCP cannot answer that second question. It was never designed to. The 78% auth failure rate isn’t a bug in MCP implementations — it’s the ecosystem discovering that auth cannot be bolted onto a protocol that has no identity model, no bilateral trust, no policy language, and no concept of provenance.

Garry Tan’s Playwright CLI worked great because he was one developer calling his own tool. No second party. No consent record. No legal basis to declare. No regulator to satisfy. The moment a second party enters — a customer whose data you’re processing, a processor you’re sharing data with, a supervisory authority with enforcement powers — the 100-line wrapper stops being sufficient not because it’s bad engineering, but because the problem changed.

The Question MCP Was Never Asked

Here is the question no current AI protocol can answer:

“Is this specific data exchange, between these specific parties, for this specific purpose, under this specific legal basis, with these specific safeguards, permitted — and can we prove it?”

Not “can the agent call the tool.” Not “does the API accept the request.” Whether the exchange is governed — authorized by a declared policy, bound to a data processing specification, executed by credentialed wallets, recorded in a hash-chained provenance trail that neither party can unilaterally modify.

This is the question GDPR asks about every personal data flow. It is also, increasingly, the question the EU AI Act asks about every high-risk AI decision. And it is structurally unanswerable by a tool-calling protocol.

What’s needed is a different kind of protocol. One designed from the ground up to answer the governance question first, and let tool invocation happen downstream.

GDXP: The Protocol Built for the Governance Layer

The Governed Data Exchange Protocol (GDXP) is a new application-layer protocol for bilateral, credential-authenticated, policy-enforced, and provenance-tracked exchange of personal data between wallets.

The five-layer architecture makes the design philosophy explicit:

Layer 5: APPLICATION  — semantics (purposes, legal bases, data categories)
Layer 4: GOVERNANCE   — 9-step gateway evaluation (PERMIT / DENY / ESCALATE)
Layer 3: TRUST        — Verifiable Credentials + DID resolution
Layer 2: PROVENANCE   — Hash-chained, bilaterally signed audit records
Layer 1: TRANSPORT    — HTTPS + JWE (pluggable)

Notice what’s missing from this stack: tool schemas. GDXP doesn’t care what tools exist or how to call them. It cares whether a data exchange is permitted and whether that permission is provable.

Every exchange in GDXP passes through a governance gateway that evaluates nine questions before any data flows: Is the credential valid? Does the specification exist and match? Is the operation declared? Does the requesting party’s agent state-type ceiling permit this action? Does the data compartment allow this transfer? Is the consent current? Is the delegation scope valid? Are there active restrictions or erasure orders? Is the transfer mechanism adequate for cross-border flows?

This is not an auth check bolted onto a transport protocol. This is authorization as a structural property of the exchange itself. You cannot construct a valid GDXP exchange that violates the governance rules — the same way you cannot construct a valid chess position where a pawn captures diagonally forward. The rules are in the type system, not in a middleware layer that might be skipped.

How GDXP and MCP Fit Together

Here is the mistake the current debate is making: treating MCP and GDXP as competitors. They are not. They answer different questions at different points in the same flow.

GDXP asks: Is this data exchange permitted, under what conditions, and can we prove it?

MCP asks: How does an agent invoke a tool?

These are sequential. GDXP runs first. MCP runs after.

AGENT
  │
  ▼
GDXP GATEWAY ── evaluates: state-type, relationship-type, consent, compartment, data processing spec
  │
  │  issues: ToolInvocationGrant (scoped, short-lived, gateway-signed)
  ▼
MCP TOOL SERVER ── checks: does this request carry a valid GDXP grant?
  │
  │  executes within authorized scope only
  ▼
PROVENANCE RECORD ── both sides sign, hash-chained

The interface between the two protocols is minimal. GDXP adds one message type: gdxp:ToolInvocationGrant — a scoped credential issued after gateway evaluation, carrying which operation is permitted, which data categories may be accessed, the requesting agent’s agent state-type, and an expiry. MCP adds one header: X-GDXP-Grant — the tool server verifies this before executing. No grant, no execution. The grant is the auth.

The MCP server stops needing to reinvent authorization because GDXP already ran. The 78% auth-failure problem disappears because the question “is this allowed?” has a structural answer before the tool call is made.

And the token bloat problem? It gets solved too. The agent doesn’t browse tool schemas. It declares an intent against a data processing specification. The gateway evaluates the intent and returns a scoped grant. The agent’s context load drops to one specification reference and one gateway decision. The tool server already knows what tools it has — it doesn’t need to re-advertise them into the agent’s context window on every call.

Why This Matters Now

The EU AI Act’s high-risk AI provisions come into full effect in 2026. They require that high-risk AI systems maintain logs sufficient for post-hoc audit, that human oversight is possible at defined intervention points, and that the system can demonstrate that its outputs are traceable to the inputs and rules that produced them.

GDXP’s agent state-type system maps directly onto these requirements. A T1 agent has full discretion — it needs provenance logging because its decisions are autonomous. A T2 agent has bounded power — the gateway enforces the ceiling, the grant encodes the scope. A T6 agent must be passive — read-only, cannot modify. When a bounded agent calls an MCP tool via a GDXP grant, the grant encodes the agent state-type, the tool server enforces it, the provenance chain proves it, and the regulator can audit it.

The timing is not coincidental. GDXP version 0.1.0 is dated March 14, 2026. The infrastructure is arriving. The regulatory requirements are arriving. The protocol that connects them is arriving.

The Actual Diagnosis

The LinkedIn post ends with the right observation: “A standard way for AI to communicate with tools is genuinely useful. Maybe even necessary. But what the ecosystem built on top of it wasn’t a standard.”

The ecosystem built tool-calling infrastructure and tried to use it as a governance framework. That’s the error. The fix is not to abandon the concept of a standard — it’s to build the right standard at the right layer.

MCP at the tool layer. GDXP at the governance layer. The GDXP grant as the bridge between them.

What is Happening?

When Georg clicks “Withdraw Consent,” he isn’t sending a request — he is triggering a deterministic state change across the entire enterprise stack.

The Chain Reaction. A single action in the Personal Wallet triggers a cascade of seven automated effects. This includes edge-level data blocking, CRM record updates, the immediate purging of scheduled email queues, the locking of analytics profiling, team notification, and the sealing of a cryptographic audit trail. No human intervention is required at any step.

Liability Burn-down. As each system syncs, the Risk Score drops from 100% to 0%. This visualizes the transition from “Legal Liability” (where a GDPR violation could occur at any moment) to “Verified Compliance” — and the telemetry panel shows the exact KROG rule that drove each reduction.

The Witness Chain. Every step is logged in a cryptographic Witness Chain signed with EdDSA and SHA-256, providing a sealed audit trail that proves to regulators exactly when and how consent was revoked — and that the user, not the platform, owns the proof.

Why Can It Happen Like This?

This instantaneous enforcement is powered by the unique architecture of the KROG Engine and its universal rule set.

KROG Universal Rules. Unlike traditional “legalese” that requires human interpretation, KROG rules are machine-executable logic built on a formal system of agent states, bilateral relationships, and modal operators. Because the code is the policy, the system doesn’t need to “decide” to stop an email. The engine identifies the Prohibition operator, and the action is logically blocked. The telemetry panel in the demo shows these operators firing in real time.

State Transitions. When consent is withdrawn, Georg’s relationship with TrustFlow changes. Before withdrawal, TrustFlow held a Permission. After withdrawal, this becomes a Prohibition. In KROG terms, TrustFlow’s state transitions from can act on consent to forbidden to act. This is not an interpretation; it is a deterministic state change that propagates through every relationship type in the stack.

Edge Enforcement (The Gateway). In legacy systems, a withdrawal must travel through multiple databases, which can take days. The KROG Gateway acts as a Policy Enforcement Point at the perimeter. The moment consent is withdrawn, it compiles a PolicyCard — a relationship type is encoded, meaning the Gateway must block and the API must be passive. This logical barrier stops data flow before internal systems even finish syncing.

Temporal Logic Guarantees. KROG extends its modal operators with Temporal Logic. The email queue purge, for example, is governed by the invariant “Always: if consent is withdrawn, then immediately no emails may be sent.” This isn’t a best-effort rule; it is a formally verifiable temporal constraint. The analytics purge uses a liveness pattern so that the data will be purged within 30 days.

European Digital Identity (EUDI) Standards. Built on the 2026 EUDI/EUBW framework, KROG ensures that the Withdrawal signal is cryptographically signed and universally understood by any compliant enterprise stack, removing the need for proprietary, brittle integrations. The Witness Chain is user-sovereign — Georg owns his audit trail, not the platform.

The Business Value

This transforms compliance from a manual cost center into automated infrastructure:

• Zero manual intervention. Seven systems updated in under 28 seconds without a single support ticket.

• Zero “middleman tax.” No legal discovery, no compliance team scramble, no vendor API fees for consent management.

• Bank-grade audit trail. Generated automatically as the business operates — not reconstructed after the fact.

• Regulatory proof on demand. The Witness Chain provides cryptographic evidence of exactly which KROG operators fired, which Relationship type transitions occurred, and which temporal constraints were satisfied. This is the standard of proof that regulators are moving toward.

Mote to come in KROG Wallets.

KROG Engine Protocol — krogrules.com — February 2026

Share Georg Philip Krog

Leave a comment