Why agents break classic security assumptions

Everything in the previous track was designed for a world where code does what it was written to do. An agent breaks that assumption in a specific, identifiable way, and it is worth being precise about which parts break.

Traditional application security rests on four assumptions:

• Code and data are separable: the program is fixed, and input is something it processes.
• Control flow is determined by the program, not by its input.
• A component's privileges are exercised only by its own logic.
• Behaviour is reproducible, so testing tells you what production will do.

A SQL injection is the closest classic analogue, and the comparison is instructive because of where it breaks down. SQL injection is solved by parameterised queries: a hard boundary between code and data enforced by the parser. There is no equivalent for natural language. The model has no parser-level distinction between 'the developer's instruction' and 'text I was asked to summarise'.

• You cannot escape untrusted text into safety, because meaning is not syntax.
• You cannot enumerate malicious inputs, because the input space is all of language.
• You cannot rely on the model refusing, because refusal is itself probabilistic.

So the defence moves outward, into the surrounding architecture: what the agent can reach, what it can spend, what it can send, and what needs a human. Everything that follows is a variation on that idea.