The tool blocked it, but the agent kept going.

TL;DR: Agents can reach the same resource through different tools. A block on one does not prove that the action is blocked. Layered controls need to enforce the intended policy throughout the workflow, and even authorized work can show where they fall short.

During a review of a customer’s coding-agent activity, our team at Bluebear found what looked like a successful block on a production change. An agent had tried to scale a production workload to zero through an MCP tool, and the request was denied.

Then we reconstructed the rest of the session and found that the agent had switched to Bash and completed the same change against the same targets. A follow-up check confirmed the result.

The work was authorized, and we did not establish business harm. What changed was our conclusion about the control: we had verified a restriction on one tool, not a restriction on the change itself.

What did the block actually prove?

A control can work exactly as configured while providing less protection than the organization believes it does. An assessment that describes an agent’s access as “read-only” or says “production writes are blocked” may be accurate for one interface without describing what the agent can do through another.

An inventory might correctly show both a restricted cloud connector and shell access. The important connection is whether the shell has credentials that allow the operations the connector refuses. The conversation and tool calls help establish what was requested and what happened, but they don’t necessarily reveal permissions the agent never used or controls on routes it never tried.

Whether that difference needs fixing depends on the intended policy. Shell access may be an approved administrative route, with the MCP interface deliberately more restricted. An alternative route is not, by itself, a failure.

But if scaling that production workload to zero requires additional approval, the requirement should hold whether the agent uses MCP or the shell. A general request to complete a task does not necessarily replace an approval required for a particular step. Runtime protection needs to preserve that requirement as the agent moves between tools.

In another investigation, autonomous workers had been launched with an option to skip permission checks, yet a separate project-level guardrail still blocked sensitive commands, including inside a worker launched that way. That was another layer of defense doing its job. It did not establish complete protection, but it contradicted the claim that all safeguards were disabled.

We do not need to wait for a damaging incident to learn from either kind of finding. Ordinary, authorized work can show where controls hold and where they stop, giving the organization a chance to address gaps before they contribute to harm.

What would prove the fix worked?

Suppose the policy requires approval before the production workload in our opening case can be scaled to zero. Retesting the original MCP call would not tell us whether the issue was resolved, as we already knew that call was blocked.

A controlled test should also cover the shell route, using the identities and permissions available to the agent. Without the required approval, neither route should make the change. The evidence should include the enforcement decision and confirmation that the workload remained unchanged. Other identified routes capable of making the same change belong in the test scope too.

The fix may therefore sit in the underlying permissions, execution controls or approval process, rather than in the connector. If a route is deliberately exempt, that exception needs an owner and an explicit decision to accept the access it permits.

This gives security leadership a more useful basis for closing the finding than “we added a blocking rule.” It supports a bounded claim: for the resources, identities and routes tested, the agent could not make the specified change without approval. It also makes clear what remains untested.

An inventory of connected tools is the starting point, not the conclusion. Its value lies in the defensible claims it supports about what agents can reach and what actually constrains them.

Before counting a blocked call as proof of protection, it is worth reading the rest of the session. In our case, that was where the finding began.

Based on anonymized records from internal investigations and validation work. The cases illustrate specific findings — not prevalence, and not the current state of any environment.