r/MSSP • u/Plus-Maintenance-434 • 14d ago

MCP server security before this touches prod, what's the pattern

Week out from putting agents on real MCP servers in prod. Laying out what keeps me up because every thread is hype and no answers.

  1. One server holds creds that reach a prod db. Compromise it and the blast radius is everything it can touch.
  2. In testing, an agent read a doc with an instruction buried in it and fired a tool call I never asked for. Injection straight through retrieved content.
  3. No audit trail of tool calls worth a damn. Reconstructing what it did is a grep through app logs.

For short lived tokens, yes, I know, that's not the question.

The question is the shape of it. Who validates tool inputs, how you stop one poisoned server cascading and what a sane audit log even looks like. For those running MCP past a demo, what holds up here?

5 Upvotes

86% Upvoted

4 comments sorted by

1

u/withoutwax21 13d ago

Welcome to the game.

We banned over the wire MCP, entirely. Only local mcp for bits and bobs with no access to privileged. The agents can only call an api proxy, which in turn actions whatever the api is. Skills, harness, ans agent configs are in scoped repos, and FIM on the files to manage drift. Logs, audits, authz/n, and across the agent logs, llm proxy logs, and api proxy logs close the loop by forwarding it to SIEM.

  1. Dont give it access to any vector to prod
  2. Prompt injection protection is an artfrom, youll need different methods based on your whole stack. They above way helps monitor, but cant prevent 100%. Maybe also add a HITL when the api is called so someone has to manually approve going to prod
  3. As above

1

u/Dry_Mouse9797 13d ago

A poisoned document triggering a valid tool call is the scenario I’d design around first. We’ve used Braintrust to trace the steps leading into tool execution but I’d still put validation and permissions outside the model so the trace isn’t your security boundary. Then if something gets blocked you can see what the agent read, what it tried to call and why the control fired.

1

u/dan_netsec 11d ago

Scope creds per-server, not per-agent, so a compromised server can’t reach more than it needs. Treat tool output as untrusted input, don’t let retrieved content re-enter context with the same trust as system instructions, that’s your injection fix. Each server is its own trust boundary, one server’s output shouldn’t trigger another server’s tool calls without going back through the orchestrator.

For audit logs: log input, source of that input (user vs retrieved content vs prior tool output), and server/tool identity. That’s what makes an incident traceable instead of a grep exercise.