The hype cycle for AI agents is colliding with the hard reality of enterprise operations. While a developer can wire a Large Language Model (LLM) to a few tools in an afternoon, the resulting system often collapses under the weight of production traffic. The core failure isn't usually the model's reasoning capability; it's the lack of a strict contract between the model, the tools, and the data. Sudhanshu Thakur’s recent analysis on DEV.to argues that most teams are building agents without a clear boundary, treating the Model Context Protocol (MCP) as a silver bullet for security when it is merely an interoperability layer.

The Illusion of the Demo

An impressive demo hides a dangerous truth: agents that can approve refunds or change production configurations are distributed systems with an unreliable reasoning component. When an agent calls the wrong tool or retries a payment operation without idempotency checks, it doesn't just return a bad answer; it creates an operational incident. The problem is that many early implementations expose tools with only a name, description, and input schema. This is insufficient for production. A safe tool contract must explicitly define tenant access, valid values, approval requirements, and audit trails. A tool description is not a security policy.

MCP as the Interoperability Layer, Not the Gatekeeper

MCP standardizes how AI applications discover and use external tools, preventing the need for bespoke integrations for every model. However, this standardization does not automatically grant safety. Thakur emphasizes that MCP should be treated strictly as an interface. The platform, not the model, must decide whether an action is allowed. A production-ready MCP tool must define its business purpose, classify read versus write operations, enforce authentication, and specify timeout and retry rules. If the model requests an action, the gateway must validate the user, evaluate policy, and check idempotency before the request ever reaches the domain service.

Read vs. Write: The Asymmetry of Risk

Not all tools are created equal. Read-only tools, such as searching a knowledge base or checking an order status, generally require standard user authorization. Write tools, which create payments, update customers, or deploy software, demand significantly higher controls. These should include explicit confirmation, second approvers, transaction limits, or dry-run modes. Developers must avoid hiding write operations behind friendly names like 'manage_account.' Instead, use descriptive names like 'create_refund' or 'disable_user' to reveal risk to models, developers, and security teams alike. Clear naming conventions are a critical first line of defense against accidental data corruption.

The Five Horsemen of MCP Security

MCP-based systems introduce familiar security risks in new forms. Excessive permissions expand the blast radius if the model or server is compromised. Prompt injection occurs when untrusted content in a document or ticket attempts to hijack agent instructions. Confused deputy problems arise when an agent uses its own powerful credentials to perform actions a user isn't authorized for. Tool poisoning involves malicious or poorly maintained tools with misleading descriptions, while data leakage happens when the agent combines information from different tenants. The solution is layered security: least privilege, isolation, validation, monitoring, and clear ownership.

Observability Is Non-Negotiable

Traditional monitoring asks what failed and which service was slow. Agent observability must go deeper. It needs to track the original user intent, the context retrieved, the tools considered, the policy decisions made, and the final data returned to the user. Every action requires a correlation ID that follows the request across the model gateway, MCP server, domain service, and audit system. Without this trail, debugging an agent's decision becomes guesswork, making it impossible to prove accountability in regulated industries.

Start Narrow, Scale Carefully

The best first production agent is rarely a general-purpose assistant with access to the entire company. It is a bounded workflow, such as searching internal documentation, summarizing support tickets, or validating an invoice. Teams should measure accuracy, latency, cost, refusal quality, and tool-selection errors before expanding. A narrow agent with clear boundaries creates more business value than a general agent that appears intelligent but cannot be trusted. The goal is controlled autonomy: systems that can complete useful work while remaining observable, explainable, reversible, and accountable.

Key Takeaways

  • MCP is an interoperability standard, not a security layer; it does not automatically enforce permissions or safety.
  • Production agents require a strict contract defining tenant access, idempotency, and audit trails, not just tool descriptions.
  • Differentiate between read and write tools: write operations demand higher controls like approval workflows, transaction limits, and explicit confirmation.
  • Observability is critical: track user intent, policy decisions, and tool selection with correlation IDs to debug and prove accountability.

The Bottom Line

Stop treating MCP as a security feature. It is a plumbing standard. If you haven't built the identity, policy, and audit layers around it, you aren't building an enterprise agent; you're building a liability with a chat interface.