“Expected Behavior” Is Not the Same as Safe: MCP Command Execution and the Agent Attack Surface

The reply that should worry you

A recurring exchange in agent security goes like this. A researcher reports that a Model Context Protocol server will execute arbitrary shell commands emitted by the model. The maintainer replies, reasonably, that the server exposes a command-execution tool on purpose—running commands is what it is for—so this is expected behavior, not a bug. And they are right. The tool is doing exactly what it was built to do.

That is precisely why it should worry you. In classic application security, “the code did what it was written to do” usually ends the conversation. In agent security it opens it. Because the entity deciding when to invoke that perfectly-working tool is a language model, and a language model’s decisions are influenced by whatever text lands in its context—including text an attacker controls.

Capability, decision, and where they got merged

Traditional software keeps two things separate: what a component can do and the authenticated request that asks it to do that. A database can drop a table; it drops one only when an authorized query says so. Agent tool-calling quietly collapses that separation. The “request” is now a probabilistic decision by a model reading a mix of trusted instructions and untrusted content, and the model cannot reliably tell which is which.

So when the MCP maintainer says command execution is expected behavior, translate it: the capability is intentional, and the decision to use it has been delegated to something that can be argued with. The vulnerability is not in the tool. It is in the missing layer between the model’s decision and the tool’s capability.

The fix is not removing the tool

You often cannot delete the command-execution tool—it is why the agent is useful. The move is to reintroduce the boundary the tool-calling architecture removed: a pre-execution gate that runs deterministic code between the model’s decision and the side effect. The model may still decide to run rm -rf; the gate decides whether that decision is honored.

# pip install constitutional-agent
from constitutional_agent import Constitution

constitution = Constitution.from_defaults()

async def guarded_mcp_call(tool_call, env):
    """Gate every MCP tool invocation that has real-world side effects."""
    decision = constitution.evaluate({
        # Governance: is this destructive / unapproved for its blast radius?
        "proposed_spend": tool_call.blast_radius,
        "approved_budget": env.get("approved_blast_radius", 0),
        "gate_override_without_amendment": tool_call.is_shell_exec,
        # Epistemic: did any of this context come from untrusted input?
        "failing_tests": env.get("untrusted_input_present", 0),
    })

    if decision.system_state.value == "FREEZE":
        # The command never reaches the shell. Log and stop.
        return Blocked(reason=decision.gate_results)

    return await tool_call.execute()

The gate is deterministic Python. It returns a system state, and your code—not the model—branches on it. An untrusted-sourced request to run a high-blast-radius command trips the governance gate to FAIL, the system state goes to FREEZE, and the shell call is never made. The tool kept its expected behavior. You added the boundary that decides whether to use it.

Minimize the registry while you are there

The gate handles the moment of invocation. The other half is reducing how much can be invoked at all. Every tool you register is a decision the model is now allowed to make. A command-execution tool wired into an agent that also reads untrusted web content is a maximal attack surface. Register the smallest set of tools the task needs, scope each one’s blast radius, and gate the destructive ones specifically. Least privilege did not stop being good advice because the caller is a neural network.

“Expected behavior” describes the tool. It says nothing about whether the decision to invoke it was trustworthy. Agent security lives in that gap, not in the tool’s changelog.