A fuzzer has no opinion about your product. It doesn’t know what a user “would” do. It just tries every input the system accepts, including the ones nobody designed for, until something breaks.
That’s the best description I’ve found for how an AI agent behaves inside a transactional flow.
Any multi-step flow — search, select, fill in details, confirm, pay — has a state space much larger than the path the business had in mind. Retries out of order. Partial completions. Combinations nobody wrote a test for. That space always existed. It stayed empty because a human got bored, got confused, or just never thought to try it.
An agent doesn’t get bored. It has no social sense that a path is “not meant for it.” It just keeps going until it finds a state the system accepts.
This is not the same question security asks. Security asks what a hostile actor can do, and measures the answer in damage. Nothing here is hostile. The agent isn’t trying to break your flow — it’s indifferent to whether the path was intended. A perfectly secure system can still hand an indifferent actor a result nobody signed off on.
Worse than a bug: when the agent finds one of those paths, it usually succeeds. Not a crash, not an error. A completed transaction the system permitted and nobody authorized, indistinguishable in your logs from a normal one.
The rule that used to hold — nobody will do that, nobody would think of it — was never written into any requirement. It was a guess about human psychology, quietly doing the job of a spec.
Product and engineering don’t have a discipline for this yet, because until now the actor exercising the happy path also happened to be the one who stayed on it.
If you want to know what your system actually allows, stop asking whether the tests pass. Ask what happens when something tries everything.