What it actually took

What it actually took

Worth being concrete about effort, because the abstract version of this work sounds larger than it is.

Under 1,200 lines of unremarkable C#. In every row the code was the small part and the decisions were the large one.

That pattern is worth expecting. The gate is three hundred lines and a fortnight, because the fortnight is spent getting a team to agree which actions cannot be undone. The capability issuer is straightforward and the list of operations per task type does not exist anywhere and has to be written by someone who understands the product.

If a plan for this work budgets engineering days and no decision days, it is wrong in a way that will show up in week three.

The order matters more than the total

Ship these in the wrong order and you will spend months before anything improves.

Egress first, because it is independent of everything else and stops the most published attacks. Provenance second, because the gate cannot ask its most useful question without it. The gate third. Capability fourth, since the gate works with a coarse capability model and gets better with a fine one. Quarantine last, because it is the most invasive and the least urgent once a gate is standing.

A team that starts with quarantine, which is the intellectually interesting one, will spend six weeks on schemas while the exfiltration leg stays open.

Where this leaves you

An agent that can be injected, will be injected, and cannot do much about it.

That is the outcome. Not an agent that resists attack, because chapter 4 established you cannot buy that. An agent whose compromise is uninteresting, because the authority to do damage was never sitting where the compromise happens.

The work was ordinary. Type wrappers, a policy engine, scoped tokens, a renderer, an approval screen, some tests. No research, no novel cryptography, nothing that did not exist in 1990. The difficulty was never technical. It was that the industry spent three years asking how to make the model trustworthy, and the answer was to stop needing it to be.

Running this well is ongoing work rather than a project that finishes. The policies drift, the tool register goes stale, the allowlist needs maintaining, and the test corpus grows with each engagement. That is the shape of the commitment, and it is the same shape as the rest of your production surface.

If you would rather have someone build and maintain this alongside your team, that is what You Source does through Dev on Demand: senior engineers delivering task-based work, starting with a Proof of Quality, which is one real task delivered and evaluated before any subscription. The architecture in this book is not proprietary and you do not need us to implement it. The offer is the maintenance.

Chapter 20 is about what none of this fixes.

Sources for this chapter

Every attack in the "where each attack dies" section is a construction against the reference agent in this book, not a report of a live system, and the outcomes describe what the architecture is designed to do rather than measured results. No claim is made that these seven attacks are representative of what an adversary will try, and chapter 20 addresses what the design does not cover. The checklist ordering is the author's judgement about effort versus reduction, not a measured ranking.