How MCP works
The Model Context Protocol is an open protocol, introduced by Anthropic in 2024 and since adopted broadly across the industry, that standardizes how AI applications and agents connect to external tools and data sources. Providers expose their capabilities as MCP servers; an AI application acts as the client. The protocol is JSON-RPC based: a client discovers what a server offers through calls like tools/list, then invokes individual tools with structured arguments and receives structured results. The same mechanism covers data resources and prompts, so one protocol replaces the per-integration glue code that previously connected every model to every system.
What makes MCP consequential is what flows through it. A tool call is not a text completion; it is a real action on a real system — querying a database, creating a ticket, changing a configuration — executed with real credentials. Authorization in the MCP specification builds on OAuth bearer tokens, which handles the transport-level question of whether a client may talk to a server. Everything above that — which servers, which tools, which callers, under what conditions — is left to the organization deploying it.
Why it matters for security
MCP moves AI adoption from reading to acting. As long as a model only answered questions, the worst case was a wrong answer; once agents call tools, the worst case is a wrong action executed at machine speed with legitimate credentials. That changes the questions an enterprise must be able to answer: which MCP servers are approved for use at all, which agent — and which human behind it — is making each call, which tools that caller may invoke, and what happened, in full, afterward.
The identity requirements follow directly. Destructive or high-impact actions need a human approval step rather than autonomous execution. Credential handling needs rethinking, because an agent client that holds upstream secrets itself becomes the breach vector; clients should never hold the credentials of the systems behind the servers they call. And every invocation needs an audit trail tied to an identity, since an agent acting on a user’s behalf blurs exactly the accountability that audit exists to preserve.
Governing MCP in the enterprise
The emerging answer is the MCP gateway pattern: an identity-aware proxy that sits between agents and MCP servers, the same way an access proxy sits between users and applications. The gateway maintains an allow-listed catalog of approved servers, authenticates the calling agent and the user behind it, enforces tool-level authorization so a caller sees only the tools it is entitled to, injects upstream credentials at the proxy so clients never hold them, routes destructive actions through human-in-the-loop approval, and records every discovery and invocation for audit.
Practically, start by inventorying MCP usage before governing it — unmanaged servers tend to appear the way unmanaged SaaS once did. Then move traffic behind a gateway, beginning with the servers that touch production systems or regulated data. Monosign’s MCP Gateway applies allow-listed catalogs, tool-level authorization, human-in-the-loop approvals, and audit to MCP traffic.