Trust Is the New Infrastructure
Intelligence became software. Trust became the bottleneck. For most of history intelligence was scarce; artificial intelligence changes that equation, and the primary challenge of the next decade will not be capability — it will be trust. A thirty-year journey through military intelligence, silicon, banking, behavioural science and AI security, arguing that trust is emerging as a new infrastructure layer as fundamental to the autonomous age as identity was to the internet.

Intelligence Became Software. Trust Became the Bottleneck.
A Thirty-Year Journey Through Military Intelligence, Silicon, Banking, Behavioural Science, Artificial Intelligence and the Future of Autonomous Trust
Intelligence is becoming abundant. Trust is becoming scarce. Therefore trust becomes infrastructure.
A note on this revision: the argument, structure and voice below are yours. What’s been added is evidentiary scaffolding — current data, named frameworks, one very recent, very concrete case study that didn’t exist when the first draft was written, and a new section on SPECTRE, the adversarial instrument built to test SILO. Where a claim in the original was illustrative rather than documented (the Lime bike architecture, for instance), I’ve kept the illustration but flagged it as a model rather than a confirmed technical spec, so the paper’s credibility doesn’t rest on a detail nobody can verify. The SPECTRE material is drawn from internal architecture documentation rather than independently verified or peer-reviewed sources, and is footnoted accordingly — the same treatment given to the SILO material in Part VI. One more addition, this one unplanned: an anecdote about Tony Stark, JARVIS and vibe coding that started as a reply to a stranger on the internet and turned out, much to my own surprise, to contain the whole thesis in miniature. It now opens Part I, and the same line closes the Conclusion. Sources are linked inline and collected at the end.
Executive Summary
For most of human history, intelligence was scarce. Every organisation, government, military, institution and company was constrained by the availability of capable human minds.
Artificial intelligence changes this equation. For the first time in history, intelligence itself is becoming software.
This paper argues that the consequences of this transition are being profoundly underestimated. The primary challenge of the next decade will not be capability. It will be trust.
Put as plainly as I can put it: intelligence is becoming abundant. Trust is becoming scarce. Therefore trust becomes infrastructure. Everything that follows is really just that sentence, unpacked at length and checked against the evidence.
The organisations that thrive will not necessarily be those that build the most capable autonomous systems. They will be those that build the trust architectures that allow autonomy to scale safely.
Drawing on lessons from military intelligence, operating systems, silicon engineering, financial services, behavioural science, marketing technology, cloud computing, autonomous systems and AI security — and on a live regulatory episode from June 2026 that made the argument for me — this paper proposes that trust is emerging as a new infrastructure layer. A layer as fundamental to the autonomous age as identity was to the internet age.
Part I — The Engineer’s Curse
A Confession, By Way of Tony Stark
I ought to admit, before we go any further, that this paper did not begin its life in a boardroom, nor at a whiteboard thick with trust-architecture diagrams — though heaven knows there have been plenty of both over the years, usually accompanied by cold coffee and the particular optimism that arrives at eleven o’clock at night and rarely survives the morning. It began, rather more sheepishly, with an argument I had on the internet about a man who does not exist.

