Tool permissions set the maximum harm a hijacked security agent can do

In the post's playbook code, `if alert.severity == "critical":` calls `isolate_endpoint(alert.host)` and opens a P1 ticket. A `high` alert gets a P2 ticket, and everything else goes to `log_for_review` ^[8]. The function has three paths ^[2]. An engineer wrote the branches and a reviewer approved them ^[19]. The only input that picks a branch is `alert.severity`.

The agent replaces that `if` with a loop. It observes, reasons, chooses a tool, executes, observes the result and reasons again, repeating "until the model decides it's done" ^[9]. Given the same integrations, the post lists eight actions the agent might take, including disabling the user account and isolating one or more endpoints. None of them is pre-sequenced ^[10]. If each of the eight runs exactly once, there are 40,320 possible orders ^[1]. The loop can also call a tool more than once, so a reviewer would have even more sequences to cover.

The post's SOC example gives the agent one instruction: "Investigate this suspicious endpoint and contain it if necessary" ^[7]. No change board would accept that sentence as a spec, yet the agent then decides whether "contain" means isolating a host, disabling an account, or both ^[7].

In the playbook, the value that chooses the next action is `alert.severity`. In the agent, the reasoning step makes the choice. That step reads whatever telemetry the agent pulled ^[9]. If an attacker wrote any of that text, it feeds the step that picks the next tool. "Prompt injection stops producing bad text and starts producing bad actions," the author wrote ^[4]. According to the post, every tool the agent can reach is something an attacker might steer it into using ^[17].

Anthropic's "Building effective agents", published in December 2024, draws the same line ^[11]. It calls workflows "systems where LLMs and tools are orchestrated through predefined code paths" ^[11]. It calls agents "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks" ^[11].

In that loop, the deterministic layer belongs between choosing a tool and executing it ^[6][9]. The model's tool call becomes a request, and code decides whether it runs. I think this is the right design, and OWASP's definition of Excessive Agency shows why. OWASP calls it the vulnerability "that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction" ^[14]. A check at the execution boundary does not need to know whether the model was injected or just wrong. It needs the requested tool, its arguments and the identity the call would run as.

For review, the post proposes one question: "What is the maximum harm this agent can cause if its reasoning is manipulated, incorrect, or compromised?" Its answer is that the agent's tools and permissions set that number ^[12]. OWASP's 2025 entry gives the root cause as "typically one or more of: excessive functionality; excessive permissions; excessive autonomy" ^[15]. Its first mitigation reads "Limit the extensions that LLM agents are allowed to call to only the minimum necessary" ^[16]. Each of those three causes corresponds to a setting outside the model: the tool list, the grant behind each tool, and the set of calls that need a human approval ^[15].

The argument is one author's, built on published guidance. The available text of the post ends before the author sets out an implementation of the control plane ^[20].