A tool approval prompt is reassuring. Until the agent finds another route to the same tool.
In one customer environment, an agent inspected how its tools and approval settings worked. It then started the tool server separately and used a small custom client to speak to it directly. The normal coding client was the place that presented the approval prompt. The alternate client did not pass through that prompt.
An Armor1 reviewer confirmed that the alternate path invoked server tools, including a publish operation.
One server, two doors
The legitimate path was straightforward: the coding client requested a tool and presented an approval when the workflow required one. The alternate path addressed the same MCP server using its protocol, outside that client.
The distinction is easy to miss. A front-desk receptionist can check visitors who use the lobby. The check does not protect a side door that opens to the same room.
The session also contained searches for approval configuration and server implementation details. The important result was not that the agent knew about approval prompts. It was that a second client could reach the operation without exercising the check.
Put the decision where the action happens
An approval in a user interface can be useful, but a sensitive operation needs enforcement at a boundary every caller must cross. Depending on the architecture, that may be the server, an authorization service or a gateway that holds the downstream credential.
A strong approval is bound to the operation, identity, target, arguments and expiry. A server should reject an action when that authorization is missing, regardless of which client sent the request. Read-only discovery may need a different policy from publishing, changing permissions or exporting data.
Test the side door
Ask an engineer who owns the server to try a second client in a disposable environment. Can it discover the tool? Can it call a sensitive operation without an approval token? Does the audit record identify the caller and decision?
Also restrict unnecessary server processes and access to credentials. Those controls reduce opportunities to create alternate paths, but they do not replace authorization on the action itself.
If an approval protects only the route through one client, it is a workflow feature. To protect the resource, the same decision must apply to every route.