Someone had posted a photograph of Tony Stark in his workshop — all holographic schematics and casual, hip-swivelling authority, the sort of confidence usually reserved for orchestra conductors and people who have never once had a production deployment fail on a Friday afternoon — with the caption that Stark was, in fact, the world’s first vibe coder. He didn’t write the suit. He gestured at a problem, said something clever, and JARVIS simply understood him and got on with it.
I found I couldn’t disagree, and that bothered me rather more than agreeing would have done. Because it’s true, isn’t it? An enormous number of us now build things exactly this way — myself very much included. I have spent a great many years writing my own toolchain from the ground up, quite literally called AutoCode and CloudCode, precisely so that when I gesture at a problem the way Stark gestures at a hologram, something I actually understand — down to the concrete, not merely down to the API — is the thing doing the work. If you’d like to see that particular obsession laid out in public, the wider ecosystem it belongs to lives at justinjames.agencie.io — thirteen products and counting, all built on roughly the same premise as everything that follows in this paper.
So I wrote back. Not glibly — properly, the way you write something when you suspect, even as you’re typing it, that you might want to read it again later:
“Tony Stark was absolutely a vibe coder. The difference is that someone still had to build JARVIS. AI raises the level of abstraction, but it doesn’t eliminate engineering. Someone always has to make the tools that make the tools. Follow it far enough down and you’re back to code again. The keyboard may become optional; understanding systems won’t.”
I mention this not out of any great fondness for superhero mythology, but because it turns out to contain the entire argument of this paper, compressed into something you could fit on a napkin. Somebody, somewhere, always has to build JARVIS — and whoever that is has to understand not merely how to make a system capable, but how to make it trustworthy: how it behaves when nobody is watching, how it fails, and how you would ever know. Abstraction is wonderful. It is, in a very real sense, how civilisation has always progressed — nobody forges their own iron ore to build a laptop, and nobody should have to. But abstraction only ever moves the understanding somewhere else. It never deletes it. And when the thing being abstracted away is judgement, behaviour and trust, rather than arithmetic, moving it somewhere else stops being a convenience and starts being the whole ballgame.
That, in the end, is what the rest of this paper is really about. Not whether the tools get smarter — they plainly will, and on a curve that would have made yesterday’s engineers weep with either joy or terror, depending on the engineer — but who understands the machinery well enough to be trusted with the parts nobody else is watching. The keyboard, as I say, may well become optional. Understanding systems will not. If anything, it becomes the one scarce thing left standing when everything else is abundant.
Opening Every Black Box
Throughout my career I have suffered from what can only be described as an engineering compulsion. Whenever I encounter a black box, I feel compelled to open it. Occasionally literally. More often intellectually.
Military intelligence. Operating systems. Enterprise platforms. Silicon. Cloud computing. Fraud systems. Trading systems. Marketing platforms. Behavioural science. Artificial intelligence.
Every time I encountered a system I did not fully understand, I built one. Not because I intended to compete with it. Because I wanted to understand where the abstraction ended and reality began.
This habit eventually led me to train a small language model several years before generative AI became fashionable. Not because I foresaw the current explosion. Simply because I wanted to understand how intelligence could emerge from mathematics, data and computation.
The model itself was unremarkable. The lesson was profound. Once you build something from the ground up, the magic disappears. What remains is understanding. And understanding often reveals uncomfortable truths.
Part II — The Lime Bike Paradox
The Most Sophisticated Trust System Nobody Notices

