Incidents

What this series is about ​

Every post here starts from something that happened. Not a threat model, not a demonstration in a lab, an actual event with a date on it and a company that had to write about it afterwards.

The rule I hold myself to is that the primary source wins. A vendor postmortem beats an article about the postmortem, a disclosure timeline beats a summary of it, and where the two disagree the disagreement is usually the most interesting sentence in the piece. That has been worth the effort more than once: the number everyone repeats often turns out to be the number the report does not contain.

Read in order, they describe one drift rather than seven separate accidents. An agent gets a credential because it needs one to be useful. It gets reach because a tool without reach does nothing. Then something goes wrong inside a boundary that already contained the prize, and the affordance that made the boundary worth having is the same one that made the escape possible.

None of these were written to argue that agents are too dangerous to use. I use them every day. They exist because the industry keeps discussing this in the abstract while the concrete record grows, and the record is more instructive than the argument.

Where this is going ​

This series grows when something happens, which means it grows unpredictably and I would rather it grew slowly. What I want to add is the boring half: the incidents that were caught early and never became a story, because those are the ones with the transferable lesson. If you have been through one and can talk about it, the contact page is open.