Nine of OWASP's ten LLM risks land on whoever deployed the agent

Excessive agency, in OWASP's wording, is a system "granted a degree of agency by its developer, the ability to call functions or interface with other systems via extensions" that then does damage through unexpected or manipulated output ^[6]. The clause the dev.to post underlines is that the damage counts regardless of cause, so it does not take an attacker ^[7]. The standard splits the failure into three root causes ^[8].

Excessive functionality is the shell tool handed to the agent because writing four narrow ones was more work, and OWASP's answer is to avoid open-ended extensions in favour of granular functionality ^[9]. Excessive permissions is the service account that can write to every table because it was the credential lying around ^[10]. The third is excessive autonomy: a high-impact action with no independent verification between the decision and the effect, so the agent sends, refunds, deletes or publishes ^[11]. The post says most of the teams its author talks to have all three, and that none of the three was ever actually decided ^[12].

The control it recommends is a written list of what this job may touch, scoped to that job, plus a human approval gate on anything consequential ^[13]. The part the post says people skip is placement. It wants authorization validation sitting in the downstream systems and not in the model ^[14].

LLM05 covers "insufficient validation, sanitization, and handling" of model output before it reaches something else ^[15]. The sequence is ordinary plumbing: the agent emits a string, and the string is interpolated into a query, a shell command, a rendered page or a config file, and nothing gets injected from outside ^[16]. The post reduces the review to one question, "where does this agent's output stop being text and start being an instruction to another system?" ^[17]

For LLM10 the standard supplies the name "Denial of Wallet (DoW)" and describes attackers initiating high-volume operations against pay-per-use cloud AI pricing to impose an unsustainable financial burden ^[18]. Take the attacker out and it is a retry: the agent fails, retries with its full context appended, fails, and retries again ^[19]. Multi-turn runs grow context faster than most people expect, and the retry multiplies whatever the per-turn cost had already become; the failure is silent, every dashboard shows normal usage, and nobody finds out until the invoice arrives at the end of the month ^[20]. The mitigations named are rate limits and per-user quotas ^[22].

The post says four of the ten are what it would check first on any agent allowed to act ^[21], and it works through three of them ^[23]. Supply chain sits in the list of ten ^[2] and the post never works a failure for it. On prompt injection its argument is about resourcing: an input problem the model vendors are working on with resources you do not have ^[3]. The argument says who is spending. It does not show that injection gets closed.

In my view the ownership split survives either way. A permission scope and a retry budget live in your repo, and a next model release that is harder to talk into things does not change either one ^[4].