Most people look at a shared e-bike and see a bicycle. This is understandable. Most people look at a Tesla and see a car. This is equally understandable. Both observations miss the architecture underneath.
A modern connected e-bike is best understood not primarily as a bicycle, but as a distributed system in miniature: a battery management unit, a motor controller, a cellular/BLE communications stack, a secure element or SIM-based identity, and a cloud backend, each of which has to establish that the others are who they claim to be before anything happens. This is the general pattern for connected IoT devices with a hardware root of trust: keys embedded in the silicon at manufacture, firmware verified against those keys before it’s allowed to run, and a cloud service that will only accept telemetry from a device it can cryptographically recognise.1
(I want to be precise here: I’m describing the class of architecture that shared-mobility and connected-vehicle fleets generally use, not a confirmed technical teardown of any specific vendor’s bike. The point stands regardless of the specific product — the object is a trust network with wheels, not a bicycle with an app.)
There is something almost pleasing about this, in the way a well-balanced equation is pleasing. Whether you are talking about a rented bicycle on a street corner or a spacecraft several hundred million kilometres from home, the physics of trust turns out to be the same shape: nothing gets to simply assert what it is. It has to demonstrate it — cryptographically, electrically, or otherwise — to something else that has absolutely no obligation to take its word for it. The universe, as far as we can tell, has never once operated on good faith. Engineering, eventually, always catches up with that fact, whether the thing being engineered is a rocket, a rented bicycle, or an AI agent with a login.
Trust in that architecture emerges from relationships, not from any single component:
The battery attests to the controller. The controller attests to the firmware. The firmware attests to the secure element. The secure element attests to the cloud. The cloud attests against manufacturing certificates.
The result is not merely a vehicle. It is a continuously governed system. A remarkable observation follows: the emerging architecture for AI agent governance looks structurally similar — hardware-rooted attestation, cryptographic identity, and continuous rather than one-time verification.2 Part XII returns to this in more depth.
Part III — The Tesla Lesson
Trust Architecture Beats Product Architecture
Tesla’s most consequential innovation may not be battery technology. It may be trust architecture.
Every Tesla update is cryptographically signed, and the vehicle verifies that signature before installing anything — Tesla, not a third party, decides what code a Tesla runs.3 Updates are staged so the vehicle stays stationary during installation and can revert to the previous known-good version if something goes wrong, and the deeper architecture underneath increasingly relies on hardware roots of trust — Trusted Platform Modules that store keys and perform attestation so that only verified firmware boots at all.4
That stack — identity, telemetry, attestation, monitoring, staged rollback, governance — turns a car into a continuously governed software platform rather than a static object you bought once.
It’s not a purely defensive story. Independent security research on Tesla’s cellular telematics stack in 2025 found real weaknesses — susceptibility to IMSI-catching and rogue base-station attacks, insecure fallback paths — which is a useful corrective to any narrative that trust architecture, once built, is finished.5 The thief no longer attacks a lock. The thief attacks an ecosystem, and the ecosystem has to keep defending itself, continuously, forever. That continuous-verification requirement, not the one-time build, is the actual product.
The same pattern increasingly appears everywhere: connected vehicles, industrial systems, cloud platforms, identity systems, autonomous agents. The future belongs to systems where trust is architectural rather than procedural.
Part IV — The Hidden Thread
Marketing, Behavioural Science and Intelligence
One of the more unexpected chapters of my career involved studying behavioural science and marketing systems. At first glance this appears disconnected from cybersecurity. It is not.
Marketing asks: why do people believe? Behavioural science asks: how does trust form? Intelligence asks: what information should be trusted? Security asks: how is trust abused?
Robert Cialdini’s decades of research identified a small set of heuristics — reciprocity, commitment and consistency, social proof, authority, liking, scarcity, and later unity — that predict compliance across cultures with remarkable consistency, precisely because they operate below conscious deliberation.6 The uncomfortable finding for anyone building secure systems is that these same heuristics are the substrate of social engineering. A 2024 study testing Cialdini’s principles against people who had been explicitly warned that a social-engineering attempt might be present found that the principles still worked — social proof and authority remained the strongest predictors of both trust and risk-taking, even when participants knew, in the abstract, that they were being tested.7
The common thread is trust. Not technology. Trust. This insight becomes profoundly important once intelligence itself becomes software — because behaviour becomes the attack surface, and behavioural manipulation no longer requires a human attacker on the other end.
Part V — Intelligence Becomes Abundant
The Most Important Transition Since the Internet
For centuries, intelligent labour was scarce. Humans required sleep. Humans became distracted. Humans became bored. Humans stopped. Every security model implicitly relied on this fact — an adversary that got tired was an adversary that eventually gave up.
Then intelligence became software. Not consciousness. Not sentience. Something more disruptive: persistence.
The scale of this shift is now visible in the numbers rather than just the argument. Gartner reported a 1,445% surge in enterprise inquiries about multi-agent orchestration in 2025 alone, and the autonomous-agent market crossed roughly $7.6 billion the same year, with Deloitte projecting it toward $50 billion by 2030.8 Nvidia has said it now runs on the order of 100 AI agents per human employee internally — a ratio in the millions of agents against tens of thousands of people.9 An autonomous system never sleeps, never becomes bored, never goes home. Civilisation has never operated at this scale before.
Part VI — Building the Bad
Why Trust Cannot Be Studied From a Distance
To build trustworthy systems, I discovered an uncomfortable reality. Eventually you must build the thing you hope to defend against. You must build the adversary. You must build the attack path. You must observe trust failing. Only then can you understand how trust survives.
This was one of the forces that eventually led to SILO. Not because I was interested in cybersecurity for its own sake. Because I became increasingly interested in trust itself.

The starting premise is uncomfortable and simple: an AI agent with valid credentials is the perfect insider threat. It doesn’t trigger malware signatures, because it isn’t malware. It doesn’t use known-bad patterns, because every action it takes is authenticated with keys it was legitimately issued. A single compromised agent — via prompt injection, model poisoning, or adversarial manipulation of its inputs — can drift autonomously from its intended behaviour, abuse those valid credentials, and exfiltrate data or modify systems, and it can do more damage in minutes than a human insider could do in months, precisely because nothing about the attack looks unauthorised from the outside.10
The architecture SILO uses to answer that is a direct, literal application of Part II’s Lime Bike observation — trust emerging from relationships between components, each one checking the others — built as five layers, each watching a different altitude of the same system: silicon (bus transactions, DMA, CPU instructions), the hypervisor (kernel memory, process tables), the OS kernel (syscalls, file operations, network packets), the user-space agent mesh (per-agent behavioural telemetry, captured via eBPF), and a cloud or on-prem classification layer that does the actual machine-learning judgment and triggers the response.11 The insight underneath all five layers is the one this whole paper has been arguing in the abstract: a rootkit can fool the kernel. It cannot fool the kernel and the hypervisor and the hardware simultaneously, because it doesn’t have write access to all three at once — the disagreement between layers is, in a fairly literal sense, physically unforgeable.12

