What Comes After Zero Trust? Protecting Critical Infrastructure from AI-Scale Cyberattacks

Question

AI and hacking pose increasing threats to infrastructure, including financial networks, utilities, communications, and more. Air-gapped systems don't seem to be good enough.

How will these systems protect themselves? Can internal networks get mapped to an IPv4/IPv6 subset or abstraction layer that an AI bot or virus could not understand? Does all data, scripts, runtimes—virtually anything that can be executed by an OS kernel—need to be encrypted at rest and in flight? If air-gapping and current privilege-based systems are insufficient, how can internal networks function even if those protections are also insufficient?

What would a hardware and/or software solution look like?

Answer

The key design shift is to stop treating "inside the network" as a security boundary.

The goal should not be to create a network representation that an AI cannot understand. Given enough observations, an AI will eventually infer almost any stable abstraction. Instead, the architecture should make understanding the network provide almost no authority to do anything.

Hiding or rotating IPv4/IPv6 addresses can help, but only as one layer. The deeper objective is to eliminate persistent network identity, implicit reachability, reusable credentials, and unverified executable code.

An Ephemeral Capability Network

Imagine an Ephemeral Capability Network (ECN).

An application does not need to know where a destination physically exists. Instead of connecting to a durable IP address and port, it requests a capability:

connect(
  resource = BREAKER_CONTROL,
  operation = READ_STATUS,
  purpose = GRID_BALANCING
)

A hardware-backed policy system decides whether this particular workload, on this particular machine, running this particular binary, at this particular moment, may perform that operation.

If allowed, the system creates a temporary encrypted path. The underlying network can still use Ethernet, IPv6, optical networking, and conventional routing, but those technologies become transport mechanisms rather than security identities.

Addresses can change continuously. Malware scanning the network learns little of durable value.

More importantly, possessing an address does not confer permission to communicate with the resource.

Replace addresses with cryptographic capabilities

The stronger security primitive is a short-lived cryptographic capability tied to a workload and device.

Conceptually:

RESOURCE: Transformer-178
OPERATION: read_voltage
WORKLOAD: SHA256:8FA91...
DEVICE: TPM:92AC...
VALID: 18:52:00–18:52:05
MAX_REQUESTS: 3
DATA_CLASS: operational

The capability is cryptographically signed, expires quickly, cannot be transferred to another program or machine, and authorizes only the specified operation.

Stealing it provides very little value.

This replaces the familiar model:

username + password + role + VPN + network access

with something closer to:

hardware identity + measured workload + purpose + operation + time-limited capability

Make the network dark

An unauthorized machine should discover almost nothing:

• no useful DNS enumeration
• no broad service discovery
• no routable server inventory
• no persistent east-west routes
• no meaningful open-port map
• no durable topology

A workload asks a policy authority for permission. If authorized, the secure fabric constructs a temporary path. When the transaction ends, the path, mapping, keys, and capability disappear.

Network topology itself becomes ephemeral.

Encrypt everything—but distinguish confidentiality from integrity

For critical infrastructure, encryption should become the default:

• data at rest: encrypted
• data in transit: encrypted
• data in use: hardware-isolated where practical
• executables: signed, measured, and preferably encrypted
• firmware: signed and measured
• configuration: signed
• containers and VMs: measured
• AI models: signed and measured
• scripts: signed
• infrastructure-as-code: signed

But encryption alone is insufficient.

If malware replaces control.py with malicious code, disk encryption does not help once the operating system decrypts it. The machine should verify that the executable's cryptographic measurement matches an approved value before allowing it to execute or receive sensitive capabilities.

Move trust below the operating system

A compromised operating system should not automatically mean a compromised machine.

Put a separate security processor between the OS and critical resources. Think of an integrated evolution of a TPM, HSM, SmartNIC/DPU, attestation engine, key vault, and policy enforcement point.

The main operating system never possesses long-term root keys.

The security processor independently decides whether the OS may communicate with a resource, decrypt particular data, access a device, load firmware, or perform privileged operations.

A root compromise of Linux or Windows therefore does not automatically become root compromise of the infrastructure.

