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.