That disagreement feeds a Trust Deficit Score: a continuously updated 0–100 rating per agent, built from syscall patterns, file access, network activity, memory operations, process relationships, API usage and exactly those cross-layer discrepancies, run through an ML pipeline (isolation forests for anomaly detection, LSTMs for sequence modelling, a distilled transformer for intent classification).13 The response is graduated rather than binary — an agent crossing a score of 15 gets closer observation, 40 gets its capabilities restricted, 70 gets network-isolated, and only past 90 does the system terminate it outright and notify a human — which matters because a system that can only say “trusted” or “not trusted” either over-blocks legitimate agents into uselessness or under-reacts to a slow, low-and-slow compromise. A score is a curve. A permission is a wall.
After enough systems, enough platforms, enough transformations and enough AI products, one conclusion became difficult to avoid: every technological revolution eventually becomes a trust problem. SILO is what happens when you stop treating that as an aphorism and build the containment layer it implies — down to the silicon.
Part VII — The Necessity of Building an Adversary
Why SILO Required SPECTRE
One of the more uncomfortable truths of security engineering is that eventually you must build the thing you hope to defend against. A firewall engineer who has never studied attack paths will eventually fail. An anti-fraud engineer who has never understood fraud will eventually fail. An AI governance architect who has never explored autonomous adversarial behaviour may discover, too late, that theory diverges sharply from reality.
This is the same instinct described at the start of Part VI — the compulsion to open every black box — pushed one step further. It is not enough to build the defender. You must also build the adversary, and then refuse to let the two sides cooperate. That refusal is the entire design principle behind SPECTRE, the autonomous adversary built specifically to test SILO.
SPECTRE does not ask SILO whether it has been detected. SILO must find it independently.14 That distinction sounds obvious. It is not. Many security systems, even well-intentioned ones, end up quietly measuring themselves rather than the adversary: the defender is told in advance what to look for, or the test is scripted closely enough to the detection logic that a pass proves the system can recognise its own assumptions and nothing more. SPECTRE’s architecture rejects that model outright. It establishes a clean autonomy boundary — SPECTRE attacks, SILO observes, and verification happens only afterward, checked against a ground truth neither side had access to during execution.15
An adversary does not ask permission. It does not announce intent. It does not subscribe to the defender’s audit stream. It simply acts. So SPECTRE acts, receiving no hints about SILO’s detection logic, and SILO must observe independently — without cooperation, without signalling, without trust — in exactly the way Part II described trust as something that has to be established between components with no built-in reason to assume good faith in one another.16
The result is not a benchmark in the conventional sense. It is closer to a controlled instrument for answering a single, specific question: how does an autonomous system behave when it is unconstrained, and can another autonomous system recognise that behaviour without being told what to look for? Historically, every major computing platform eventually required its own version of this capability — testing frameworks, observability frameworks, compliance frameworks, verification frameworks. The internet needed them. Cloud needed them. Mobile needed them. It would be a strange kind of exceptionalism to assume autonomous agents will not.
The uncomfortable version of the underlying claim, stated plainly, is this: I did not build SILO because I was interested in AI security for its own sake. I built it because thirty years spent moving between military intelligence, behavioural science, marketing, finance, governance and artificial intelligence kept arriving at the same conclusion — every technology revolution eventually becomes a trust problem. Intelligence has now become software. Trust, therefore, becomes infrastructure. To test that conclusion rather than merely assert it, I built the adversary as well.
That last sentence is the difference between a prediction and a body of evidence. It is one thing to argue, as Part VIII of this paper does, that no external safety architecture can be fully outsourced or trusted at a distance. It is another to have already built both the attacking and the defending half of that argument, and to have watched what happened when neither side was told about the other.
There’s a neat echo here of the Stark argument that opened this paper. Building SILO didn’t remove the need to understand systems — if anything, it multiplied it, because now there were two systems to understand instead of one, each built specifically so as not to trust the other’s account of itself. Someone always has to build JARVIS. It turns out someone also has to build the thing whose entire job is finding out whether JARVIS is lying — and, crucially, that someone has to understand both well enough that neither can talk its way past them.
Part VIII — The Anthropic Illusion
Governance Cannot Be Outsourced
Many people find comfort in the safeguards implemented by Anthropic, OpenAI, Google and Microsoft. Those safeguards matter. They are also insufficient, and June 2026 supplied the clearest possible demonstration of why — one concrete enough that this section barely needs the counterfactual argument anymore.
On June 9, 2026, Anthropic released Claude Fable 5 and Claude Mythos 5, its most capable models to date. Within three days, the U.S. Commerce Department invoked export controls covering both models worldwide — reportedly triggered by an informally reported, narrow jailbreak technique that could route around a cybersecurity safeguard, allegedly demonstrated by another company reading a codebase and asking the model to “find and fix” vulnerabilities in it.17 Because the controls applied to foreign nationals with no clean way to comply selectively, Anthropic disabled both models for every customer on Earth rather than for the specific population the order targeted.18 Anthropic’s own public position was blunt: treating a narrow, non-universal jailbreak as grounds to recall a model already deployed to hundreds of millions of people would, applied consistently across the industry, “essentially halt all new model deployments for all frontier model providers.”19 Access to Mythos 5 was partially restored on June 26 for a vetted list of roughly a hundred organisations; Fable 5 remained offline longer.20
Sit with what actually happened there, independent of where you land on the policy: a private company’s safety architecture, its enterprise contracts, and its own internal governance process were all rendered irrelevant in a matter of days by a single government’s decision, acting on an informal, unverified report. The labs’ safeguards were not the load-bearing wall. Jurisdiction was. Whoever holds the ability to switch a model off — the lab, and behind it whichever government the lab answers to — holds leverage over every downstream customer, regardless of how good that customer’s own governance is.21
Now widen the aperture. Who governs the privately hosted frontier-derived model, fine-tuned and running on someone’s own hardware? Who governs the open-weight model that was never gated in the first place — and by mid-2026, Chinese open-weight providers already accounted for more than 45% of all inference traffic on major aggregators, a share that keeps growing precisely because it cannot be switched off by anyone’s export-control letter?22 Who governs the reasoning engine operating beyond commercial infrastructure entirely?
Nobody. At least not today. This is why the problem is governance rather than safety. A safety classifier is a property of a specific vendor’s specific deployment. Governance is a property of the ecosystem, and the ecosystem currently has no equivalent of a hardware root of trust — no layer beneath the model that a customer, a regulator, or a competitor can independently verify.
Part IX — The Billion-Dollar One-Person Company
The New Economics of Scale

