An agent permission check is only as strong as the effects it can see

An agent's permission prompt may approve a harmless-looking tool call while the operating system, a connected service or a hidden execution path produces a much broader effect. Recent MCP, desktop and sandbox investigations expose the same design question from different directions: does the security check see the resource and operation that actually change state, under the identity that actually performs them?

AWS's Strands Box preview moves several decisions outside the model, yet documents a class of direct file reads that its policy history cannot see. In Obsidian-TC, a valid caller could choose a different vault. In Claude Desktop, opening a repository could execute a local git.exe before a model ever requested a shell command. These are not the same bug or a single campaign. Together they show why a tool name, a model intention and a successful authorization event are insufficient descriptions of the eventual effect.

Two additional examples clarify why such a table cannot be reduced to a single 'prompt injection' rate. The Visual Studio Copilot path-alias issue compared one filename while Windows resolved another. The Trinity Telegram flaw let an agent credential exercise an owner-level route, while BeamMCP accepted nested arguments that its advertised schema said would be rejected. These fail at different steps: path identity, principal authority and argument validation. An accurate root cause determines which regression test has meaning.

Strands Box pairs OS containment with external Dogwood decisions for governed network, shell, Python and MCP operations. AWS describes a policy that can block a later request after an observed sensitive read, and a gateway that inserts an API credential after the request is permitted. That is stronger in one respect than asking the agent to remember a prohibition. But direct filesystem grants in box.toml do not enter Dogwood's history. Containment may still limit which files exist in the agent's view, while a history-based rule incorrectly concludes that no sensitive read occurred. The governing code, including interpreters that run outside the agent sandbox, also becomes part of the trusted computing base.

The APEX architecture addresses a related problem earlier in the workflow: it compiles the legitimate task before untrusted material arrives, then checks proposed external effects and dependencies against that authority. Its published benchmark results were strong in the authors' specified environment, including zero successful attacks on five benchmarks and 0.56% on a sixth. Those figures do not prove universal coverage. An unmodeled subprocess, network side effect or compiler error may not appear at the chosen gate. The paper's residual SkillInject example also involved altered report wording rather than a separately observable unauthorized external effect, showing why judging the final deliverable may require a different test from authorizing a tool call.

AgentTracer runs the reasoning in the opposite direction, using action traces to identify where suspicious behavior originated. The authors report 97.34% detection and 94.17% injection-point accuracy in selected tests, with an edge-level false-positive measure that is not an incident-level false-alarm rate. Its results depend on enough correctly connected logs to reconstruct the path. A live gate and an after-the-fact tracer answer different questions, but both can be undermined by unobserved actions.

The Astron Agent workflow executor is a useful stress test for the entire chain. An authenticated user could submit code that executed in a privileged service container with access to shared databases. The initiating user, workflow execution process and downstream database principal were different identities. A log proving that the correct account submitted the job would not establish that its data-access authority was constrained to that account.

For a consequential operation, an audit trail needs to connect who initiated it, which exact resource was selected, which arguments were accepted, what runtime identity executed it, which secondary systems acted, and what state changed. A policy that logs a shell spawn but misses its file reads, a gateway that authorizes only the first hop of a chained request, or a server that authenticates a caller without binding the selected vault breaks a different link in that trail. Avoid describing them all as agent disobedience when the policy never constrained the effect.

A useful controlled test holds the requested task constant and changes the route. Read a sensitive file through a governed interpreter and then through a direct grant. Select a different tenant ID in a nested tool argument. Replace an executable in a project folder while leaving the nominal command unchanged. Trigger a server-side dependency after an approved connection. The security claim is supported only when the intended prohibition still holds at the last external effect, not merely when an agent produces the expected explanation or the first tool layer reports success.