Separate policy authority from workloads

A sophisticated zero-trust architecture creates another danger: compromise the central policy controller and the attacker may own everything.

So the trust plane should itself be distributed.

Identity, device attestation, workload attestation, and policy authorization can be controlled by independent authorities. High-consequence actions can require threshold approval—for example, two of three authorities plus hardware attestation, an approved software measurement, a maintenance window, and perhaps physical operator approval.

One compromised AI agent cannot simply grant itself universal access.

Treat critical commands differently from ordinary traffic

Reading a turbine temperature and opening an emergency steam valve should not merely be two API permissions.

High-consequence operations should cross a hardware-enforced authorization boundary. Monitoring may remain network-accessible, while actuation requires independent policy consensus, verified control software, and—in the most critical cases—physical or human authorization.

Unidirectional gateways and data diodes remain valuable here: telemetry can leave a safety domain without creating an equivalent inbound command path.

Assume the AI eventually compromises a machine

The architecture should be evaluated from a harsher starting point:

Assume Server 47 is completely compromised. What can Server 47 actually do?

Ideally it can continue performing its assigned function and accessing its authorized data, but it cannot enumerate the infrastructure, scan unrelated resources, steal reusable credentials, load unsigned software, change its own authorization, impersonate another workload, establish arbitrary persistent routes, or modify firmware.

That is a fundamentally different objective from trying to guarantee that Server 47 can never be compromised.

AI becomes part of the defense

Traditional security often searches for known signatures: malware hashes, bad IP addresses, CVEs, and known command sequences.

Autonomous attackers can continuously change their behavior.

A defensive system should therefore maintain a behavioral envelope for every important workload. If a water-pump controller normally communicates with a fixed class of sensors at a predictable rate and suddenly requests access to an employee database, enumerates devices, transfers hundreds of megabytes, or asks for a firmware service, the network should not merely create an alert.

It should automatically reduce that workload's capabilities:

NORMAL
  ↓
SUSPICIOUS
  ↓
READ-ONLY
  ↓
ISOLATED
  ↓
PHYSICAL-SAFETY MODE

Humans can investigate afterward.

Critical infrastructure needs a digital immune system

Power grids, telecommunications networks, financial systems, and industrial plants cannot always respond to an intrusion by shutting down.

They need graceful degradation.

A critical system might operate through states such as:

LEVEL 0 — NORMAL
LEVEL 1 — HEIGHTENED
LEVEL 2 — CONTAINMENT
LEVEL 3 — AUTONOMOUS ISLAND
LEVEL 4 — SAFETY MODE
LEVEL 5 — MANUAL

A substation could lose cloud analytics, remote optimization, enterprise telemetry, and AI forecasting while retaining protection relays, voltage regulation, breaker safety, and local control.

The ability to continue operating safely while assuming the digital network is hostile becomes a cybersecurity feature.

A Hardware-Enforced Ephemeral Capability Architecture

I would combine these ideas into a Hardware-Enforced Ephemeral Capability Architecture (HEECA).

Its core invariants would be:

1. No persistent network trust.
2. No reusable machine credentials.
3. No execution without measured and signed provenance.
4. No communication without a short-lived cryptographic capability.
5. No high-consequence action based solely on software authorization.
6. Every critical physical process can operate in a degraded local mode after the digital network is considered hostile.

The underlying IPv6 network can remain conventional. What changes is that an IPv6 address no longer represents identity, authorization, or durable reachability.

The larger security model becomes:

Assume the network is compromised.
Assume the operating system is compromised.
Assume credentials will be stolen.
Assume malware understands the architecture.
Then design the infrastructure so none of those facts alone grants useful authority.

That is the direction critical-infrastructure security may need to move as autonomous AI systems make reconnaissance, exploitation, lateral movement, and adaptation dramatically faster.

The IPv4/IPv6 abstraction idea remains useful—but not because it can be made incomprehensible to AI. Its value is in making the network cryptographic, capability-based, workload-specific, non-enumerable, and continuously changing.

An attacker could understand exactly how the architecture works and still be unable to manufacture the hardware-backed authority required to traverse it.