Start Here

Begin with Synoptikon

A short guide to Synoptikon, organised around Big Reads, Explainers, Perspectives, and Workbench.

What is Prompting Trust?

The weekly companion to Synoptikon, for current developments and shorter notes.

Feeds

Follow Synoptikon by feed, email, or curated sources without relying on the homepage.
When the endpoint cannot be trusted: the case for isolation architecture - featured image

The friction that used to protect you

What happens when the endpoint can no longer be trusted

Security has always been a race between the defender and the attacker. A vulnerability is disclosed; a patch is issued; an attacker reverse-engineers the binary; a systems administrator deploys the fix. For roughly three decades, that race was unequal in a useful direction. Attackers needed days or weeks to weaponise a new finding. Defenders, working through change advisory boards and patch-testing windows, could just about keep pace. The buffer was real, if uncomfortable.

That buffer is gone. Microsoft’s 2025 Digital Defence Report documents the consequence: the company now processes approximately 100 trillion security signals daily, with Infosecurity Magazine (2025) reporting that AI-powered attack automation is the primary driver of that volume. The time between disclosure and active exploitation has compressed to something procurement cycles were never designed to match.

This is not a temporary acceleration. The attacker’s loop is now faster than the defender’s, and the gap is not closing. For most of the history of enterprise security, defenders held the initiative, with more time than attackers to act on the same information. That relationship has reversed. What follows from that reversal, architecturally and strategically, is the subject of this piece.

How the trust boundary degrades

The danger of legacy endpoints is not simply that they carry known vulnerabilities. It is that they are fixed, predictable, and increasingly beyond the reach of the controls designed to manage them. Three distinct branches of the degradation sequence are worth tracing carefully, because each points to a different failure mode.

The first branch runs through the security appliance itself. On 15 October, Australia’s Cyber Security Centre (2025) issued an urgent advisory — not routine guidance — regarding multiple high-severity vulnerabilities in F5 BIG-IP products, alongside confirmation of an active incident affecting F5 infrastructure. Reuters (2025) reported systemic alarms: F5 devices sit at the network perimeter with privileged traffic inspection rights, and the specific vulnerability allows unauthenticated bypass of access controls. An attacker outside the network can walk past the device that was supposed to be checking their credentials.

The more important signal is architectural rather than technical. F5 appliances are trusted by design. They are positioned at the most sensitive chokepoints in enterprise networks, given near-complete visibility into encrypted traffic, and treated as authoritative about what should and should not pass. When the inspection layer carries its own exploitable flaw, the trust model collapses at precisely the point it was most relied upon. The watchtower, it turns out, has a door.

The second branch runs through endpoints that simply cannot be updated. Windows 10’s end-of-life means that machines failing the TPM 2.0 hardware check for Windows 11, a substantial and disproportionately cost-constrained population across manufacturing, healthcare, and education, will stop receiving security patches. They are not decommissioned. They remain on corporate networks, carrying credentials, storing data, and participating in authentication flows. They just stop evolving while the threat landscape continues to.

Against an adversary that can move from vulnerability disclosure to working exploit within hours, a device that will never receive the corresponding patch is not merely a degraded asset. It is a permanent liability with a predictable expiry date that has already passed.

The third branch is harder to see because it runs through the adoption agenda rather than the security agenda. Enterprise AI agents of the kind now being deployed across sales, finance, and operations workflows do not authenticate with passwords. They operate with OAuth tokens and API keys. A token that passes every identity check is, to a Zero Trust architecture, indistinguishable from a legitimate user. The actions it takes, including querying large volumes of data, triggering automated workflows, and initiating downstream API calls, look exactly as designed. Zero Trust was built to govern human users making human-scale requests. It was not drawn for non-human identities operating at machine volume on behalf of business processes that nobody in security classified as an authentication control. The distinction matters acutely when the token is the attack vector.

What the adversary already knows

CrowdStrike’s 2025 APJ eCrime Report names Australia the top regional ransomware target, with Chinese cybercrime marketplaces providing accessible tooling at scale. That is not primarily a geopolitical observation. It is a market one. Adversaries have made the same analysis a rational investor would: Australian organisations carry high asset values and, relative to those values, comparatively modest defences. Incentives that strong do not weaken; they compound.

The WA Health breach reported by ABC News Australia (2025) makes the same point from a different angle. A 15-year-old with no hostile intent and no sophisticated tooling triggered a major data exposure by probing a publicly reachable system. The mechanism was not cunning. It was a basic access control failure on infrastructure carrying sensitive health records, with no anomalous-behaviour detection to raise an alarm before the damage was done.

What that incident demonstrates is that attack sophistication and potential blast radius have decoupled. The interesting adversary is the one with AI tooling; the dangerous one might be a curious teenager on a Tuesday afternoon. Organisations that have calibrated their threat model entirely around organised, motivated actors are, in a meaningful sense, over-prepared for the wrong threat and under-prepared for the right one.

For decision-makers, the pincer produces one unavoidable analytical conclusion: prevention-first investment is misallocated against this combination of threats. Prevention assumes sufficient accuracy and speed to stop what is coming. Against an adversary exploiting at machine pace and a defensive estate patching at procurement pace, that assumption no longer holds as the primary strategic bet. This is a gamble that has already been lost in several Australian sectors. The question that matters now is not how to stop every intrusion but what any given intrusion can reach once it succeeds.

Where Zero Trust assumptions snap

