MCP Is the Protocol. You Still Need an Auth Layer.
The Model Context Protocol (MCP) is one of the most important things to happen to AI agents. By standardizing how agents discover and interact with tools, MCP solved a real problem: every tool provider had their own API format, their own discovery mechanism, their own way of doing things. MCP gave us a common language.
But here's what MCP doesn't do: it doesn't decide who gets to speak that language.
What MCP Does Well
Let's give credit where it's due. MCP is elegant. It defines a clean protocol for:
- Tool discovery: Agents can find what tools are available and what they do
- Schema definition: Tools describe their inputs and outputs in a standard format
- Invocation: A consistent way to call tools across different providers
- Context passing: Tools get the context they need to do their job
If you're building an AI agent that needs to interact with multiple services, MCP is a godsend. Instead of writing custom integration code for every tool, you implement MCP once and get access to a growing ecosystem.
Think of MCP like TCP/IP. It defines how the packets move. It's the plumbing. And good plumbing matters enormously.
What MCP Doesn't Do
TCP/IP moves packets, but it doesn't decide who's allowed to send them. That's what TLS certificates, authentication, and authorization layers are for. MCP has the same gap.
MCP tells your agent how to call a Google Calendar tool. It doesn't answer:
- Should this agent have access to Google Calendar at all?
- Which user's calendar should it access?
- Can it read events or also create them?
- Who approved this access and when does it expire?
- What happens when the user wants to revoke access?
These are authorization questions, and MCP intentionally leaves them to the implementation. That's the right design choice for a protocol — you don't want auth baked into the transport layer. But it means every MCP tool provider is solving auth independently, and most of them are solving it badly.
How Auth Works in MCP Today
In practice, here's what MCP tool authentication looks like in 2026:
API keys in environment variables. The most common approach. You set GOOGLE_API_KEY or SLACK_TOKEN in your MCP server config, and every tool invocation uses those credentials. Simple. Also: no per-user scoping, no time limits, no audit trail, no user consent. All the problems we've covered before.
OAuth flows bolted on. Some tool providers implement their own OAuth flow, which means each tool has its own consent screen, its own token storage, its own refresh logic. If your agent uses ten tools, you're managing ten separate OAuth integrations. That's not a criticism of those providers — it's a structural problem.
No auth at all. Some MCP tools just... don't have auth. They assume if you can reach the server, you're authorized. This works for local development. It's terrifying in production.
MCP Is TCP/IP. TapAuth Is the Certificate Authority.
We're not anti-MCP. We love MCP. We build on MCP. But MCP needs an auth layer the same way the internet needed SSL/TLS.
Here's how we think about the relationship:
MCP standardizes how agents talk to tools. It's the protocol. It defines the envelope, the addressing, the delivery mechanism.
TapAuth standardizes how agents get permission to talk to tools. It's the auth layer. It handles user consent, scope selection, token issuance, time-limited grants, and revocation.
Together, they're complementary pieces of the same puzzle. MCP makes agent-tool communication universal. TapAuth makes agent-tool authorization user-controlled.
What This Looks Like in Practice
Here's a concrete example. You have an MCP server that exposes Google Calendar, Gmail, and Google Drive tools. Your AI agent wants to check the user's calendar for availability.
Without TapAuth: The MCP server has a Google API key or service account credential configured. Every agent that connects gets full access to every Google service. The user whose data is being accessed never approved anything. The access never expires.
With TapAuth: The agent calls TapAuth's API requesting Google Calendar read access for a specific user. TapAuth sends the user an approval link. The user sees exactly what's being requested, selects the scope (read-only calendar, 1 hour), and approves. The agent gets a scoped, time-limited OAuth token. The MCP server uses that token for the tool invocation. When the grant expires, the agent needs to request access again.
The MCP interaction is identical in both cases — same protocol, same tool schema, same invocation format. The difference is entirely in how the auth token was obtained and what it's allowed to do.
The Ecosystem Needs This
As MCP adoption grows (and it's growing fast), the auth problem is going to get worse, not better. More tools means more credentials. More credentials means more attack surface. More attack surface means more incidents.
We've already seen what happens when agent credentials aren't managed properly — 280 leaked API keys on ClawHub, Okta building an entire product to find shadow agents, headlines every week about unauthorized AI access.
MCP made the plumbing standard. Now we need to make the security standard too.
Not a Gatekeeping Play
I want to be clear about what TapAuth is not. We're not trying to be a toll booth between agents and tools. We're not adding friction for its own sake. We're not anti-agent or anti-automation.
We're pro-trust. We believe agents work better when users trust them. Users trust agents more when they have visibility and control. TapAuth provides visibility and control.
MCP made it possible for agents to talk to any tool. TapAuth makes it safe for users to let them.