The phrase increasingly heard in technology circles is: the billion-dollar one-person company. Many treated it as speculation as recently as two years ago. The evidence base has since caught up with the rhetoric.
Sam Altman has described a running bet among a group of tech CEOs over which year the first one-person, billion-dollar company would appear.23 Dario Amodei has been more specific, putting a 70–80% probability on it happening within 2026, most likely in proprietary trading, developer tooling, or automated customer service.24 The closest real candidate so far isn’t a pure AI play at all: Matthew Gallagher built Medvi, a telehealth company, from $20,000 and a stack of AI tools including Claude, generating a reported $401 million in revenue in its first full year with a headcount of two, and is tracking toward roughly $1.8 billion in 2026 revenue — a margin nearly three times that of an incumbent competitor with over 2,400 employees.25 Midjourney, with fewer than 15 people, has reportedly reached roughly $200 million in annual revenue.26 Sequoia Capital has publicly said it is adjusting its underwriting models to account for what it calls “agentic leverage” — the ability of small teams to produce outsized output through AI orchestration.27
Historically, scale required people. People required management. Management required hierarchy. Hierarchy required bureaucracy. Autonomous systems change the equation: one founder may orchestrate marketing, sales, research, development, operations and support through fleets of agents. The legal paperwork may still name an individual as CEO. The operational reality is closer to that individual acting as the governor of an autonomous organisation.
This changes everything, because capability is no longer the constraint. Trust becomes the constraint — and Medvi’s own early stumble makes the point concretely: its AI customer-service agent fabricated drug prices (which Gallagher chose to honour) and hallucinated products that didn’t exist.28 A company with a headcount of two has no bureaucratic layer to absorb that kind of failure. The smaller the human organisation, the more the entire enterprise’s credibility rests on whether its autonomous layer can be trusted to represent it correctly — which is precisely the thesis this paper is making, playing out in a live business before the ink on the prediction was dry.
Part X — The CEO, the CISO and the Investor
Three Seats. One Question.
One of the privileges of a long career is eventually sitting in multiple seats. Intelligence analyst. Engineer. Architect. Executive. Founder. CEO.
Each role appears different. Yet every role eventually asks the same question: what can be trusted?
The CISO sees risk. The CEO sees leverage. The investor sees opportunity. The board sees governance. All are observing the same phenomenon from different altitudes.
There are, in my experience, two kinds of large organisation currently getting this wrong, and they sit at opposite ends of the same mistake.
The first kind won’t touch agentic AI at all, or won’t touch it properly. Every proposal gets slow-walked through committee, every pilot gets quietly parked after the demo, every request for proposal grows another appendix of caveats until the exercise becomes a monument to caution rather than a decision. The instinct is understandable. It is also, increasingly, the more dangerous of the two postures, for reasons I’ll come to in a moment.
The second kind did the opposite. They said yes to everything, and now have agents running through production systems with access nobody fully mapped, credentials nobody fully audited, and a governance model that exists mainly as a slide nobody has opened since the deck was approved. Ask their finance team how many agents currently hold write access to a general ledger, or their legal team how many can send correspondence on the company’s behalf, and watch the room go quiet. That silence, more than anything else in this paper, is the practical argument for everything Parts VI and VII describe.
Here’s the part that ought to arrive as a quiet realisation rather than a headline: for the organisations still sitting on their hands, the caution itself has become the risk. Not because agentic computing is inherently safe — it plainly isn’t, left ungoverned, which is rather the whole point of this paper — but because the legacy IT estate being so carefully protected by not adopting it is already the more exposed system in the building. Ageing, brittle, human-patched, human-paced infrastructure was never built to withstand an adversary that doesn’t sleep, doesn’t tire, and doesn’t need a human to click the link. Properly governed agentic computing — with the kind of layered, cross-checking architecture Parts VI and VII describe — is not, in the end, the thing most likely to compromise that estate. It may well be the only thing left capable of defending it at the speed the threat now moves. Worth sitting with that for a moment rather than reacting to it. It isn’t a call to panic. It’s closer to a diagnosis.

