Research seriesL3paper
We can no longer trace what a frontier model does back to a line of code, yet we hand models sensitive data and the power to act. One answer is to treat every capable model the way security already treats a powerful insider: not as malicious, but as an actor that can err or be compromised. This series tests that idea mechanism by mechanism. It asks which insider-risk controls still work when the insider can be copied and cannot be deterred, when a second model is genuinely an independent check, how control protocols keep outcomes safe even against a model working against us, what an emergency brake must guarantee mid-task, what to disclose when an incident has no code path, and how containment should scale as capability grows. Vendor-neutral and grounded in primary security, safety and incident-reporting literature.
Decades of insider-risk practice assume a human. Tested control by control against how models really behave, some controls hold, some change meaning, and some fail outright.
Adding a different model as a checker feels like redundancy. Forty years of fault-tolerance research and new evidence on language models say it often is not, unless it is designed to be.
If a model might be working against its safeguards, the safeguards have to be evaluated as if it is. AI control turns that stance into protocols, budgets and red-team games.
Being able to pause or stop an AI agent mid-task sounds simple. Making the stop impossible to route around, and safe for half-finished work, is an engineering problem in its own right.
Software incidents are disclosed against a version and a line of code. When the failure lives in a model's behaviour, its configuration or its context, disclosure needs a different record.
More capable models need stronger containment, but how much stronger, and of what kind? A capability-by-authority matrix turns that intuition into a build decision.