Runtime behavior monitoring for stdio MCP servers -> catching side effects and attributing them to tool calls

[Agent-Hellboy]

Pre-submission Checklist

• This post follows the MCP community guidelines

What would you like to share?

Most MCP server testing checks protocol/schema conformance and what a tool returns. But an MCP server is a real process that can shell out, read files, and open sockets — and a malicious or compromised one can do that in response to a tools/call without any of it showing up in the response. I've been exploring observing that at runtime and tying it back to the exact tool call that caused it.

Scope: this mostly targets stdio servers. Stdio is where it fits cleanest today — the fuzzer/client launches the server as a child process, so we get its process group for free, and stdio calls serialize (one tools/call active at a time), which makes per-call attribution exact. HTTP/SSE with concurrent requests is harder and out of scope for now (see question 2).

What I built (sharing for feedback):

• An eBPF sidecar (Rust + aya) attached to sys_enter_* tracepoints — execve, connect/sendto, openat, unlink, chmod, ptrace — streaming events to userspace.
• The client sends begin/end marks around each tools/call, so each observed syscall is attributed to that specific call. A policy layer turns them into findings.

Repo: https://github.com/Agent-Hellboy/mcpfz-probe

Attack vectors it surfaces (detection, which is what makes them avoidable — the probe reports, it doesn't sandbox):

• execve of unexpected binaries (/bin/sh, curl, …) — command injection / RCE, shelling out, running a downloaded payload.
• connect / sendto to non-allowlisted hosts — data exfiltration, C2 beaconing, and SSRF (e.g. a fuzzed URL hitting the cloud metadata IP 169.254.169.254).
• openat on sensitive paths (~/.ssh, .aws/credentials, .env) — credential / secret theft.
• openat for write outside the workspace — dropping payloads, tampering with files it shouldn't touch.
• unlink outside the workspace — destruction / anti-forensics (e.g. wiping logs).
• chmod (making files executable) — persistence / backdoor setup.
• ptrace — process injection / anti-debugging.

All of these can be triggered by a tool implementation that trusts its input, so pairing them with a fuzzer means fuzzed inputs that cause real side effects show up as findings instead of silently passing.

All of these can be triggered by a tool implementation that trusts its input, so pairing them with a fuzzer means fuzzed inputs that cause real side effects show up as findings instead of silently passing.

Questions for the community:

1. Is runtime behavioral attestation something the MCP ecosystem cares about, or is isolation considered out of scope for the protocol?
2. For HTTP/SSE servers with concurrent requests, is there any request-correlation signal (headers, ids) worth standardizing so runtime observations can be tied to a specific call the way stdio allows?
3. Which behaviors would be most valuable to flag by default for MCP servers specifically?

Relevant Links

No response