{
  "id": 5008393,
  "title": "Your Agent Has Tools Now: Why MCP Tool Calls Need Runtime Verification",
  "url": "https://urgent.news/2026/09/02/your-agent-has-tools-now-why-mcp-tool-calls-need-runtime-verification",
  "topic": "ai",
  "section": "AI",
  "published": "2026-09-02T04:01:34.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/correctover/your-agent-has-tools-now-why-mcp-tool-calls-need-runtime-verification-53i6"
  },
  "original_language": "en",
  "account": "LLM applications have mostly focused on text risk, but the introduction of tool calls has changed the game. Tools like shells, HTTP fetchers, and filesystem clients enable agents to perform actions with actual credentials on your infrastructure. This expands the attack surface from \"text the model wrote\" to \"actions the model took.\"\n\nThere are four main ways tool calls can go wrong:\n\n1. Code execution tools can lead to remote code execution, as shell, exec, and interpreter tools can execute malicious commands if not properly secured.\n2. Fetch/HTTP tools can be used for server-side request forgery (SSRF), allowing agents to access internal services and private RFC1918 addresses.\n3. Tools can be used for credential and environment-variable exfiltration, where sensitive data is read and sent elsewhere via HTTP tools.\n4. Prompt injection can occur when untrusted content in the model's context contains instructions that trick the model into making unauthorized tool calls.\n\nConfiguration scans are a good starting point, but they are not sufficient. Static analysis can identify many issues, but it cannot account for the dynamic, context-specific nature of tool calls. A static blacklist approach is ineffective, as safety is highly contextual depending on the tool, caller, arguments, and chain of preceding calls.\n\nRuntime verification is necessary to evaluate every tool call before it runs. A runtime verifier should check five key aspects:\n\n1. Structure: validate well-formed tool names, arguments as objects, nesting depth, and payload size.\n2. Schema: enforce per-tool validation rules, such as types, required fields, enums, numeric ranges, and string lengths.\n3. Identity: verify which agent is making the call using an allowed-caller list.\n4. Integrity: use cryptographic hashes for arguments and signed receipts to bind the verification verdict to the exact input data.\n5. Security intent: perform semantic analysis of the call in context, checking for command-injection patterns, SSRF targets, path traversal, environment-variable exfiltration, obfuscation, and cross-tool attack chains.\n\nTwo non-negotiable properties for the runtime verifier are fail-closed (blocking calls if verification is unreachable or receives malformed input) and deterministic, fast performance.",
  "summary": "For most of the short history of LLM applications, model risk was text risk. A model could output bad advice, leak something from its prompt, or produce a convincing phishing draft — but it couldn't touch your machine. The worst case ended at the screen. Wire a few tools into that model — a shell, an HTTP fetcher, a filesystem client, a cloud SDK — and the equation changes. With the Model Context…",
  "key_points": [
    "Tool calls expand LLM attack surface from text to actions with actual credentials",
    "Runtime verification necessary to evaluate every tool call before execution"
  ],
  "editors_take": "The introduction of tool calls in LLM applications shifts the security focus from text output to actions taken, requiring runtime verification to prevent exploitation of expanded attack surfaces.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}