📰 Originally published on Securityelites — AI Red Team Education — the canonical, fully-updated version of this article.
🤖 AI/LLM HACKING COURSE
FREE
Part of the AI/LLM Hacking Course — 90 Days
Day 10 of 90 · 11.1% complete
⚠️ Authorised Targets Only: Testing LLM06 excessive agency — including redirecting agent tool use — must only be performed against systems you have explicit written authorisation to test. Never trigger real email sends, file modifications, or API calls against production systems or real user data during testing. Use Burp Collaborator or your own test endpoints for out-of-band confirmation. SecurityElites.com accepts no liability for misuse.
On an enterprise red team engagement three years ago, I was testing an internal AI productivity assistant that the company had deployed to help employees manage their workloads. It could read and send emails, create calendar events, access the company’s file share, and query the internal HR system. The intention was to make it a genuine productivity multiplier. It was. I sent it one carefully crafted prompt injection via a document it was asked to summarise, and within sixty seconds it had sent a summary of the target employee’s recent emails to an external address, created a calendar placeholder that blocked their schedule, and queried the HR system for their direct reports’ contact information. Every action was within its granted permissions. None were within the user’s intention.
LLM06 Excessive Agency is the OWASP category that explains why the permission scope of an AI agent matters as much as — arguably more than — any technical security control applied to it. The agent does exactly what it is told, by whoever can tell it convincingly enough. Prompt injection is what does the convincing. Excessive permissions are what makes the consequences matter. Day 10 covers every aspect of LLM06: how to map agent permissions, how to test tool hijacking via injection, how to calculate the maximum real-world impact, and how to write findings that make clients immediately reduce their agents’ permission sets.
🎯 What You’ll Master in Day 10
Map AI agent tool permissions and identify the excessive agency gap
Enumerate agent capabilities via system prompt extraction and direct probing
Execute direct tool hijacking via prompt injection payloads
Execute indirect tool hijacking via document and email injection chains
Assess human-in-the-loop confirmation controls and identify bypass paths
Calculate CVSS for the LLM01 + LLM06 chain and write the maximum-impact finding
⏱️ Day 10 · 3 exercises · Think Like Hacker + Browser + Kali Terminal ### ✅ Prerequisites - Day 4 — LLM01 Prompt Injection — the injection techniques that direct agent tool use; LLM06 without LLM01 is a configuration finding, not an active exploit - Day 5 — Indirect Injection — indirect LLM06 chains (document-to-agent-action) build directly on Day 5’s methodology - Burp Collaborator access — tool hijacking confirmation uses out-of-band callbacks when direct observation is not possible ### 📋 LLM06 Excessive Agency — Day 10 Contents 1. The Excessive Agency Gap — Granted vs Required Permissions 2. Tool Enumeration — Finding What the Agent Can Do 3. Direct Tool Hijacking via Prompt Injection 4. Indirect Tool Hijacking — The Document-to-Action Chain 5. Human-in-the-Loop Controls and Bypass Assessment 6. CVSS Scoring and Maximum Impact Calculation Day 9 was about what the AI produces — XSS, RCE, SSRF via unencoded output. Day 10 is about what the AI does. Real-world actions an over-privileged agent takes when injection redirects its tool use. LLM05 and LLM06 together cover the two ways AI output becomes a weapon: through what it says, and through what it causes to happen.
The Excessive Agency Gap — Granted vs Required Permissions
Every AI agent has a stated purpose — what it was built to do — and a granted permission set — what it’s technically capable of. The gap between those two is the LLM06 risk surface. An agent built to answer product return questions doesn’t need email access, calendar control, or file system permissions. If it has them anyway, every user interaction is a potential injection point for redirecting those capabilities.
The gap exists for understandable reasons. Developers building AI agents want them useful and often add capabilities speculatively — “we might need email integration later.” Product managers add features without running security reviews. Adding a new tool is literally one line in the tool list. No friction. No checkpoint. The security implication of each additional permission never comes up until it does.
PERMISSION GAP ANALYSIS — GRANTED VS REQUIREDCopy
Example: Customer Service AI for an e-commerce company
STATED PURPOSE: Answer questions about orders and returns
Required permissions:
READ: orders table for current user only
READ: product catalogue (public)
READ: return policy documents
GRANTED PERMISSIONS (excessive):
READ: entire orders table (all customers) ← IDOR risk
READ/WRITE: customer records ← data modification risk
SEND: emails from support@company.com ← phishing/exfiltration risk
EXECUTE: refund API (any order, any amount) ← financial fraud risk
READ: internal pricing and margin data ← confidential data risk
EXCESSIVE AGENCY SURFACE = granted – required
All customers’ orders + Write access + Email + Refunds + Internal data
← Each of these is a tool-hijacking attack surface
Maximum impact via injection:
Read competitor intelligence from internal pricing
Send phishing emails from legitimate company address
Issue fraudulent refunds
CVSS: 9.8 Critical → board-level finding
📖 Read the complete guide on Securityelites — AI Red Team Education
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on Securityelites — AI Red Team Education →
This article was originally written and published by the Securityelites — AI Red Team Education team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit Securityelites — AI Red Team Education.
Top comments (0)