MCP, OAuth, and the Agent Permissioning Problem

MCP — the Model Context Protocol — has rapidly become the standard for connecting AI agents to external tools. OAuth has been the standard for delegated access to APIs for over a decade. Together, they cover the wire protocol and the authorization handshake. Neither covers the harder problem in production: deciding, on every action, whether this particular agent should be allowed to do this particular thing on behalf of this particular user.

That is the agent permissioning problem. It is the gap teams hit when they move from a demo to a deployment.

What MCP solves

MCP is the contract that lets any agent talk to any tool. It defines how tools advertise their capabilities, how agents discover them, how requests and responses are structured, and how authentication metadata is exchanged. It standardizes the protocol so a Claude agent and a custom agent can both call the same MCP server without bespoke glue.

This is genuinely important. Before MCP, every agent framework had its own tool integration story. After MCP, the wire format is consistent. But MCP is, by design, a protocol — not a policy engine.

What MCP leaves open

MCP standardizes how an agent and a tool talk, but it does not opine on:

• Which user is this agent acting on behalf of, and how do we know?
• Has this user authorized this specific action — not just the app, the action?
• What organizational policy applies, and who enforces it?
• When the user offboards, how do all live agent sessions get revoked?
• Where is the immutable record of what this agent did?

These are permissioning questions. MCP servers can implement them individually — but each server doing its own thing produces fragmented policy, inconsistent audit, and no unified revocation. That is exactly the failure mode enterprises hit at scale.

Why raw OAuth falls short

OAuth is the natural starting point for authorization, and most MCP servers bolt OAuth on. But OAuth was designed for human users delegating access to apps, not for autonomous agents taking many distinct actions inside one app. Three specific gaps:

Scope granularity. OAuth scopes are app-level. "Send Slack message" is one scope. But for an agent, "send Slack message to a channel I'm already in" and "send Slack message to a channel I've never seen" are very different actions and deserve different policy.

Identity model. Standard OAuth flows produce a token tied to a user or to an app. They do not produce a token tied to a specific agent acting on behalf of a user. Without per-agent identity, audit trails collapse and revocation is all-or-nothing.

Revocation latency. OAuth tokens have TTLs measured in minutes to hours. Refresh tokens last longer. A leaked agent token can be active long after the user revoked access — unless the broker checks current policy on every call.

The permissioning pattern

The pattern that works is to insert a permissioning layer between the agent and the MCP servers (or any tool). The layer:

• Authenticates the agent and resolves the user it is acting on behalf of.
• Resolves the user's permissions from the upstream IdP (Okta, Azure AD, etc.).
• Evaluates the requested action against organizational policy and the user's scope.
• Mints a short-lived, narrowly-scoped token for the downstream system.
• Forwards the call, captures the response, and writes an immutable audit record.
• Re-checks current policy on every call, so revocation propagates in milliseconds.

MCP authentication tools

Teams building this layer today choose between rolling their own and using a purpose-built platform. Agentic Fabriq provides the broker, policy engine, and audit pipeline as a drop-in service that integrates with Okta, Azure AD, and Google Workspace. Other options include lower-level libraries that handle individual primitives (token storage, OAuth flows, MCP auth handshakes) but leave the policy and audit layers to the team.

Takeaway

MCP solves the protocol. OAuth solves the handshake. Permissioning is what decides whether a given action should happen, attributes it to a user, and leaves a record. Teams that treat permissioning as a first-class layer ship agents to production. Teams that treat it as an afterthought ship demos.