Five Conversations That Kill AI Agent Deployments
Five Conversations That Kill AI Agent Deployments
TLDR
| Problem | MCP Audit Solution |
|---|---|
| "We can't let AI access production data" | Every access is logged with who, what, when |
| "How do we know what Claude did?" | Full audit trail in their own Log Analytics |
| "What if it runs a destructive command?" | Policy engine blocks dangerous tool calls |
| "Our auditors need evidence of controls" | Structured audit logs, maskable sensitive args |
| "We need to control which users can do what" | Per-identity, per-tool policy enforcement |
"We can't let AI access production data"
This one comes out first, every time. But if you push on it a little, it's not really what they mean. Nobody's saying the agent can never touch production. What they're saying is: right now, we'd have no idea what it did once it got there.
Fair point. If an agent queries a database through an MCP server, who asked for it? What parameters did it pass? When did it happen? If you can't answer those questions, of course you're going to say no. I would too.
The gateway is a YARP reverse proxy that sits between your agents and your MCP servers. Every tool call flows through it. Every request gets logged - the caller's identity (pulled from their JWT, so UPN, app ID, OID, whatever claims you're working with), which tool was called, the arguments, the response, timestamps. All of it.
The part that usually gets people's attention: it deploys into your infrastructure. Data doesn't leave your perimeter to end up in some vendor's SaaS platform. That one detail tends to unblock the conversation pretty quickly.
"How do we know what Claude did?"
I love this one because it's always phrased with a specific agent name. "What did Claude do?" "What did GPT do?" Sometimes it's "what did Dave's weird Python thing do?" - which tells you a lot about the state of agent governance at most companies right now.
At most organisations today? You don't. You might have some application logs somewhere. You might be able to piece something together from container output if you squint hard enough. But a proper audit trail that your security team can query? Almost nobody has that.
The gateway writes structured audit events to Log Analytics. Not just text dumps - actual structured records with a consistent schema. Agent identity, tool name, arguments, response, policy decision, latency. Your security team can write KQL queries against it. Your SIEM picks it up. Same tools they already know.
I think the mistake a lot of teams make is treating logging as a "phase two" problem. It's not. The moment you can't tell an auditor what your agent did last Tuesday, you've got a phase one problem that blocks everything else.
"What if it runs a destructive command?"
This is the one that actually kills projects. The others slow things down, but this one stops them dead.
The concern is legitimate. You've got an agent connected to a filesystem MCP server - it could, in theory, call a delete operation. Connected to a cloud infrastructure tool? It could modify resources. The fact that it probably won't isn't good enough when you're talking about production systems.
The gateway has a policy engine that checks every tool call before it gets forwarded to the MCP server. You write regex-based deny patterns for each tool. If an argument matches a pattern you've flagged, the request gets rejected and logged as a policy violation. It never reaches the MCP server.
Say you've got an MCP server that can manage files. You can block any call where the arguments contain rm -rf or DROP TABLE or whatever keeps you up at night. The agent gets a structured error back. The attempt gets logged. Your production data stays exactly where it was.
You decide what "dangerous" means for your environment the gateway enforces it. Doesn't matter which agent made the call or how creative the prompt was.
"Our auditors need evidence of controls"
SOC 2, ISO 27001, FCA, HIPAA - the acronym changes but the auditor's question is always the same: "what controls do you have over AI agent actions, and can you show me evidence they work?"
What auditors want is simple. They want to see a rule that says "this identity can't call this tool." And then they want to see a log entry showing that when someone tried, it got blocked. Control and evidence. That's it.
The gateway gives you both. The policy config defines which identities can call which tools and what argument patterns are blocked. The audit logs record every tool call and every policy decision. When the auditor asks to see it, you open Log Analytics and show them.
One thing I added early on was argument masking. Your audit logs need to show that controls are working, but they shouldn't contain the sensitive data you're trying to protect. So you can mask specific arguments in the log output. The auditor sees the denied request, the policy that caught it, and the identity involved - without seeing customer PII or API keys in the log entries.
"We need to control which users can do what"
This usually comes up third or fourth in the conversation, once people accept that agents might actually make it to production. Not every agent should have the same access. The research team's agent doesn't need write permissions. The junior analyst's agent probably shouldn't be calling the same tools as the principal engineer's.
The gateway lets you lock this down per identity and per tool. Identity comes straight from Azure AD JWT claims, so there's no custom auth system to build - it just reads the token your agent is already carrying. You set up allow-lists per route (which identities can reach which MCP servers) and deny rules per tool.
Unauthorised request comes in? Rejected before it hits the upstream server. You update the policy in App Configuration, and it takes effect within seconds. No redeployment, no code changes to your agents, no SDK work. Your agents don't even know the gateway is there - they just think they're talking to the MCP server.
Where this is heading
Six months ago, when someone raised these objections, the answer was usually "we'll build something" or "we'll wait for Microsoft to add it." Neither of those timelines worked. Auditors don't wait for your internal tooling roadmap.
The gateway is live, have a look. You don't need to change your agent code - just update your MCP server URL to point at the gateway and everything gets audited, policy-checked, and metered.
If you've got a working agent that's stuck in staging because of the security conversation, . That's why I built it.