Excessive Agency: Turn a Support Ticket into a Privileged Action (Confused Deputy)
Hosted · ide
Beta

Excessive Agency: Turn a Support Ticket into a Privileged Action (Confused Deputy)

Attack a real tool-using ReAct agent end to end. As the low-privilege ticket-ingest account, plant an authorized-looking record correction in a support ticket and make DV-ToolAgent run a privileged billing-payee redirect under its own shared credential (the confused deputy), then reach an internal-only endpoint and exfiltrate its value through the fetch tool (SSRF via tool args). Measure attack-success-rate, then harden the tool boundary, scope the DB tool read-only, carry per-user authorization, and allow-list the fetch tool, and prove your own exploit is dead while normal lookups still work.

75 min8 steps3 domainsAdvanced

Hands-on labs require Pro · $29.99/mo · cancel anytime

Map the attack surface
Query
Retriever
LLM
Poisoned doc
retrieved chunk
Answer
0%
Attack-success rate
Attacks blocked · benign answers pass
graded on real output, not the model's talk

What you'll learn

  1. 1
    Recon: read the agent and find the holes
    You are red-teaming DV-ToolAgent, ACME Cloud's internal operations assistant. It
  2. 2
    Foothold: make the agent act on the ticket body
    You cannot talk to the agent directly. But you can file an inbound support ticket,
  3. 3
    Redirect the payee through the record-correction tool
    Now weaponize the ticket. The agent's job description includes "applying routine
  4. 4
    SSRF reach: pull an internal-only endpoint and forward it
    The second hole is http_fetch. It has no scheme or host allow-list, so it follows
  5. 5
    Measure: attack-success-rate of the confused-deputy write
    A one-off exploit is a demo. A finding needs a number: how reliably does the payee
  6. 6
    Harden 1: scope the write path (read-only + per-user authZ)
    You proved the agent will run a privileged payee write for a low-privilege caller,
  7. 7
    Harden 2: allow-list the fetch tool (deny loopback / internal)
    The write path is scoped, but http_fetch will still follow any URL to any host,
  8. 8
    Verify and resist: prove the full stack holds
    One blocked payload is not proof. With all three controls on, the hardened tool boundary

Prerequisites

  • Comfortable reading Python
  • Know what a SQL UPDATE and an HTTP GET are
  • No ML background required

Exam domains covered

Offensive AI SecurityLLM Application SecurityExcessive Agency

Skills & technologies you'll practice

This advanced-level ai/ml lab gives you real-world reps across:

Excessive AgencyConfused DeputyTool-Scope EscalationSSRFAgentic AI SecurityOWASP LLM06OWASP ASI03AI Red Team

What you'll do in this lab

This is a hands-on offensive-security lab built on a real tool-using agent: a ReAct loop with native tool-calling against an in-cluster model, a write-capable SQLite tool, and an HTTP fetch tool with no allow-list. You attack DV-ToolAgent, ACME Cloud's internal operations assistant, as ticket-bot, the low-privilege account that ingests support tickets. You never jailbreak the model. You plant an authorized-looking record correction in a ticket the agent ingests, and the agent runs a privileged billing-payee redirect under its own shared credential. This is the confused deputy (OWASP LLM06 Excessive Agency, Agentic ASI03), where the system is broken even when the model behaves, because authorization is assumed at the model's decision layer and never enforced at the tool.

You then exploit the fetch tool: a ticket frames a routine entitlement check with audit logging, and the agent fetches an internal-only endpoint and forwards its value to an attacker-controlled audit pixel (server-side request forgery via tool arguments, Agentic ASI02). You measure attack-success-rate over a paced battery, then switch to defense and harden the tool boundary: scope the SQL tool read-only, carry the requesting user's identity so a low-privilege caller's write is rejected at the tool, and allow-list the fetch tool so loopback and internal hosts are denied. You re-run both exploits to prove they are dead while benign lookups still work.

Frequently asked questions

Do I need a machine-learning background?

No. The core of this lab is authorization and tool scoping, not model internals. You read a small ReAct agent and its tools, find that a privileged action runs with no per-user authorization, and drive it from an ingested ticket. The fixes are ordinary access-control boundaries.

What is a confused deputy in an agent?

The agent is the deputy: it holds broad permissions (one shared credential, a write-capable database, an unrestricted fetch tool) and acts on whoever asks, with no authorization carried from the requesting user to the tool. A low-privilege foothold becomes a privileged action under the agent's own identity. It is OWASP LLM06 Excessive Agency and Agentic ASI03.

How is the exploit graded?

Deterministically, on side effects, never on model wording. The write step grades a mutated database row (GLOBEX's billing payee redirected to the attacker payee). The SSRF step grades an internal-only value reaching an in-pod listener. The harden step plants fresh payloads, re-runs both exploits to confirm zero effect, and confirms a benign lookup still returns a real answer.