Three approaches, one gap
The Model Context Protocol (MCP) solves interoperability. It was never built to solve governance, and it shows. The uniform client-host-server interface is genuinely useful: it lowers integration cost and gives every call a consistent shape to log. But access under MCP is binary. A compliant server hands over full tool utility, and there is no way to scope a grant down to “read-only, this folder only.” Nothing decides who is allowed to call what. The protocol is stateless about the agent’s reasoning, so what gets logged is the result of a call, not why it happened. Liability doesn’t exist in the spec at all. None of this is a flaw, exactly. MCP isn’t trying to answer these questions.
Runlayer and Rippling are now answering them from opposite ends. Runlayer sits on the wire. Its Agent IAM issues “Agent Accounts,” credentials with policies and lifecycle state attached, and it checks every call against the intersection of user policy, agent-account policy, and server policy before letting it through. That’s a real fix for the missing policy layer. It’s still a gateway, though. It has no idea who the employee behind a request actually is, and no visibility into what the agent does once a call clears.
Rippling comes at it from the other side. It already owns onboarding, role changes, and offboarding for the human workforce, so its bet is that agent capability should just fall out of the same HR record instead of getting reconstructed downstream. Parker Conrad put it plainly when Rippling shipped its own competing gateway: “MCP governance is inseparable from job and role… A 3P gateway only approximates this through SCIM/group sync : Rippling has the data natively.” A new hire gets access on day one, a role change updates agent permissions in the same transaction, offboarding kills everything at once. That’s a real advantage over reconstructing role context after the fact. But the ceiling is the same as Runlayer’s, just reached from the other direction: Rippling can tell you an agent is entitled to something, not whether what it did with that access was safe. Nothing about running code gets contained.
And underneath the disagreement about where policy should live, the two approaches share a limit: neither changes what MCP hands over once a call is approved. The grant is as binary and unscoped as it ever was. A gateway or an HR system decides whether the door opens; what’s on the other side of that door is exactly what MCP always gave you. That’s the tell that the governance conversation is anchored to the wrong layer. The checkpoint gets the attention because it’s the layer MCP happens to expose, not because it’s where the risk sits. Make the gate as smart as you want. It can’t see what an agent does after it walks through, it can’t verify the reasoning behind an action, and it can’t attach liability once something goes wrong. Those were never checkpoint problems. They’re substrate problems, and MCP doesn’t expose the substrate.
Mithran doesn’t play at either checkpoint. It governs the substrate directly. Every build gets an identity, an adversarial review that has to produce evidence rather than accept a self-attestation, a runtime contained at the kernel and compute boundary instead of intercepted at a gateway, and a signed record of what actually happened. Aegis, Mithran’s immune system, screens actions live, guilty until proven safe: approve, quarantine, block, auto-fix. The Corporate Brain, Mithran’s live and permissioned picture of the company’s actual systems and policy, feeds it context instead of a static rule table. None of this stops at the access-request moment. It runs the whole way through context, build, review, deployment, runtime, and sharing. Runlayer’s question is “is this call allowed.” Rippling’s is “is this agent entitled to it.” Mithran also asks whether the action was safe, and whether you can prove it afterward.
What the research says, and how Mithran already works
Google DeepMind’s Intelligent AI Delegation paper argues that delegating a task safely means transferring authority, responsibility, and accountability along with it, and verifying the result, rather than just routing a request from one agent to another. Three pieces of that framework already describe how Mithran runs.
Take contract-first decomposition, the idea that a sub-task has to be small and precise enough to check mechanically before anyone delegates it. That’s what Aegis does at review. Nothing clears on a plausible-sounding claim. It clears on independent evidence or it doesn’t clear.
Privilege attenuation is where the three approaches genuinely split. The paper’s rule is simple: never hand off your full set of permissions, only the narrow slice a sub-task actually needs. Rippling attenuates by role. Runlayer attenuates by policy intersection at the gateway. Both attenuate the grant. Mithran attenuates the execution: containment enforces the boundary at runtime no matter what was nominally handed out upstream, so a permission that’s too broad never turns into an action that’s too broad.
Transitive accountability is where the gap is starkest. The paper wants signed attestations carried up a delegation chain so responsibility doesn’t evaporate somewhere in the middle. Mithran’s lifecycle already works that way internally. Context, build, review, deployment, runtime, and sharing each produce a signed record that points back to the one before it. Runlayer and Rippling can’t do this, not because they built it wrong, but because neither owns a lifecycle to attest across. A gateway approves a call. An HRIS approves a grant. That’s the whole job, and it ends there.
Where Mithran differentiates
Set against MCP’s four gaps, the table below maps one system answering all four, not four separate patches. The honest limit: MCP’s biggest strength, near-zero-friction interoperability across any client and any tool, comes directly from its refusal to be a policy layer. An operating-system approach gives some of that up by design. The bet only pays off if governing the substrate beats governing the checkpoint often enough to justify the tighter coupling.
The cost of getting this wrong
IBM’s Cost of a Data Breach Report 2026 puts a number on the stakes: 92% of organizations that suffered an AI-related breach lacked proper access controls, which the report calls “a systemic failure to treat identity as mission-critical infrastructure.” Its recommended fix spans agent onboarding, authentication delegation, anomaly detection, and lifecycle governance. It also frames “AI sovereignty” as something that has to span API security, identity, and compute together, not any single layer alone. That’s a direct argument for the end-to-end position: a gateway covers the access surface, an HR system covers identity, and sovereignty by IBM’s own definition means governing compute too.
MCP vs. Mithran
| Raw MCP | Mithran | |
|---|---|---|
| Governs | The wire protocol between client and tool server | The full lifecycle: context, build, review, deploy, runtime, sharing |
| Access model | Binary: full tool utility per session | Earned, evidence-based, continuously re-evaluated |
| Granularity | No semantic attenuation | Containment at the kernel/compute boundary |
| Visibility | Stateless on reasoning; logs results, not intent | Signed records capturing process, not just outcome |
| Liability | No native reputation or accountability | Identity + adversarial review + audit trail |
| Main deficiency | Declines to be a policy or safety layer | Not an open interop standard; value depends on adopting Mithran as the substrate |
Sources and section references
- Tomašev, N., Franklin, M., & Osindero, S. (2026). Intelligent AI Delegation. arXiv:2602.11865v1 [cs.AI]. Google DeepMind. (Mithran project file:
2602.11865v1.pdf) MCP critique from §6; contract-first decomposition from §4.1; privilege attenuation and confused-deputy framing from §4.7; transitive accountability and signed attestation from §4.5–4.8; cognitive friction as a supporting concept, not a named pillar, from §2.3 and §5.1; defense-in-depth from §4.9. - IBM. Cost of a Data Breach Report 2026. (Mithran project file:
CostofaDataBreachReport2026.pdf) - Rippling, “Introducing Rippling AI Governance”; Parker Conrad, @parkerconrad, Aug 20 2026
- Runlayer: Agent IAM & Governance, MCP Gateway
- Mithran.ai