The MCP tool name is not the permission check

A safe-sounding MCP operation can still cross an unsafe boundary. In the Langflow and Argo CD disclosures, the relevant permission check was not the tool's name but the executable or API target that the service ultimately reached. A third study, NOMOS, shows why independent checks at that point can help, and why their policy rules still need testing.

The three records are different kinds of evidence: two published software vulnerabilities, and one controlled defensive experiment. Neither vulnerability dossier establishes a confirmed attack against a named production victim, and the experiment is not a deployment-wide security guarantee. The common question is where an application chooses to trust a model's requested action. Langflow, Argo CD MCP and NOMOS allow that question to be answered at three different points in a tool chain.

An MCP tool generally exposes a named operation and a parameter schema. That interface can make an agent's intent legible, but it does not independently establish which operating-system processes may start or which REST endpoints may be reached. Those powers come from the host application, its service credentials, and the code that turns arguments into effects. A model instructed to use only delete_application is not constrained to applications if the underlying code can construct a different endpoint from its argument.

The Argo CD MCP CVE describes exactly that kind of mismatch. The delete_application tool accepted an applicationName value without adequate path validation. The constructed request could traverse to another Argo CD API endpoint, making deletion of a repository, cluster or project possible where the server's Argo CD token had the corresponding permission. The affected published range is through argocd-mcp 0.9.0. The security limit here is important: the MCP bug did not magically override Argo CD's RBAC. It redirected an authenticated request and could use whatever rights that token already had. See the RBAC boundary Claim.

In Langflow's MCP stdio disclosure, the effect was process creation rather than REST deletion. User-controlled MCP server configuration could supply an executable and arguments launched by the Langflow host. Some implementations also assembled these values through bash -c. The relevant condition was the ability to configure an MCP server or provide flow-embedded settings. In exposed development deployments where LANGFLOW_AUTO_LOGIN allowed token acquisition, that condition might not require ordinary user credentials; in other deployments, the reported path required an authenticated user with relevant configuration access. See the access-precondition Claim.

Langflow version 1.9.0 added validation at a REST-facing configuration path, yet the advisory reports that flow definitions and tweaks could still reach the underlying process-launch function without passing that validation. Version 1.10.3 moved shared validation closer to the final execution sink and eliminated the shell-based launch path described in the advisory. The affected packages and ranges differ, so operators should consult the component-specific version record, not infer that any earlier API validator was sufficient.

This distinction is wider than one framework. Validation performed at a convenient entry point is only complete when every route to the same effect passes it. In Langflow, the shared effect was process spawn. In Argo CD MCP, it was the normalized authenticated API request. The investigation should therefore begin at the final operation: what exact executable, command arguments, HTTP method, path, target object and credential will actually be used? It should then trace all ways those values can be supplied.

The NOMOS preprint proposes converting natural-language rules into schema-checked, deterministic gates before state-changing tool calls. The authors report reducing violations from 66.3% to 2.6% in their airline tasks and from 30.8% to 6.9% in retail tasks. On a particular AgentDojo banking evaluation, they report zero attack success, while the three other tested suites reached at most 3.6%. These denominators belong to different experimental tasks, not to deployments of Langflow or Argo CD, and they cannot be used to claim that NOMOS would have prevented either published vulnerability. Benchmark Claim.

The same paper describes a development gate that rejected 95.9% of otherwise task-passing calls. That is the counterweight to treating external policy as a magic fix. A deterministic gate can consistently enforce the wrong rule, or miss actions that never pass through the tool path being monitored. For MCP operators, robust controls therefore require both code-level validation of the final target and a tested least-privilege policy for whether the requested effect is allowed. Neither a fluent model explanation nor a tool's human-readable name substitutes for those checks.

For a hosted tool, first identify the authority held by the host process or service token, then identify the exact sink that converts parameters into a process launch or API call. Verify every configuration route reaches the same validation and authorization logic. For Argo CD, constrain the service token and inspect the normalized target, rather than trusting the tool name. For Langflow, check affected package versions, deployed configuration access and sink-level validation; upgrading to a documented fixed version does not automatically make arbitrary third-party MCP packages trustworthy. For policy gates, measure blocked legitimate work as well as rejected dangerous calls.

These steps address separate failure modes. They do not prove that an agent cannot make a harmful request, but they reduce the ability of such a request to borrow authority the agent was never meant to wield. For the broader mechanism, see agent authority.