⚠️ Failure Mode: Most architects celebrating MCP's ability to connect LLMs directly to enterprise systems are skipping a critical question: what happens when the prompt is malicious? One crafted instruction can execute a real write operation against your ERP with no alarm, no gate, and no human review.
Enterprise teams are giving AI systems write access to their most critical business data — pricing, inventory, financials, vendor records — without a governance layer. When this goes wrong it does not look like a technology failure. It looks like a business crisis. Orders placed at zero price. Payments routed to wrong accounts. Inventory records wiped. And no audit trail to explain how it happened.
The technology enabling this is MCP (Model Context Protocol) — powerful, fast to implement, and dangerously easy to deploy without the architecture it requires. This post breaks down the boundary between semantic layer and MCP, shows exactly where the attack surface opens, and defines the three governance layers every enterprise AI system needs before going anywhere near write access.
The semantic layer is safe — but read-only
A semantic layer sits between your LLM and your data. It exposes a curated, permission-aware model — metrics, dimensions, KPIs — and nothing else. An LLM can query it freely because the worst outcome is reading data it is already permitted to see. Role-based permissions are enforced at the semantic layer. The data model is defined and controlled. The blast radius of any mistake is limited to a bad query result.
The limitation is fundamental: semantic layers are read-only by design. The moment you need AI to act — update a record, trigger a workflow, modify a price, approve a purchase order — you need write access. That is where MCP enters the picture.
MCP enables write access — and that changes everything
MCP servers can execute real operations against live enterprise systems. That power is also the risk. An LLM processing a crafted prompt injection can issue a perfectly valid MCP tool call with malicious intent. Without a governance layer, that instruction goes straight to your ERP. No validation. No human review. No audit trail.
Real-world example:
- A prompt is injected into a customer-facing AI assistant
- The injected instruction tells the LLM to set all product catalog prices to $0.00
- The MCP server receives a valid
update_product_pricetool call - The ERP executes it. No alarm fires.
- By the time anyone notices, thousands of orders have been placed at zero price
The three layers every MCP write path requires
Every MCP tool call that touches a write operation in an enterprise system must pass through three governance controls before execution.
1. Prompt validation layer
Before any write intent reaches the MCP server, validate the instruction independently of the LLM. Check: does this action match the user's stated goal? Is the scope within expected bounds? Do the parameter values fall within acceptable ranges? Flag and block anything outside the expected envelope before it gets further.
🔒 Security Pattern: Treat the prompt validation layer as an untrusted-input boundary. Apply the same rigor you would to any external API input — schema validation, value range checks, anomaly detection, and rejection of anything malformed or out-of-scope.
2. MCP server input and output schema enforcement
The MCP server itself must enforce a strict schema on every incoming tool call. Define explicit contracts for each tool: expected parameter types, value ranges, allowed record types, and maximum operation scope. Reject anything outside the contract at the server boundary, before execution. Apply the same validation to output — never return raw ERP data to the LLM without sanitization.
🔄 Resilience Pattern: Design MCP tool contracts to be narrow and specific. A tool that can only update price for one SKU at a time with a defined min/max range is far safer than a bulk update endpoint. Scope restriction is your first blast-radius limiter.
3. HITL governance gate
For any write operation touching critical business data — pricing, financial records, inventory, vendor data, purchase orders — require human approval before execution. This gate is not optional and must not be bypassable by the LLM. The agent submits the proposed operation and waits. A human reviews and approves or rejects. Only on explicit approval does the MCP server execute.
🤖 Agent Pattern: Implement HITL as a hard gate in your LangGraph workflow state machine. The agent transitions to a
PENDING_APPROVALstate and cannot proceed toEXECUTINGuntil the approval signal is received from an authenticated human actor. No LLM reasoning path should be able to bypass this transition.
The observability requirement
Governance without observability is theater. Every MCP write operation must generate a complete audit trail: who or what initiated it, the full prompt context that led to it, the validation decisions made at each layer, the human approval record, the exact operation executed, and the result. This trail must be immutable and queryable.
🔍 Observability Pattern: Use AgentOps or LangSmith to capture full session traces for every agentic workflow touching write operations. Tag every trace with the MCP tool name, parameter hash, validation outcome, approval actor, and ERP transaction ID. When something goes wrong — and it will — you need forensic replay, not log archaeology.
The architecture rule
Semantic layer for read. MCP for write. But every MCP write path must pass through prompt validation, MCP schema enforcement, and a HITL governance gate before touching any enterprise system.
The leaders celebrating "AI talking directly to ERP via MCP" are describing a system one prompt injection away from a business crisis. The architects who understand this gap will be the ones cleaning up the mess in 2027 — and Gartner has already said more than 50% of enterprise AI agents will fail by then. Governance is not a feature. It is the foundation.
Coming next
- A2A vs MCP — and where Google's UCP and AP2 fit in the agentic protocol landscape
Top comments (0)