MCP Is an Integration Contract, Not a Security Boundary

The Plug Is Standard. The Power Is Not.

An agent that can read your calendar through MCP and an agent that can wire money through MCP use the exact same connection shape. That symmetry is the whole point of the protocol — and it is also the trap. The Model Context Protocol made one thing genuinely easier: connecting an AI agent to your tools and data through a single, predictable contract instead of a bespoke adapter per integration. Reading a calendar, querying a database, filing a ticket — the wiring now looks identical.

That convenience leads to a quiet misread. Because the wiring is standard, teams assume the safety is standard too. It is not. MCP standardizes connection shape. It does not remove the need for permission design.

Think of MCP as a power outlet contract. It guarantees the plug fits. It does not decide which appliances you allow in the room, who can switch them on, or what happens if one draws too much current. Those decisions stay with you.

What MCP Actually Standardizes

MCP defines a clean separation between three roles. The host is the application the user interacts with. The client lives inside the host and speaks the protocol. The server exposes capabilities to the client. Those capabilities fall into a small set of primitives: resources (data the agent can read), prompts (reusable instruction templates), and tools (actions the agent can invoke, including ones that write or execute).

The value is real. A stable contract means you can swap a database server for a CRM server without rewriting the agent. It means a tool's input schema is discoverable rather than guessed. It means the ecosystem can grow without every vendor inventing a new handshake.

Notice where the decision diamond sits. Everything above it — host, client, server, primitives — is what MCP gives you. The gate below it, the one that asks whether a call is sensitive or mutating and routes it to consent or approval, is yours to build. Consent and approval are part of the design intent, but they are not behavior the protocol enforces for you by default. The diagram shows where the standard ends and the work begins.

What MCP Does Not Decide

The specification itself is direct about this. The MCP spec explicitly warns that tool access and arbitrary code execution carry real risk and require security and trust controls layered on top. It frames consent, data privacy, and tool safety as responsibilities of the implementer, not guarantees of the wire format. Read that as a design principle, not a feature you can switch on.

So the standard answers "how do these two systems talk to each other?" It leaves these questions open, and they are the ones that actually determine your exposure:

Open design question	Who owns it
Which data can this server expose?	You, via corpus and scope decisions
Which tools are read-only vs. write/execute?	You, via tool design
Where do credentials live and how are they rotated?	You, via secret management
Does a write action need human approval?	You, via the host's approval gate
What gets logged for every call?	You, via audit configuration
How do you revoke access quickly?	You, via a revoke path you build first

MCP gives you the connector. It does not give you least privilege, transport hardening, credential hygiene, scoped tool permissions, audit trails, or a human-in-the-loop checkpoint. Those remain engineering and governance work.

The Interoperability Wave Raises the Stakes

This matters more now because connection standards are multiplying and converging. Google launched the Agent2Agent (A2A) protocol on 2025-04-09 with more than 50 technology partners, positioning it as a complement to MCP: where MCP standardizes how an agent connects to tools and context, A2A standardizes how agents talk to each other. Two interoperability layers, both designed to make connection trivial.

Source: Google Developers Blog, checked 2026-06-14.

That momentum is good for builders and bad for anyone who confuses easy connection with safe connection. The easier it becomes to wire an agent into a fleet of tools and peer agents, the more a single missing permission check propagates. You can read the launch framing in Google's A2A announcement, and the implementer-responsibility language in the Model Context Protocol specification.

The security community has already named the failure modes. The OWASP LLM Top 10 for 2025 lists excessive agency and supply-chain risk among the top risks for LLM applications. Excessive agency is exactly what happens when an agent gets a write tool it never needed. Supply-chain risk is exactly what happens when you install a third-party MCP server without reviewing what it exposes. The standard makes both easier to stumble into.

A Reusable MCP Server Review Checklist

Before you connect any MCP server, especially one you did not write, run it through a fixed review. Treat an unreviewed server like an unreviewed dependency, because that is what it is.

Review item	What to confirm	Pass condition
Data exposed	Which resources can be read	Only the data this workflow needs
Tools exposed	Full list of callable tools	No tool you cannot explain
Write actions	Which tools mutate or execute	Each one justified and listed
Credential source	Where the server gets its secrets	Scoped token, not a personal admin key
Logs	What is recorded per call	Caller, tool, inputs, outcome captured
Revoke path	How to cut access fast	A tested, documented kill switch
Owner	Who is accountable	A named human, not "the team"

