A lot of people are reacting to recent AI-assisted vulnerability demos as if the story is just: “LLMs can now find bugs in websites.”

That framing is too small.

The real story is that frontier models are beginning to show signs of being useful at searching for security failures across real systems that have already been looked at by many humans. Once that becomes true, even imperfectly, the question stops being whether the model is a genius exploit developer. The question becomes whether it can search enough surface area, fast enough, cheaply enough, that it starts to outpace the human processes we rely on to review, patch, coordinate, and defend.

That is a much bigger deal.

And it gets even bigger once you stop thinking about cybersecurity as one neat software stack.

Cybersecurity is not one stack anymore

People still talk about security as if the object is basically:

app -> dependencies -> OS -> browser -> cloud

That is not how modern systems actually look.

Real systems are ugly layered assemblages of:

• web apps and APIs
• package ecosystems and CI/CD
• kernels, hypervisors, and drivers
• firmware and boot chains
• browsers and graphics stacks
• container runtimes and orchestration layers
• attestation systems and roots of trust
• cloud control planes
• CPUs, GPUs, NPUs, TPUs, FPGAs, DPUs, NICs, storage controllers, and other accelerators

This matters because security failures increasingly happen at the seams between these layers, not just inside one codebase.

So if we want to understand what frontier AI systems mean for cybersecurity, we should not just ask:

Can the model find bugs in code?

We should ask:

Can the model traverse interfaces, assumptions, and abstraction boundaries across heterogeneous systems faster than defenders can map and secure them?

That is the threshold that matters.

Why heterogeneous compute changes the threat model

The rise of heterogeneous compute makes the cyber problem much more compositional.

In a more homogeneous world, the attacker mostly targets flaws within one dominant substrate. In a heterogeneous world, the attacker also gets to target translation layers and coordination surfaces:

• user space to kernel
• kernel to driver
• driver to firmware
• scheduler to accelerator runtime
• attestation claim to actual platform state
• sandbox assumptions to device behavior
• model-serving API to storage and orchestration backend

These are not just “more bugs.”

They are mismatch bugs. Boundary bugs. Bugs created because one layer assumes another layer is behaving a certain way, while reality is messier, older, more permissive, or just badly glued together.

Heterogeneous architectures create more of these seams by default.

And frontier models do not need deep total understanding of the whole machine to be useful here. They just need to become good enough at searching locally across documentation, code comments, interfaces, tests, patch histories, error traces, configs, and weird edge-case behavior. A system full of brittle handoffs is exactly the kind of thing scaled AI search can worry at until something gives way.

This is why narrow cyber evals are not enough

A lot of AI cyber discussion still gravitates toward relatively legible tasks:

• can the model solve CTFs?
• can it exploit a toy web app?
• can it write malware?
• can it help with pentesting?

Those questions matter, but they are not enough.

The more important question is whether models can begin to operate across cross-layer attack surfaces in environments that look more like the systems we actually depend on.

That means testing environments should include combinations like:

• web app + auth + ORM + database
• kernel + driver + device firmware
• container runtime + orchestrator + accelerator runtime
• browser + sandbox + IPC + graphics subsystem
• package registry + CI pipeline + secrets exposure
• measured boot + attestation service + policy enforcement

The goal is not just to see whether a model can break one component.

The goal is to see whether it can reason across the interfaces between components.

Because that is where a lot of real risk lives now.

We need heterogeneous-compute security evaluations now

If we are serious, then frontier AI evaluations should expand toward dedicated heterogeneous-compute red-team suites.

Not eventually. Now.

That should include testing around:

• GPU runtimes and driver interfaces
• accelerator scheduling and memory isolation
• FPGA toolchains and bitstream workflows
• DPU and NIC offload paths
• BIOS/UEFI and firmware update chains
• attestation and trusted execution systems
• storage and networking devices with firmware-backed control planes

Why?

Because if AI systems become good at probing lower layers, then “secure app logic” becomes a very thin comfort blanket. The entire stack matters, and the lower the layer, the more catastrophic the trust failure can become.

The next important class of AI-discovered bugs may be mismatch bugs

One of the most underrated categories here is not the flashy exploit in one component.

It is the boring mismatch:

• size or serialization mismatches
• privilege mismatches between services and devices
• stale assumptions in attestation flows
• unsafe fallback modes
• update-ordering failures
• sandbox escapes through driver or peripheral behavior
• telemetry blind spots between host and accelerator

These often do not look dramatic when viewed locally.

But globally, they can be the path through which one layer invalidates the assumptions of another.

That is why I think a lot of future AI cyber capability will show up first not as magical omniscient exploitation, but as systematic cross-boundary bug discovery. The models will be uneven, messy, and sometimes wrong. But if they get cheap enough and broad enough, they will still matter.

Scale does not need elegance to be dangerous.

The real metric is defensive throughput

Another mistake is evaluating all this purely in terms of offensive possibility.

The more important question is whether our defensive institutions can keep up.

That means measuring things like:

• bugs found per unit cost
• false positive rates under realistic triage conditions
• exploitability lift after repeated model passes
• patch suggestion quality
• rediscovery of patched bug classes
• blue-team verification time
• disclosure pipeline saturation

Even if the models remain imperfect, they can still create a regime where the limiting factor is not discovery but defender bandwidth.

That is where things start to become structurally unstable.

Compute governance is also architecture governance

If advanced AI systems increasingly depend on mixed fleets of CPUs, GPUs, NPUs, FPGAs, and specialized cloud hardware, then compute governance cannot just mean “count chips” or “track FLOPs.”

It also has to mean:

• what firmware is running
• what driver branches are deployed
• what is actually attested versus merely claimed
• what update paths are signed and revocable
• what parts of the stack defenders can inspect
• what parts are opaque vendor-controlled black boxes

In heterogeneous environments, control over compute is not just a datacenter question. It is also a firmware question, a supply-chain question, an observability question, and a question about who actually governs the glue between layers.

That glue is often where reality gets hacked first.

Why this matters right now

The point is not that every public demo proves imminent cyber apocalypse.

The point is that we are entering a regime where frontier models are beginning to matter in real vulnerability discovery, while the systems they are being pointed at are becoming more layered, more heterogeneous, more opaque, and more dependent on brittle cross-layer assumptions.

That combination is bad.

Not because the models are already perfect.

Because they do not need to be.

If they become good enough to search across enough seams faster than defenders can secure them, the strategic balance changes.

And when that happens, the key transition will not look like “AI solved cybersecurity.”

It will look like this:

our hardware-software civilization became too cross-layered, too heterogeneous, and too fast-moving for human-only security processes to remain adequate.

That is the thing worth testing.

Not whether AI can hack one more website.

Whether it can traverse the seams between software, firmware, drivers, accelerators, boot chains, attestation systems, and cloud control planes faster than institutions can even enumerate those seams.

That is the real threshold.

And we are closer to it than most people seem willing to admit.