Most teams deploying “agents” are repeating the same mistake the industry made with browser extensions: shipping arbitrary third-party code paths into privileged user contexts, then acting surprised when things go sideways.
The new wrapper for that mistake is Model Context Protocol (MCP). It’s real, it’s spreading fast, and it’s already the default integration surface for tool-using LLM apps. Anthropic introduced MCP as an open protocol to connect models to tools and data sources. OpenAI added support for MCP servers in the Agents SDK. Microsoft pushed MCP into the Windows/VS Code orbit via developer tooling and partner integrations. If you’re a founder or platform owner, the relevant fact isn’t which model you use. It’s that MCP is becoming the “NPM for agent capabilities.”
And that means your next reliability and security workstream isn’t prompt tuning. It’s an MCP control plane.
MCP is a software supply chain, not an integration detail
Classic integrations are point-to-point: you sign up for an API, you wire it into one service, you observe its behavior. MCP flips the direction. Now you run (or adopt) a server that advertises a menu of tools, and an LLM client can call those tools as part of agent execution. The model becomes a dynamic router across capabilities. That’s the part people like.
The part operators should worry about: tools become code and policy bundled together, distributed with minimal friction, invoked under ambiguous identity, and executed in workflows where “what happened” is hard to reconstruct after the fact.
We already know this movie: browser extensions, Slack apps, OAuth scopes, CI plugins, Terraform providers, npm dependencies. MCP is the same category, with one twist: the caller is non-deterministic and can be induced by untrusted input (prompt injection) to do the wrong thing. That makes “tool permissioning” a first-class problem.
Prompt injection isn’t a model bug. It’s an authorization bug you haven’t designed for yet.
Most early MCP setups treat a tool list like a convenience feature. Operators should treat it like a registry of executable business actions.
The contrarian take: “open tool ecosystems” will hurt most teams
Open protocols are good. Open tool ecosystems are messy. If you let your product—or even your internal agents—pull in MCP servers the way developers pull in npm packages, you’re choosing velocity over control. That trade can be correct for prototypes. It’s reckless for production workflows touching money, customer data, or core infrastructure.
Founders often say they’ll “add governance later.” That’s how you end up with a tool sprawl you can’t audit, and a blame chain that ends with “the model did it.” Regulators, customers, and your own finance team won’t accept that.
Where it breaks first
- Identity: Which user (or service) did the tool action run as? Human impersonation via delegated tokens becomes the default failure mode.
- Authorization: The model chooses tools dynamically. Your RBAC system wasn’t designed for “non-deterministic caller picks capability at runtime.”
- Data exfiltration: Tools that can read docs, tickets, or code can be induced or transmit sensitive data out of policy.
- Spend: Tool calls amplify token usage and downstream API bills. Without quotas and budgets, an agent is a cost spike generator.
- Forensics: You can’t answer simple incident questions: which prompt, which tool, which parameters, which output, which token, which policy.
The hard truth: if you can’t produce an audit trail that ties a tool call to an authenticated identity and an approved policy, your “agent” is a liability wearing a demo-friendly UI.
Tool choice is now architecture: pick your MCP surface area deliberately
Teams keep comparing models as if that’s the main decision. In 2026, the model is a replaceable component. The tool surface is your product’s real power—and your risk.
Table 1: Comparison of common MCP deployment patterns (what you gain, what you risk)
| Pattern | What it enables | Primary risk | Best fit |
|---|---|---|---|
| Local-only MCP servers (developer machine) | Fast prototyping; direct access to local repos, notes, CLI tools | Secrets leakage; inconsistent environments; zero central audit | Early R&D, personal productivity |
| Self-hosted MCP gateway (central) | Unified policy, logging, identity mapping, allowlists | You own reliability; misconfig becomes org-wide blast radius | Companies serious about compliance and ops |
| Vendor-hosted tool connectors | Quick path to SaaS data sources (CRM, tickets, docs) | Opaque logs; limited controls; dependency on vendor uptime | Small teams optimizing for speed |
| Tool sandbox (isolated execution) | Contains untrusted tools; reduces data and network exposure | More engineering; performance overhead; tricky UX | High-risk tool sets; regulated data |
| Bring-your-own MCP registry (internal catalog) | Discoverability with governance; standard reviews | Catalog sprawl if you don’t enforce ownership and deprecation | Mid-to-large orgs with platform teams |
If you’re building a product, don’t confuse “users can connect anything” with “platform.” Platforms need guardrails. If you don’t want to build guardrails, narrow the surface area and own the tools yourself.
What an MCP control plane actually needs (not marketing, actual mechanics)
“Control plane” can become a fluffy word. Keep it concrete: it’s the system that decides which tools exist, who can call them, under what identity, with what data, and how you can prove it later.
Key Takeaway
Agents don’t fail like microservices. They fail like over-permissioned human interns with an API key, infinite patience, and no intuition for what’s sensitive.
Minimum viable controls (non-negotiable)
Table 2: MCP governance checklist (what to implement before production)
| Control | What “good” looks like | What to log | Failure you prevent |
|---|---|---|---|
| Tool allowlist + ownership | Every tool has an owner, repo, versioning policy, and deprecation path | Tool name, version, owner, change history | Tool sprawl; abandoned connectors |
| Per-tool scopes and permissions | Scopes map to actions (“read tickets”, “create invoice”), not “full access” | Scope requested, scope granted, policy decision | Overbroad access; accidental destructive ops |
| Identity binding + token hygiene | Tool calls execute as a service identity or delegated user with clear attribution | Actor, tenant, delegated identity, token source | “Who did this?” ambiguity; account compromise blast radius |
| Approval gates for high-risk actions | Human-in-the-loop for money movement, prod changes, data exports | Proposed action, diff/params, approver, timestamp | Silent damaging actions; compliance failures |
| Full-fidelity audit trail | Reconstructable chain: prompt → tool selection → params → outputs → side effects | Input/output hashes, redacted payloads, correlation IDs | Un-debuggable incidents; weak postmortems |
Budgeting and rate limits: treat agents like load tests that talk
If your agent can call tools in loops, it will. Sometimes because it’s “reasoning.” Sometimes because a user asked for an exhaustive analysis. Sometimes because it got stuck. Without budgets, that becomes a surprise bill and degraded latency for everyone else.
Set budgets at multiple layers: per user, per workspace/tenant, per tool, and per workflow. Make budgets visible in product UI, not hidden in a backend dashboard. Users should understand that “run the agent” spends money and capacity.
Policy isn’t just RBAC; it’s content-aware constraints
Traditional RBAC asks: can this actor call this API? MCP forces you to ask: can this actor call this API with this input, sourced from this context, producing this kind of output?
That’s why prompt injection defenses matter, but not as “model safety.” It’s an app security problem. The attacker doesn’t need to jailbreak the model. They just need to shape the input so the model chooses the wrong tool with the wrong parameters.
The engineering pattern that wins: “thin agent, thick tools”
Teams keep stuffing logic into prompts and agent graphs. That’s brittle. The winning architecture is the opposite: keep the agent thin, and move business logic into tools with strict contracts.
Why? Because tools can be versioned, tested, code-reviewed, and observed. Prompts can be versioned too, but their failure modes are weirder and harder to bound. If you want predictable operations, build deterministic tools and let the model do orchestration and summarization—not policy decisions.
Design tools like internal APIs, not “LLM functions”
- Make side effects explicit: separate “plan” from “execute.” Provide dry-run endpoints.
- Use strong schemas: reject ambiguous params; return structured errors the agent can handle.
- Idempotency: if a model retries, you shouldn’t double-charge, double-create, or double-delete.
- Guard sensitive fields: don’t even expose them unless the policy engine grants it.
- Provide safe defaults: “read-only” mode until explicit escalation.
A concrete control-plane sketch you can implement this quarter
Not a grand platform rewrite. A pragmatic layer around MCP calls.
- Front all MCP tool calls through a gateway service that injects identity, enforces policy, and emits audit logs.
- Define tool tiers (read-only, write-low-risk, write-high-risk). Only tier-1 is callable by default.
- Put high-risk tools behind approvals (Slack/Teams button, internal web console, or ticket-based).
- Adopt a tool catalog with ownership metadata and a “last reviewed” requirement.
- Make budgets enforceable and fail closed: if you can’t attribute cost, block the call.
# Example: policy-gated tool invocation envelope (conceptual)
# Store this alongside your audit logs; redact payloads if needed.
{
"request_id": "uuid",
"actor": {"type": "user", "id": "user_123", "tenant": "acme"},
"model": {"provider": "openai", "name": "gpt-4.1"},
"mcp": {"server": "internal-gateway", "tool": "jira.create_issue", "version": "1.3.0"},
"policy": {"decision": "approved", "scope": "tickets:write", "approval_gate": false},
"params_hash": "sha256:...",
"result": {"status": "success", "output_hash": "sha256:..."}
}
This isn’t fancy. It’s what you’ll wish you had the first time an agent opens 400 tickets, exports a customer list into the wrong place, or edits production config because a doc it read told it to.
The market will split: “agent apps” vs “agent infrastructure”
Most startups building shiny agent UIs are competing on demos. The durable companies will compete on controls: governance, catalogs, policy engines, audit, approvals, and cost management. That sounds boring until you realize it’s how you get agents into regulated industries and core enterprise workflows.
Expect the same pattern we saw with cloud: early winners shipped convenience, later winners shipped control. AWS didn’t win because it had prettier demos than early PaaS products. It won because it created primitives operators could reason about, secure, and budget.
Three predictions worth holding yourself to
- MCP registries will become normal inside companies, with internal review processes like package repositories.
- “Tool risk scoring” will become a procurement artifact the same way SOC 2 reports became table stakes.
- The first big public agent incidents won’t be model hallucinations; they’ll be unauthorized tool actions that were fully “correct” given bad permissions.
If you’re building with MCP now, here’s the concrete next action: write your “tool incident” runbook before you add your tenth tool. Define what gets disabled, who gets paged, what logs you need, and how to unwind side effects. If you can’t answer those questions, you’re not running agents—you’re running a live-fire integration experiment against your own business.
One question to sit with: if an attacker can control some of the text your agent reads (an email, a support ticket, a shared doc), which of your MCP tools turns that text into money movement, data export, or infrastructure change? Name it. Then put it behind a gate.
