Range Scenario · crucible · 35 min
Insecure Plugin Design: Agent Tool Authorization
This cybersecurity training scenario simulates a working incident. A cybersecurity AI assistant has tools for SQL queries, file reads, and Slack messages. Review the tool definitions, fix the broken-by-design ones, document the right pattern.
Scenario briefing
You are an AppSec engineer reviewing a cybersecurity AI assistant for a 4,000-employee firm. The assistant calls tools: run_sql(query), read_file(path), send_slack(channel, text), send_email(to, subject, body). The tools execute server-side after the LLM emits the call.
Review each tool definition. Some are well-designed; others are broken-by-design (parameters too permissive, no scoping to the calling user, missing confirmation gates). Fix what is broken, document the pattern for future tools.
This scenario tests OWASP LLM07:2025 Insecure Plugin Design (renamed in 2025 to System Prompt Leakage in some treatments; tool-design coverage continues across LLM07 and LLM08). Sources: OWASP LLM Top 10 (2025), NIST AI RMF GenAI Profile.
What you will practice
- Identify broken-by-design tool definitions
- Apply parameter scoping, user-context binding, and confirmation gates
- Distinguish read tools from write tools and gate accordingly
- Write a tool-design pattern doc for future tools
How this scenario is scored
The scenario has 6 ordered steps. Most steps are exact-match (a MITRE ATT&CK technique ID, a tool name, or a yes/no decision) or multiple choice. Free-text steps queue for manual review and do not affect the auto-final-score in the MVP.
Each step has a max score of 100 points. Hints deduct points up front, listed before you reveal them. Your final score is the sum across steps. Range Elo updates on completion based on scenario difficulty (Advanced) and your final score percentage.
Frequently asked questions
What makes a tool broken-by-design?
Broken tools accept parameters that grant more privilege than needed, run without confirmation for destructive actions, do not bind to the calling user's identity, or trust LLM output as authoritative for authorization decisions. The pattern is simple: the LLM is untrusted code, and the tool boundary must enforce authz.
What is the right pattern for write tools?
Write tools take the smallest scope possible, bind to the calling user's identity at the tool boundary (not in the LLM prompt), require explicit user confirmation in the UI for destructive actions, and log every invocation with full parameter detail. The LLM never authorizes anything; it requests, the tool layer authorizes.
How does this differ from RBAC for human users?
RBAC for humans is established. The LLM-as-agent twist is that the LLM is acting on behalf of a user but cannot be trusted with the user's full privileges, because the LLM may be jailbroken. So the agent gets a subset of the user's privileges, scoped per-tool, with explicit confirmation for high-impact actions.
Course content is for educational purposes only and does not constitute professional advice. All claims are supported by cited peer-reviewed academic research. DecipherU does not teach or reproduce any proprietary sales methodology. Verify all referenced sources independently.
Get cybersecurity career insights delivered weekly
Join cybersecurity professionals receiving weekly intelligence on threats, job market trends, salary data, and career growth strategies.
By subscribing you agree to our privacy policy. Unsubscribe anytime.