If any row fails, the server does not get connected to anything that matters until it passes. This list is short on purpose so it gets used.

Default to least privilege

The single highest-leverage habit is starting from zero. A new MCP server connection should expose the smallest set of read-only resources that the task needs, with write and execute tools added one at a time, each with its own justification. It is far easier to grant a missing capability later than to discover an over-broad one after an incident.

The same logic applies to credentials. A server should authenticate with a narrowly scoped token tied to the specific account and permissions the workflow requires, never a shared administrator credential that happens to be convenient. Pin the scope, then pin the rotation schedule.

Consider a hypothetical: Castlewood Insurance, a claims-software company, wants its support agent to draft claim-status replies. The fast path is to point a community MCP server at the production database with the ops team's standing credentials. Instead, the engineer who owns the integration starts from zero — a read-only resource scoped to the claims and tickets views, a single draft_reply tool that writes nothing, and a token tied to a dedicated service account with no delete rights. Two weeks later, when product asks the agent to also log a follow-up on a claim, that one write tool gets added with its own approval gate and its own log line. Nothing else had to be unwound, because nothing else was ever granted.

Where Human Approval Belongs

Not every action deserves the same friction. Reading a public document and deleting a customer record are not the same risk, and a good design does not treat them the same. The cleanest way to decide is a tiering table you write once and reuse.

Action tier	Examples	Control
Read, low-sensitivity	Public docs, internal wiki search	Logged, no prompt
Read, sensitive	Customer PII, financial records	Consent gate plus log
Write, reversible	Draft email, create ticket	Show diff, one-click confirm
Write, irreversible	Send payment, delete data, deploy	Explicit human approval, every time

The protocol can carry an approval signal, but it cannot decide your tiers for you. That mapping is a product and governance decision. Get it wrong in the permissive direction and you have handed an agent excessive agency; get it wrong in the restrictive direction and nobody uses the tool. Designing those gates well is the heart of agentic work, and it is what the AI Agentic Patterns course drills with concrete tool-permission exercises rather than slideware.

Transport, Credentials, and Audit Are Still Yours

Three areas reliably get skipped because MCP makes them feel handled. They are not.

Transport choice. A server reachable over the network is a different risk surface than one running locally over a standard input and output stream on the same machine. Remote servers need authenticated, encrypted transport and a clear answer to "who can reach this endpoint." The protocol supports transport options; choosing and hardening one is your call.

Credential handling. Agents are persuasive, and so is text they read from untrusted resources. Credentials should never sit in prompts, tool descriptions, or logs where a prompt-injection attempt could surface them. Store them in a secret manager, inject them at the server boundary, and keep them out of the model's context entirely.

Audit logs. If you cannot answer "which agent called which tool, with what inputs, on whose behalf, and what happened" after the fact, you cannot investigate an incident or prove compliance. Logging is not free and not automatic. Build it into the server boundary from day one. Governance teams looking for the full control stack here will find it in AI Governance, Risk & Secure Operations.

A Short Adoption Sequence

When a team is ready to bring MCP into real workflows, the order matters more than the speed. A workable sequence: inventory the tools and data you actually want the agent to touch, draft the permission tiers above, build or review each server against the checklist, wire credentials through a secret manager, turn on logging, then enable the agent with the narrowest scope and widen only on evidence. Architecture reviewers can pressure-test exactly this kind of boundary design in Claude Certified Architect Foundations.

The sequence is deliberately unglamorous. None of it is about the protocol. All of it is the work the protocol leaves to you.

The Standard Is a Floor, Not a Ceiling

MCP is a genuine improvement. A common integration contract lowers the cost of connecting agents to the systems where work actually happens, and the surrounding interoperability wave, including A2A's 50-plus-partner launch, signals that this shape is here to stay. Standardized connection is worth adopting.

The mistake is treating a connection standard as a safety standard. The plug fits; the power is still yours to govern. Permission design, transport choice, credential handling, tool scope, audit logs, and human approval do not come in the box, and the specification itself says as much.

MCP will keep making the plug easier to fit; the part it will never do for you is decide which appliances belong in the room. Practice writing that judgment into real agent integrations — scoping servers, setting tiers, building the revoke path — in AI Agentic Patterns, then harden the credentials, transport, and audit story around them in AI Governance, Risk & Secure Operations. The connection is the floor. The trust you design on top of it is the job.

Originally published April 2, 2026. Updated and re-verified June 14, 2026.