DEV Community: dnyandeo bharambe

Semantic Layer vs MCP: Why Direct ERP Write Access Is an Enterprise Security Risk

dnyandeo bharambe — Tue, 16 Jun 2026 23:13:08 +0000

⚠️ 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_price tool 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_APPROVAL state and cannot proceed to EXECUTING until 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

Building a production LLM Judge: lessons from the enterprise audit engine

dnyandeo bharambe — Sun, 07 Jun 2026 16:56:30 +0000

When I was building the enterprise audit engine, the LLM Judge was the last thing I
planned to add. It felt like over-engineering. The main agent already had MCP tool
access to live device state, a policy file to reason against, and a LangGraph state
machine keeping it on track. That felt like enough.
Then during testing, the agent correctly flagged a non-compliant firmware version —
and recommended a remediation action that belonged to a completely different device
category. The reasoning was internally consistent. It just used the wrong rule.
Nothing in the pipeline caught it. The output looked clean. Without a second check, that
would have gone to the user.
That's when I added the Judge. Here's how it works and what I learned building it.
What the Judge actually does
The Judge is a separate LLM call that runs after every agent response, before anything
reaches the user. It gets two inputs:
• The agent's output — the proposed compliance verdict and any suggested
remediation
• A fresh read of the policy file — not pulled from the agent's context, read
independently
Its job is to compare those two things and decide whether the agent's reasoning holds
up against the actual policy. It's not re-running the audit. It's checking whether the
answer the agent produced is consistent with the rules the agent was supposed to
apply.
If the reasoning checks out, the output moves forward. If something doesn't line up, the
Judge blocks it, logs the mismatch, and returns an error instead of a verdict.

Why independence matters more than intelligence
The design decision that makes the Judge actually useful is a simple one: it doesn't
share context with the main agent.
Most multi-step agent pipelines accumulate context as they run — retrieved chunks,
intermediate reasoning, tool outputs. By the time the agent produces its final answer, it's
been reasoning inside a specific context window for several steps. That context shapes
what the agent sees as plausible.
If the Judge reads from that same context window, it's not really checking anything
independently. It's just re-reading the same information through a slightly different
prompt. Whatever bias or error the agent accumulated, the Judge inherits it too. That's a
rubber stamp, not a check.
The fix is straightforward. The Judge reads the policy file directly. Not from cache, not
from whatever the agent retrieved — from the file. Every time. That's what gives it the
ability to catch the category mismatch the main agent missed. The agent had
accumulated enough context during its reasoning loop that the wrong rule seemed
plausible. The Judge, reading the policy fresh, saw the inconsistency immediately.

How it sits in the LangGraph state machine
The Judge is a node in the LangGraph graph, not a wrapper around the graph. That
distinction matters for how state flows through the system.
After check_compliance runs and produces a verdict, the graph routes to llm_judge
before doing anything else. The Judge node reads the policy file, compares it against
the proposed verdict, and sets a pass/fail flag in the graph state.
From there the graph branches:
• FAIL — the output is blocked, the error is logged to AgentOps, and the response
returned to the user explains that the verdict couldn't be verified
• PASS — the graph moves to suggest_remediation, where the agent proposes
the corrective action
After suggest_remediation, there's a hard gate. The graph does not automatically
proceed to execute_remediation. The only path forward is a human clicking Approve in
the Streamlit UI. That approval event triggers the final node, which is the only place in
the entire graph where a write operation touches the database.
The Judge and the HITL gate are separate concerns. The Judge is about correctness
— did the agent apply the right rule? The gate is about authorization
— did a human sign off on the action? Both are necessary and neither replaces the other.

What it logs
Every Judge decision gets written to AgentOps as a structured event: the agent's
proposed verdict, the policy sections the Judge checked against, the final pass/fail, and
if it failed, the specific mismatch it found.
That logging turned out to be more useful than I expected. During development it made
debugging much faster — you could see exactly what the Judge was checking and why
it made the call it did. For a production enterprise system, it also creates a full audit trail
for every compliance decision the system touches.
If someone asks later why a device was flagged or cleared, there's a complete record:
what the agent found, what the Judge verified, and who approved the remediation. That
kind of traceability is hard to retrofit once a system is in production.

What I'd do differently
The main thing I'd change is adding a confidence threshold to the Judge output rather
than a binary pass/fail.
Right now the Judge either passes or blocks. That works for clear-cut cases, but there's
a middle category — outputs where the reasoning is mostly right but one detail is
uncertain — where a hard block isn't the right response. A confidence score would let
the system surface those cases to the human reviewer with a flag rather than just
blocking them silently.
The other thing is latency. Adding a second LLM call to every response adds time, and
for simple queries that don't need a full audit, that overhead isn't worth it. The intent
classifier at the FastAPI gateway already routes simple queries to the NIM worker and
skips the full agent. Extending that logic to also skip the Judge for low-stakes queries
would help.
The short version
The Judge is useful not because it's smarter than the main agent, but because it's
independent of it. Reading the policy fresh, without inheriting whatever context the
agent accumulated during its reasoning loop, is what gives it the ability to catch errors
the agent can't see from inside its own context window.
It adds latency and cost. For a system making compliance decisions on production
infrastructure, that's a reasonable trade.
Code is on GitHub. The Judge implementation is in the governance layer — happy to
walk through the prompt design or the AgentOps integration in the comments.

