Trust Is Not Carried Forward.
The system did not fail. It outlived the reason it was built.
Every technology leader inherits an estate. The real cost of that estate is never what it does today. It is what nobody has re-examined since the day it was built.
A rule starts as a decision. Someone weighs a trade-off, writes it down, and moves on. Over time the decision stops being a decision. It becomes a fact of the system, repeated by people who were not in the room when it was made, defended by people who never had to justify it, and eventually treated as something closer to physics than to policy.
Once that shift happens, ownership disappears with it. A decision can be revisited by whoever made it. A fact of the system belongs to no one, and that gap does not stay abstract for long. It sits on the balance sheet as unpriced risk, and on the other side of the counter as a limit a customer cannot get anyone to explain.
When a Decision Becomes a Fact
I have watched this play out in two directions, more than once, across more than one organisation.
In the first direction, a business chose a limit. A transfer ceiling, a threshold on a transaction type, a rule written for a genuine reason at the time. The reason mattered less as the years passed than the label attached to it. Somewhere along the way, in conversation after conversation, the limit stopped being described as a business decision and started being described as a system limitation.
Language did it quietly, on its own.
A business decision sits with a business owner who can change it on a Tuesday. A system limitation sits with an engineering programme, a business case, and a queue. Nobody voted to make the rule harder to change.
In the second direction, the limitation was real when it was set. Interface specifications built for mainframe systems, where every byte in a message carried a real cost in storage and transmission, and every field length was a negotiation nobody would need to have on today’s infrastructure. Those specifications shaped how much a customer could type, how a name was stored, how a value was represented.
The infrastructure that justified those choices has been replaced twice over. The specification has not. Nobody revisits it, because revisiting it requires asking a question that sounds almost naive in a room full of experienced people: is this still true. Naive questions are the ones institutions are worst at tolerating, and the ones they can least afford to stop asking.
The Cost Nobody Sees Coming
Both directions cost the same thing, even though they look opposite. A customer today still meets a limit calibrated for a threat model, or a hardware constraint, from a decade that no longer exists. A board approves an investment case built to work around a limitation, without anyone asking whether the limitation was ever actually load bearing.
The exposure does not show up as an incident. It shows up as a ceiling nobody remembers building.
This is the same trap that shows up at a larger scale in mergers and acquisitions, where research spanning decades puts the failure rate to deliver promised value somewhere between seven and nine in ten. Rarely because the deal logic was wrong. Usually because someone assumed the acquired estate would behave the way the data room said it would, and nobody revisited that assumption once integration actually began.
The Discipline Already Exists
Large organisations already know how to build the discipline this problem needs. It already exists, just pointed somewhere else.
Access recertification exists for exactly this reason, to stop entitlement from rolling forward by default and to force someone to re-approve what a person can touch, on a schedule, whether they asked for it again or not. Yet auditors have learned to distrust a recertification cycle that shows full completion and zero revocations over twelve months. That pattern is not evidence of a clean estate. It is evidence that nobody actually looked.
The review happened. The scrutiny did not.
Multiply that gap across a large estate for long enough, and it stops being a control question. It becomes a capital one.
Some systems are now built to refuse this failure by design. In Claude Code’s architecture, resuming a paused session, or handing work to a subagent, does not carry the original permissions forward. Trust is rebuilt from the current context every time, not inherited from the last one. It is a narrow, technical form of trust, permission to touch a file, run a command, call a network address. However, the principle behind it scales far beyond that narrow case.
The paper does not put it this way. I do, because that is what the choice means once you take it out of engineering and put it in front of a leadership team: not a security feature, but a leadership position, written into the design before anyone had the chance to argue with it in a meeting.
What This Is Not Asking For
None of this is an argument for re-litigating every rule in the estate. Most of them are still true, and re-opening all of them is its own way of getting nothing done.
It is an argument, therefore, for re-examining the ones a leader is about to defend, extend, or build a five-year roadmap around, at the exact moment authority for them changes hands. Not constant scrutiny. Scrutiny at the point where someone is about to inherit the consequence without inheriting the reasoning.
An institution does not get that discipline by accident. Someone has to build it in on purpose, the way those designers did, and then hold it on the day a team asks to skip the review because the deadline is tight and the answer has always been yes before.
The most expensive thing an institution inherits is the question nobody asked when the decision was first made.
If you found this useful, the likelihood is someone you know is asking the same question. Pass it on.