None of this is an argument for rushing. It’s an argument for retiring the idea that adoption and caution are opposites. The RFP that takes eighteen months to approve a single pilot, and the deployment that skipped governance entirely to hit a deadline, are the same failure wearing different clothes: neither one asked, early enough, who is accountable for what an agent does at three in the morning with nobody watching. Boards will ask that question eventually, whether or not the organisation has an answer ready. And when they do, ignorance, lethargy and underestimation will be shown no mercy whatsoever when it comes time to answer to shareholders.
Part XI — The Emergence of Digital Immune Systems
Beyond Identity
For decades, cybersecurity focused on identity. Who are you? Can you prove it? Are you authorised?
The autonomous age introduces a new question: are you behaving as intended? An agent may possess valid credentials, valid permissions, valid access — and still produce dangerous outcomes. Identity alone is no longer sufficient.
Gartner formalised a related idea in 2023 under the name “digital immune system” — a combination of software design, testing, automation, observability, chaos engineering and supply-chain security practices intended to let a system detect anomalies, isolate them, and recover largely without human intervention, the way a biological immune system contains an infection rather than preventing exposure entirely.29 Gartner’s own projection was that organisations investing in this kind of resilience could cut downtime by roughly 80%.30 The framework was built for software reliability, not for AI agents specifically, but the underlying shift it describes — from static, one-time defence to continuous, adaptive detection-and-response — is exactly the shift autonomous systems force onto trust more broadly.
This is where digital immune systems, applied to agents rather than applications, become relevant: not preventing compromise outright, but detecting unhealthy behaviour quickly enough to respond before it compounds. SILO (Part VI) is what that looks like built specifically for agents rather than adapted from application monitoring: a Trust Deficit Score instead of a static permission set, and a graduated response — observe, restrict, isolate, terminate — rather than the binary allow/deny that most access-control systems still default to.13 The Gartner framework predicted the shape of the solution in 2023. The agent-security layer is what happens when someone builds the cross-layer version of it for a class of system Gartner wasn’t yet describing — and, per Part VII, tests it against an adversary that owes it nothing.
Part XII — Why Silicon Matters
Trust historically migrates downward: software, operating systems, hardware, silicon. Trusted Platform Modules emerged in the 2000s because software alone could not be trusted to attest to its own integrity — you needed a piece of hardware that couldn’t lie about what had booted.
The same migration is now visibly underway for autonomous agents. Trusted Execution Environments — Intel SGX and TDX, AMD SEV-SNP, ARM TrustZone and CCA — isolate an agent’s code and memory from the host operating system, the hypervisor, and even a compromised cloud administrator, and support remote attestation: a cryptographic proof, verifiable by a third party, that specific unmodified code is running in a genuine enclave.31 Nvidia now ships confidential computing across its Vera Rubin platform specifically to extend that guarantee to GPU-scale inference, describing it as “hardware-rooted attestation to verify the trustworthiness of compute assets.”32 Academic surveys of the space describe TEEs as addressing “a fundamental trust gap” for autonomous agents: without hardware attestation, an operator cannot verify that an agent’s reasoning was actually isolated from host-level observation, or that its audit logs reflect real execution rather than a manipulated reconstruction after the fact.33
This connects directly to a framework that already exists, just not yet applied consistently to agents: NIST’s zero trust architecture, formalised in SP 800-207, built on a single governing premise — trust is never granted implicitly, it is continually evaluated, for every request, regardless of where that request originates.34 “Never trust, always verify” was written for humans and devices on a network. It is, without much modification, the correct architecture for autonomous agents acting at machine speed.
Future agents will likely require, as a baseline rather than an option: hardware attestation, trusted execution, behavioural attestation beyond a one-time code check, continuous runtime trust scoring, and cryptographic identity that survives being copied. The next trust revolution may begin not in software, but in silicon — and unlike the software layer, silicon is expensive to fake and hard to patch around after the fact, which is exactly why it is where trust tends to end up.
SILO’s own architecture (Part VI) is built on that premise rather than around it: its lowest layer runs on hardware and FPGA rather than in the OS, specifically because it needs a vantage point a compromised kernel cannot lie to.12 It isn’t a hypothetical roadmap item. It’s the floor the rest of the system is built on — and Part VII is the reason we know the floor holds under adversarial load rather than merely under design review.
Part XIII — The Final Convergence
After thirty years moving between military intelligence, operating systems, silicon engineering, financial services, behavioural science, marketing technology, cloud platforms, AI systems and entrepreneurship, one conclusion appears unavoidable.

