Goal hijacking is the better name because it points to the failure that matters: untrusted text changes what the agent tries to do. Once tools are involved, prompt filtering is not enough. The runtime has to separate content the system may read from instructions it is authorised to act on.
Great comment Peter, this gets at the heart of it. The taxonomy separates intent from technique precisely because the naming problem you raise comes from conflating them: "goal hijacking" describes the intent/outcome (untrusted text redirecting what the agent tries to do), while things like instruction smuggling or payload splitting are just the techniques that get you there. Different techniques, same failure.
And I'm with you completely on defense. Prompt filtering is a probabilistic control - useful for reducing surface area, but it can't be the last line once the model can call tools. The real requirement is a runtime that treats retrieved/observed content as data by default and only acts on trusted instructions. Getting that separation right at the runtime level, rather than leaning on filtering, is the shift that actually matters. Thanks for engaging.
I like the split between intent and technique. It stops the taxonomy becoming a catalogue of different payload shapes. Within the outcome side, I would distinguish content that changes an answer from content that crosses a tool boundary and changes external state. Filtering can reduce exposure, but authorisation and containment decide the blast radius. How do you represent a multi-step attack where the technique changes across turns but the hijacked goal stays constant?
Goal hijacking is the better name because it points to the failure that matters: untrusted text changes what the agent tries to do. Once tools are involved, prompt filtering is not enough. The runtime has to separate content the system may read from instructions it is authorised to act on.
Great comment Peter, this gets at the heart of it. The taxonomy separates intent from technique precisely because the naming problem you raise comes from conflating them: "goal hijacking" describes the intent/outcome (untrusted text redirecting what the agent tries to do), while things like instruction smuggling or payload splitting are just the techniques that get you there. Different techniques, same failure.
And I'm with you completely on defense. Prompt filtering is a probabilistic control - useful for reducing surface area, but it can't be the last line once the model can call tools. The real requirement is a runtime that treats retrieved/observed content as data by default and only acts on trusted instructions. Getting that separation right at the runtime level, rather than leaning on filtering, is the shift that actually matters. Thanks for engaging.
I like the split between intent and technique. It stops the taxonomy becoming a catalogue of different payload shapes. Within the outcome side, I would distinguish content that changes an answer from content that crosses a tool boundary and changes external state. Filtering can reduce exposure, but authorisation and containment decide the blast radius. How do you represent a multi-step attack where the technique changes across turns but the hijacked goal stays constant?