Ep 522 Blog 6:06 w/ Justy & Cody

MCP gets its missing enterprise authorization layer

MCP (Model Context Protocol) has been missing a proper authorization layer for enterprise deployments—the protocol itself handles tool definitions and interoperability, but doesn't specify who can call what tools or enforce access controls at the protocol level. A new enterprise authorization layer fills that gap by adding fine-grained permission boundaries, letting teams enforce 'agent A can call tool X with parameter Y, but not Z' without rebuilding the entire agent harness. The insight is that authorization is a runtime problem in cloud-native systems, not a model problem—and MCP needed to solve it at the protocol boundary, not in application code.

AgentsDev ToolsLaunchMCPBlog
Embed this episode

Paste this on any site — the player is a self-contained iframe with no cookies or trackers.

<iframe src="https://sandrise.io/exploring-next/embed/522"
  width="100%" height="180" style="max-width:640px;border:0;border-radius:12px;overflow:hidden"
  title="Exploring Next — Episode 522 audio player"
  loading="lazy" allow="autoplay" referrerpolicy="strict-origin-when-cross-origin"></iframe>
Embed & API docs →
Script Haiku 4 Voice ElevenLabs v3

Transcript

Justy So MCP just got an authorization layer, and I didn't realize until I read this that it was missing one in the first place.

Cody Right. The protocol solved tool fragmentation—same tool definition, multiple servers, no schema drift—but it punted on the 'who can call what' problem.

Justy Which means every team using MCP was rebuilding access control in their harness. That's the gap.

Cody Exactly. Authorization is a runtime problem in cloud-native systems. You don't solve it once and ship it; you solve it at the boundary where the request actually hits the resource. Pushing it down to the protocol layer instead of leaving it to the application is the right move.

Justy How does it actually work?

Cody The new layer lets you define fine-grained rules at the protocol level. Agent A can call tool X with parameters Y and Z, but not W. Agent B gets a read-only version of the same tool. The permission check happens before the tool runs—the protocol enforces it, not the harness.

Justy So you're not hoping your application code remembered to validate—the protocol itself says no.

Cody Right. And it separates policy from execution. The person who writes the agent harness doesn't have to be the person who decides permissions. Operations owns the boundary, engineering owns the orchestration.

Justy That's the real product win. When I'm a PM selling agent work to an enterprise customer, I can now say 'you control exactly what the agent can touch, audit every call, revoke access instantly—at the protocol level.'

Cody Yeah. And it becomes a compliance primitive. You're not arguing about whether your harness is audit-safe; the protocol enforces the audit trail.

Justy I've been on the other side of that conversation. Customer says 'I want to run an agent on my codebase, but I need to know what it touched.' And you're stuck saying 'we'll log it,' which isn't the same as 'we prevented it.'

Cody Mm-hm. This solves that. The protocol says 'this agent can read files in /src, but not /secrets.' The agent can't violate it because the boundary is enforced before the tool executes.

Justy So the missing piece wasn't the protocol itself—it was authorization as a first-class primitive. MCP was 'here's a way to talk to tools safely.' Now it's 'here's a way to talk to tools safely AND enforce who gets to talk.'

Cody And it came at the right time. Teams are spinning up multiple agents now—different models, different reasoning paths, working on the same codebase. You need to delegate work without losing control.

Justy Right. One agent can commit, one can read, one can suggest—and the protocol enforces the difference.

Cody Exactly. It's not a feature; it's a boundary.

Justy This is going to be one of those things where, in a year, we'll look back and wonder how we shipped agents without it.

Cody Yeah. 'Remember when agents could call any tool and we just hoped the harness was careful?' Not a great look.

Justy Okay, so the authorization layer is now in MCP—is it already available, or is this still in proposal phase?

Cody The article doesn't specify, but given the framing—'MCP gets its missing enterprise authorization layer'—it sounds like it's already shipped or very close. The way these things usually roll out is the spec lands, then implementations follow.

Justy So if you're using MCP right now, you're probably going to see this in your SDK updates soon.

Cody Yeah. And if you've been hand-rolling authorization in your harness, this is your signal to rip it out and let the protocol handle it.

Justy That's the move. One less thing to get wrong.

Cody Yep.

Justy This feels like MCP finally becoming enterprise-ready. Not just 'tools can talk,' but 'tools can talk and you control who gets to ask.'

Cody That's the whole thing. Protocol maturity isn't about features; it's about boundaries.

Justy Alright. Thanks for walking me through that, Cody.

Cody Yeah. Good catch on the article—this one actually matters.