Why I chose MCP over RAG for live infrastructure auditing

dnyandeo bharambe — Thu, 28 May 2026 22:41:53 +0000

I've been working on a project to audit distributed hardware infrastructure — devices
spread across multiple sites, each running firmware that needs to stay compliant with a
central policy. Pretty standard enterprise ops problem.
My first instinct was RAG. Everyone reaches for RAG. You embed your documents,
stand up a vector store, and your agent can reason over your data. I've built RAG
pipelines before, they work well, so I started there.
Three days in, I switched direction.

The moment I realized RAG wasn't the right fit

I was testing the agent against a scenario where a device had failed a firmware check at
2am. The agent reported it as compliant.
The problem wasn't the model. The problem was that the data the agent was reasoning
over was from an embedded snapshot I'd generated two days earlier. The device had
drifted since then. The vector store didn't know — it can't know. It's a snapshot by
design.
That works fine for a documentation assistant. For infrastructure audit it's a problem,
because you need to know what's happening now, not what was true when you last ran
the embedding pipeline.

What I needed wasn't retrieval — it was access

Here's the reframe that changed how I thought about this.
RAG answers the question: what documents are relevant to this query?
What I actually needed to answer was: what is the current state of device X right now?
Those are different questions. One is a search problem. The other is a database query. I
was using the wrong tool.
The inventory — firmware versions, device health, site assignments — lives in a SQLite
database. The compliance policy lives in a structured text file. Neither of these is a
document in any meaningful sense. Chunking them and embedding them into a vector
store was me forcing square data into a round hole because that's what I knew how to do.

server that exposes it as tools the agent can call:
• get_inventory() — returns live device state, current to the second
• query_policy() — reads the policy file and returns the requirements
• flag_violation() — marks a device non-compliant with structured metadata
The agent calls these the same way your application code calls an API. No embedding
pipeline. No staleness problem. No guessing at similarity scores for what is
fundamentally a structured query.

The gateway nobody talks about

One thing I'd push back on in most agent tutorials — they wire the LLM directly to the
frontend and call it done.
I put a FastAPI gateway in between, and I'd do it again every time.
The practical reason: NVIDIA NIM credits aren't free. A misconfigured client or a
runaway loop can drain your quota in minutes if there's nothing between the UI and the
model. The gateway enforces rate limits per IP before a single token is generated.
Saved me actual money during development.
The better reason: not every query needs the full audit agent. Simple questions — how
many nodes are in Bellevue? — don't need a multi-step LangGraph agent burning
Gemini 2.5 tokens. The gateway classifies intent and routes accordingly. Simple queries
go to a lighter NIM worker. Full compliance audits go to the Gemini agent.
It also centralises auth and logging in one place, which matters when you need to show
a security team exactly what the agent did and when.

The Judge

This is the piece I'm most glad I built, and the one I almost skipped.
Every response — whether it came from the NIM worker or the Gemini agent — passes
through a secondary LLM before it reaches the user. I call it the Judge. Its only job is to
read the agent's output, check it independently against the policy file, and decide
whether the reasoning holds up.
During testing, the Judge caught something the main agent missed. The agent had
correctly identified a non-compliant firmware version, but applied a remediation rule that
belonged to a different device category. The logic was sound — it just used the wrong
rule. The Judge caught it because it reads the policy independently, without inheriting
whatever context the main agent had accumulated during its reasoning loop.
That independence is the point. If the Judge just re-reads the agent's own context, it's
not really checking anything. You want it reading from the source, fresh.

Humans stay in the loop

The agent can suggest remediation — here's the CLI command to fix the firmware drift
on node 7. It cannot run it.
There's a hard gate in the LangGraph state machine. Suggest remediation and execute
remediation are separate nodes, and the only path between them runs through a human
decision in the UI. An architect clicks Approve. Then and only then does the write
operation touch the database.
For infrastructure this felt like the right call. The cost of a false positive — a remediation
that runs when it shouldn't — is much higher than the cost of an extra approval click.

What I'd do differently

Two things.
I'd instrument RAGAS metrics from day one. I ended up retrofitting evaluation on the
agent's audit outputs and found gaps I'd been manually poking at for weeks.
Faithfulness and context relevancy scores would have surfaced those faster.
And I'd write the red-team report in parallel, not after. I know what failure modes the
Judge catches now, but I reconstructed most of that knowledge from memory rather
than documenting it as I found it. A live failure log from the start would've made that
report much sharper.

The short version

RAG is the right tool for knowledge retrieval over static content. It's a less natural fit
when your agent needs to query live structured data and act on what it finds.
MCP let me give the agent real database access through a typed tool interface — no
embedding pipeline, no staleness, no similarity search on what is fundamentally a
relational query. For infrastructure audit, that was the right call.
Code is on GitHub if you want to dig into the architecture. Happy to go deeper on the
LangGraph state machine or the Judge design in the comments.