Zero Trust is the dominant architectural doctrine of the past decade, and its core proposition, “never trust, always verify,” is not wrong. The problem is that it was designed for a threat model that is no longer complete.

The doctrine assumes the entity presenting for verification is knowable and classifiable: a human user, a managed device, a service account with a defined scope. It assumes the verification mechanism is reliable. And it assumes that the controls sitting between the entity and the resource are themselves trustworthy. The F5 advisory removes the third assumption. The AI agent problem removes the first. A Windows 10 machine that cannot receive a patch disables the second, because certificate and credential stores on unpatched endpoints are themselves potential attack surfaces.

None of this means Zero Trust is wrong to implement. It means that Zero Trust alone, on a heterogeneous estate containing legacy endpoints and non-human identities, provides weaker guarantees than its architects intended. The architecture holds until one of its load-bearing assumptions fails. In the current environment, multiple assumptions are failing simultaneously.

The design response to a doctrine that breaks under specific conditions is not to abandon the doctrine. It is to build a complementary layer that functions when the doctrine cannot. That layer is isolation.

The design shift: from perimeter to isolation

The architecture that survives the pincer is built on a different premise than prevention. Not “never trust, always verify” in the original formulation, but something closer to: assume the worst-case endpoint state exists right now, and design the network so that state cannot propagate.

That premise produces three specific design changes, each with a clear failure mode if ignored and a clear cost if implemented.

Reclassify legacy endpoints as untrusted nodes. Machines that cannot receive patches belong on quarantined network segments or behind virtual desktop infrastructure, with no direct path to domain controllers, file shares, or data stores carrying sensitive records. The network topology diagram that currently treats them as standard corporate endpoints reflects a fiction the adversary is already planning around.

The cost of micro-segmentation or VDI is real: implementation, licensing, operational overhead. The cost of ignoring it is specific and larger: the compromised legacy endpoint becomes the pivot point from which an attacker reaches the systems that are the actual target. Ransomware events that traverse a flat network from a Windows 10 machine to a backup server are not theoretical. They are the documented pattern. Micro-segmentation does not prevent the initial compromise; it removes the foothold’s value by ensuring the compromise cannot spread.

Rebuild high-stakes verification around hardware, not biology. ABC News Australia (2025) documents a doubled deepfake image-based abuse rate, with incidents occurring at least once daily. Any business process that uses video or voice as a verification factor, including executive authorisation of fund transfers, helpdesk password resets, and contractor identity confirmation, is operating on a trust assumption that has already been defeated in production environments elsewhere.

FIDO2 hardware tokens provide a phishing-resistant factor. They are harder to impersonate through synthetic media, but their security still depends on secure enrolment, physical possession, and recovery controls. The transition from visual or biometric confirmation to hardware-based verification is not a marginal improvement. It is the difference between a risk that can be managed and one that cannot.

The ownership question here is not trivial. Payment authorisation flows and helpdesk resets are typically owned by finance and operations, not security. A successful deepfake social engineering event on a process that security never classified as an authentication control is a failure mode that security cannot fix unilaterally. Who pays for the hardware token program, who owns the process change, and who absorbs the friction of retraining? These distributional questions need answering before the architecture can be implemented, not after.

Build the AI tool register before the governance pressure arrives. Clayton Utz (2025) published guidance on 16 October connecting director duties explicitly to AI governance failures. The Australian Department of Industry (2025) updated its AI adoption guidance with risk management and accountability as baseline expectations. The direction of regulatory and legal travel is clear: plausible ignorance about AI system behaviour is no longer a viable board posture.

A practical AI register records which systems are in production, what data they access, who owns the deployment decision, and whether a kill-switch procedure has been tested. It is not a compliance artefact. It is the evidence base that demonstrates active oversight, and the absence of that evidence is now, per the Clayton Utz guidance, a named governance failure rather than an implicit one.

Organisations that build the register under regulatory pressure, after an incident, build it badly and retrospectively. Those that build it as an operating practice have a tool the board can actually interrogate. The failure mode if it does not exist: a material AI-related incident with no documented governance structure to demonstrate reasonable oversight. Personal liability, the guidance makes clear, does not require malicious intent. It requires a failure to discharge due care.

The durable implication

The pincer movement is often described as if its two forces are symmetrical: AI attacks pressing from one side, legacy debt from the other. The more accurate picture is asymmetric. The attacking side is improving continuously, at scale, with commercial incentives behind it. The defending side is constrained by capital cycles, procurement timelines, and technical debt that compounds faster than most organisations resolve it.

That asymmetry does not resolve through effort alone. It requires a deliberate architectural response. The response is not another perimeter layer. The organisations that have learned to operate under this pressure share a common posture: they have stopped assuming they can prevent every compromise, and started designing for the assumption that some will succeed. Investment follows that logic, into isolation, into detection, into the controls that limit what a successful intrusion can reach.

The F5 advisory and the 15-year-old in Western Australia point to the same conclusion by different routes. Sophisticated adversaries exploit the appliance you trusted. Unsophisticated ones walk through the door you forgot to lock. In both cases, the question that determines the outcome is not whether they got in. It is what they found when they arrived. ■

Previous Post

Human and machine speed: the growing trust gap

Next Post

Machine identity and edge trust

Subscribe to Prompting Trust

Subscribe to Prompting Trust to receive The Weekly Context.

Prompting Trust is the newsletter layer connected to Synoptikon. It carries current developments, useful links, and shorter notes, while Synoptikon holds the longer arguments and working library.

Learn more about Prompting Trust.