BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//cfp.bsidescbr.com.au//bsides-canberra-2026//speaker//R8
 PGFR
BEGIN:VTIMEZONE
TZID:Australia/Sydney
BEGIN:STANDARD
DTSTART:20250924T000000
TZNAME:AEST
TZOFFSETFROM:+1000
TZOFFSETTO:+1000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20251005T030000
RDATE:20261004T030000
TZNAME:AEDT
TZOFFSETFROM:+1000
TZOFFSETTO:+1100
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:20260405T030000
RDATE:20270404T030000
TZNAME:AEST
TZOFFSETFROM:+1100
TZOFFSETTO:+1000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
SUMMARY:Testing Second-Order Prompt Injection Across AI Agent Deployments 
 - Gaurav Vikash
DTSTART;TZID=Australia/Sydney:20260924T100000
DTEND;TZID=Australia/Sydney:20260924T105500
DTSTAMP:20260807T131713Z
UID:pretalx-bsides-canberra-2026-NRAAFR@cfp.bsidescbr.com.au
DESCRIPTION:Direct prompt injection is well understood. An attacker contro
 ls the input\, inserts a payload\, and the model executes it. Second-order
  injection works differently. The malicious payload does not come from the
  user. It is embedded in external content that the agent retrieves and pro
 cesses autonomously during task execution. The agent reads a document\, vi
 sits a URL\, or queries a tool\, and the payload arrives through that chan
 nel. \n\nBreach disclosures in 2025 confirmed that deployed AI agent syste
 ms are susceptible to injection through retrieved data. The question is no
 t whether the vulnerability class exists. It is how widely it applies acro
 ss the AI agent architectures organisations are currently deploying.\n\nI 
 tested three common deployment classes: local agents with MCP tooling\, br
 owser-based web agents\, and document-processing pipelines. For each\, I e
 xamine whether injection payloads embedded in retrieved content are treate
 d with the same trust as developer-authored instructions. I test whether p
 ublished prompt injection guidance from platform providers addresses retri
 eval-path injection specifically\, or whether documented mitigations are s
 coped to direct user input only. From these results I characterise a trust
 -equivalence condition: the structural property that determines whether a 
 given deployment architecture is susceptible to second-order delivery.\n\n
 This talk presents the testing methodology\, with demonstrations across ea
 ch deployment class\, a summary of outcomes across all three\, and a pract
 ical framework for identifying trust-equivalence conditions in AI agent ar
 chitectures before deployment.\n\n**Key Takeaways**\n\n1. Second-order inj
 ection is architecturally distinct from direct injection. The payload arri
 ves through content the agent retrieves\, not through user input\, and def
 ences scoped to user input do not address it.\n2. The trust-equivalence co
 ndition\, whether retrieved content is treated with the same trust as deve
 loper-authored instructions\, is the structural property that determines s
 usceptibility. It is identifiable before deployment without running an att
 ack.\n3. MCP-connected local agents expose an explicit retrieval pathway t
 hrough tool outputs. When tool responses are not sandboxed from instructio
 n-following context\, they become a reliable injection vector.\n4. Browser
 -based web agents that process arbitrary page content inherit the injectio
 n surface of every site they visit. This attack surface is not consistentl
 y addressed in published platform guidance.\n5. Document-processing pipeli
 nes are susceptible regardless of model-level instruction following when r
 etrieved content is passed directly into agent context without sanitisatio
 n. The vulnerability is architectural\, not a model capability gap.\n6. Ev
 ery test in this talk is reproducible using publicly available AI tools an
 d documented methodology\, making it a starting point for practitioners as
 sessing their own agent deployments.
LOCATION:Off-Main Track
URL:https://cfp.bsidescbr.com.au/bsides-canberra-2026/talk/NRAAFR/
END:VEVENT
END:VCALENDAR