Every road leads back to trust. Military intelligence is trust. Marketing is trust. Brand is trust. Leadership is trust. Investment is trust. Cybersecurity is trust. Governance is trust.
Artificial intelligence does not change this. It amplifies it, and it compresses the timeline on which the amplification becomes undeniable — the Fable 5 episode took three days from launch to global shutdown, not three years. Because intelligence is becoming abundant. And when something becomes abundant, the scarce resource becomes valuable. The scarce resource is no longer intelligence. The scarce resource is trust.
Which is, when you strip away thirty years of case studies, the whole of it: intelligence is becoming abundant, trust is becoming scarce, therefore trust becomes infrastructure. It was true in Part I. It is still true here, at the end, and I’d wager it will still be true whenever this paper is next revised.
Conclusion
The industry remains obsessed with making AI more capable. History suggests capability is not the bottleneck. Trust is.
The internet required identity. Cloud required observability. Mobile required secure enclaves. Connected vehicles required distributed trust. Artificial intelligence will require governance — and June 2026 offered the first large-scale, public proof that the governance layer does not yet exist in a form anyone can rely on, including the lab that built the model.

The future will not belong solely to those who build the smartest agents. It may belong to those who make autonomous systems trustworthy enough to become infrastructure. Because capability creates possibility. Trust creates adoption. Governance creates scale.
In a world where intelligence becomes infinitely replicable, trust may become the most valuable technology humanity has ever created. Not because it is new. Because it is the oldest technology civilisation has ever possessed — and, for the first time, we are being forced to re-engineer it at the speed of software rather than the speed of institutions.
It’s worth returning, briefly, to Stark and his workshop, because the thought that started this paper turns out to be its best summary too. AI will keep raising the altitude from which we work — that much is not in serious dispute, and it happens faster every year. But raising the altitude is not the same as removing the ground. Someone still has to build JARVIS. Someone still has to understand, in unglamorous and structural detail, how the systems underneath behave, misbehave, and can be made to answer for themselves when they do. The keyboard may well become optional. Understanding systems, trust and behaviour will not — and that, rather than any particular model release, patent or product, is the actual thesis of everything written above.
And if you’re into motorcycles — or watch bikes, beards, and grown men wrestling with things that were supposed to Just Work™ — take a look at these two trying to fix an EV Harley-Davidson. It’s a rather perfect illustration of everything above: the hardware is fine, the software is the problem. Trust, it turns out, is the same shape whether it’s a rented bicycle, a spacecraft, or a Harley that won’t start because a computer has quietly decided it shouldn’t.
Notes & Sources
Footnotes
-
The general pattern of hardware-rooted trust (secure element, keys embedded at manufacture, attestation before boot) is described in the context of OTA-updated connected devices in “Over-the-air update,” Grokipedia, and in the automotive-specific literature on trusted-execution OTA architectures (Springer, Annals of Telecommunications, 2025). ↩
-
See Part XII and its sources on TEEs, remote attestation, and hardware-rooted agent identity. ↩
-
RC Fact, “How Does Tesla Do Over The Air Updates? Software Explained,” 2026. ↩
-
Tesevo, “The Benefits and Process of Tesla OTA Updates,” 2025; Grokipedia, “Over-the-air update,” 2026 (on TPM-based root of trust for OTA validation). ↩
-
“Security Analysis of LTE Connectivity in Connected Cars: A Case Study of Tesla,” arXiv, 2025. ↩
-
Robert Cialdini, Influence: The Psychology of Persuasion (1984; revised and expanded editions); Cialdini & Goldstein, “Social Influence: Compliance and Conformity,” Annual Review of Psychology, 2004. ↩
-
Mollazehi, Abuelezz, Barhamgi & Ali, “Do Cialdini’s Persuasion Principles Still Influence Trust and Risk-Taking When Social Engineering is Knowingly Possible?”, Springer, 2024. ↩
-
Gartner enterprise inquiry data and Deloitte market projection, cited via Taskade, “AI Agents, Solo Founders, and the $1B Prediction,” 2026, and NxCode, “The One-Person Unicorn,” 2026. ↩
-
Jensen Huang, remarks at Nvidia GTC 2026, cited via Taskade, 2026. ↩
-
SILO, SILO: Unforgeable Security (investor deck), 2026 — “The Anatomy of a Rogue Agent” and “The ultimate insider threat operates with perfect credentials.” ↩
-
SILO, SILO: Unforgeable Security (investor deck), 2026 — “The Unforgeable Truth: Five Layers of Cross-Layer Verification” (L0 Silicon Sentinel, L1 Phantom Visor, L2 Guardian Rootkit, L3 Agent Mesh, L4 Neural Cortex). ↩
-
SILO, SILO: Unforgeable Security (investor deck), 2026 — “Cross-layer discrepancy is physically unforgeable.” ↩ ↩2
-
SILO, SILO: Unforgeable Security (investor deck), 2026 — “Trust Deficit Score: Autonomous response at runtime” (ML pipeline and graduated Observe/Restrict/Isolate/Terminate response bands). ↩ ↩2
-
SILO/SPECTRE, internal architecture documentation, 2026 — on the autonomy boundary requiring SILO to detect SPECTRE without cooperation or disclosure. ↩
-
SILO/SPECTRE, internal architecture documentation, 2026 — “SILO observes, SPECTRE attacks, verification occurs later, neither side cooperates during execution.” ↩
-
SILO/SPECTRE, internal architecture documentation, 2026 — on the absence of signalling or shared audit access between attacker and defender during test execution. ↩
-
Reporting on the June 2026 Commerce Department action against Claude Fable 5 and Mythos 5: Medium/Andy Garcia, “When a Government Can Switch Off a Frontier Model,” June 2026; ComplianceHub.Wiki, “When a Jailbreak Becomes a National-Security Event,” June 2026. ↩
-
Ibid.; digitalapplied.com, “Does US AI Gatekeeping Hand China the Open-Source Edge?”, 2026. ↩
-
Anthropic official statement, June 12, 2026, quoted via digitalapplied.com, “Government-Gated AI: OpenAI, Anthropic & a New Era,” 2026. ↩
-
digitalapplied.com, “Government-Gated AI,” 2026 (June 26 partial restoration for Mythos 5). ↩
-
provos.org, “The Case For Open-Weight Models And Why We Can’t Trust Frontier Labs,” 2026. ↩
-
digitalapplied.com, “Open-Weight vs Closed-Source AI Models 2026: Gap Analysis,” 2026; Resilient Cyber Newsletter #104, Chris Hughes, 2026 (OpenRouter Chinese-model usage share). ↩
-
Multiple reports of Sam Altman’s tech-CEO group chat prediction pool, e.g. Forbes, “The Future Is Solo,” Feb 2025; Forbes, “OpenAI Called The One Person AI Startup,” Apr 2026. ↩
-
Dario Amodei, remarks at Anthropic’s Code with Claude conference, cited via orbilontech.com, “How AI Creates $1B One-Person Company,” 2026. ↩
-
PYMNTS.com, “The One-Person Billion-Dollar Company Is Here,” Apr 2026; Forbes, “How A Telehealth Startup Found Success With Just $20,000 and AI,” Apr 2026 (both citing New York Times reporting on Medvi). ↩
-
NxCode, “The One-Person Unicorn,” 2026. ↩
-
Ibid. (Sequoia Capital “agentic leverage” underwriting commentary). ↩
-
Forbes, “How A Telehealth Startup Found Success With Just $20,000 and AI,” Apr 2026. ↩
-
Gartner, “Definition of Digital Immune System,” Gartner IT Glossary; Gartner, “What Is a Digital Immune System and Why Does It Matter?” ↩
-
Ibid. ↩
-
Blaxel, “What Is a Trusted Execution Environment?”, 2026; “AI Identity: Standards, Gaps, and Research Directions for AI Agents,” arXiv, 2026; “From Logic Monopoly to Social Contract,” arXiv, 2026 (on TEE + TPM combined trust for multi-cloud AI). ↩
-
Nvidia, “AI Security with Confidential Computing,” product documentation, 2026. ↩
-
“From Logic Monopoly to Social Contract: Separation of Power and the Institutional Foundations for Autonomous Agent Economies,” arXiv, 2026. ↩
-
NIST SP 800-207, Zero Trust Architecture; NIST, “Zero Trust Cybersecurity: ‘Never Trust, Always Verify’,” NIST Blog, 2025. ↩