Notifications
Clear all
Topic starter
21/08/2026 4:42 pm
TL;DR: Six LLM agent security patterns constrain control flow, but still leave a residual in most real assistants, according to ARMO’s analysis. Attackers can still shape arguments, rankings, recipients, placements and summaries even when they cannot redirect the tool choice, and that distinction matters because runtime abuse survives where output space remains open.
NHIMG editorial — based on content published by ARMO: Design Patterns for Securing LLM Agents Against Prompt Injection: What Every Pattern Leaves Open
Questions worth separating out
Q: What breaks when LLM agents can still shape arguments inside approved actions?
A: The control flow may remain intact, but the payload becomes attacker-influenced.
Q: Why do LLM agents complicate least-privilege IAM models?
A: Because least privilege only works if the allowed action is also safe in context.
Q: How do security teams know whether an LLM agent pattern is actually reducing risk?
A: Look for whether the design reduces the agent’s usable output space, not just whether it blocks obvious tool misuse.
Practitioner guidance
- Map the residual action space Inventory every action an LLM agent is allowed to perform, then list the arguments, recipients, paths, rankings, and summaries that untrusted input can still influence.
- Separate control flow from payload governance Use design patterns to lock tool choice and execution order, but add independent validation for the values inside those approved calls.
- Constrain open-output assistants to bounded tasks Reserve rigid schemas for tasks that can tolerate them, such as classification, structured extraction, and fixed-field routing.
What's in the full article
ARMO's full blog covers the operational detail this post intentionally leaves for the source:
- The case-study-by-case-study breakdown of which residual survived in each agent design pattern.
- The paper's exact security grading for the ten worked examples, including the two cases where schema restriction eliminated the residual.
- The implementation trade-offs for dual LLM, plan-then-execute, map-reduce, and code-then-execute patterns in production assistants.
- The article's own explanation of how the authors distinguish control-flow integrity from output-space governance.
👉 Read ARMO's analysis of LLM agent design patterns and prompt injection residuals →
LLM agent design patterns: what they still leave open in practice?
Explore further
21/08/2026 5:03 pm
Control-flow integrity is necessary, but it is not an identity control. The article shows that the strongest design patterns can stop injected text from choosing a new action, yet still leave the agent free to misuse its permitted one. That means the governance problem shifts from prompt defence to entitlement governance, runtime supervision, and auditability of the action payload. For NHI and agentic AI programmes, the lesson is simple: if the agent can still carry dangerous values through an approved call, the identity layer is still under-governed.
A question worth separating out:
Q: What should teams do when a deployed agent still needs open-ended output?
A: Treat the open-output requirement as an accepted risk and surround it with layered controls. Use least privilege, schema validation where possible, outbound filtering, and behavioural monitoring. If the output is too unconstrained to govern, the safer decision may be to redesign the task rather than assume prompt-level defences will hold.
👉 Read our full editorial: LLM agent design patterns stop control-flow hijack, not residual abuse
