The Device You Ship Today Will Outlive Your Assumptions About AI
We can intuitively understand the enduring nature of the physical things around us:
A vehicle shipped today may still be on the road in 2046
Industrial equipment installed this year may operate into the 2060s
Grid infrastructure commissioned now may still serve communities near the end of the century
Meanwhile, AI capabilities are changing within months, which means we are embedding rapidly evolving intelligence into infrastructure that changes slowly.
Think of it as a problem of two clocks:
AI capability advances on a cadence of months
Physical assets remain in service for decades
The practical implication is that product security architecture must keep pace with the first while preserving trust throughout the entire life of the second.
AI is already accelerating reconnaissance, vulnerability discovery, exploit development, social engineering, and attack scale. More autonomous attack chains are emerging, exposing new threat vectors. Long before many products shipping today reach end of life, today's frontier capabilities are likely to be cheaper, more widely available, and integrated into offensive cyber operations.
Yet many connected products are still built around assumptions made at launch: a fixed hardware architecture, a known threat model, a particular cloud or chip vendor, a particular model family, and a patching process that takes weeks or months.
Unfortunately, those assumptions will not last as long as the devices.
Frontier AI changes both sides of the equation. Attackers can increasingly automate discovery and exploitation, while defenders can use agents to identify exposure, propose mitigations, validate changes, and coordinate deployment. The security challenge involves balancing agent usage with managing their authority, verifying inputs, maintaining provenance, and demonstrating the physical outcomes of their actions.
This applies well beyond vehicles. The distributed-energy resource (DER) assets now being deployed to power data centers and support the grid are also long-lived, software-defined, and increasingly AI-managed systems that are exposed to the same mismatch.
That is why Palantir's recent paper, Institutional Sovereignty in the Age of AI, deserves attention from anyone who ships, installs, or operates connected products.
Palantir asked the right question
Palantir’s paper asks a powerful question: who controls your organization's intelligence?
This includes its models, context, learning loops, compute, and update paths. Its principles of zero data retention, model liquidity, ownership of the context flywheel, and building by branching together provide a practical framework for retaining control over institutional data, models, compute, and learning loops.
Palantir also addresses owned hardware and attested compute (which is hardware-backed verification of compute integrity), but for connected products and cyber-physical systems, including IoT, OT, and software-defined vehicles (SDVs), physical control of compute is only part of the problem.
A poor enterprise AI answer may cause financial or operational harm. A poor edge-AI action can damage equipment, destabilize infrastructure, or harm someone.
The unresolved problem is that owning your AI context means little if you cannot trust the physical systems that produce and act on it.
This is the cyber-physical sovereignty gap.
The Cyber-Physical Sovereignty Gap
An institution may control its data, models, compute, and ontology, and yet still be unable to establish that:
the device is authentic;
its firmware and edge model are approved;
its runtime state is verified;
an agent acted within policy;
the physical result matched the intended action.
You can own the AI context and still not know whether the machine acting on it is the machine you think it is, running the software you approved, or behaving as expected.
This is because the model does not serve as the security boundary.
In a cyber-physical system, trust must extend across the full chain: sensor → device identity → firmware → edge runtime → model → agent → policy layer → actuator → physical result.
Every transition is a trust boundary and a potential attack surface. Prompt filtering and model alignment address only part of that chain. An attacker may choose any other link.
The AI supply chain runs deeper than model weights
The AI inside a connected product depends on far more than a model. Model weights encode what a trained model has learned, but the behavior and security of an AI-enabled product also depend on its training and evaluation data, open-source libraries, model repositories and adapters, inference runtime, agent frameworks and tools, retrieval sources, hardware accelerators, cloud services, firmware and operating system, signing and update infrastructure.
Any of those layers can be compromised, manipulated, outdated, or changed without adequate verification, and may alter what the AI-enabled product perceives, decides, or does.
A manufacturer may own the device while retaining limited visibility into the intelligence running inside it.
The Frontier AI asymmetry
Hackers using an AI-enabled offensive system can orchestrate agents, scanners, code-analysis tools, exploit knowledge, and infrastructure across large numbers of targets. Work that once depended on scarce human expertise can increasingly be repeated, automated, and scaled.
A manufacturer discovering an exposure may still need weeks or months to identify affected products, reproduce the issue, build firmware, validate the change, sign it, and reach the installed fleet.
SaaS teams narrowed their version of this gap through DevSecOps. IoT and OT cannot simply transplant that tooling.
They need the speed and feedback of DevSecOps, extended with hardware identity, firmware provenance, safety constraints, real-time operation, staged fleet deployment, and verification of physical state across products that might remain in service for decades.
From AI sovereignty to cyber-physical sovereignty
Connected-product companies need a continuous assurance loop: Discover → Prioritize → Remediate → Validate → Deploy → Verify → Learn.
That loop must span hardware identity, firmware, software dependencies, edge models, cloud services, fleet context, and observed physical behavior, enabling long-lived products to evolve while preserving evidence of what changed, why, and whether the physical system remained trustworthy.
This is what we are building into the Immutaverse platform:
Radar identifies which vulnerabilities and exposures are materially relevant to a device or fleet.
Regen develops and validates mitigations against operational and safety constraints.
Origin securely deploys approved changes and verifies recovery in the field.
The Immutaverse platform is designed to detect loss of cross-layer integrity, specifically, disagreement among device identity, firmware, software, models, cloud services, and observed behavior.
Faster patch generation is only part of the goal. The harder problem is keeping connected systems dependable as their software, models, threats, and operating conditions change. Immutaverse enables connected devices to evolve at the speed of the first clock and across the lifetime of the second.
An invitation
For connected products, true sovereignty is achieved when organizations broaden their scope of ownership beyond data, models, and AI context and ensure that the devices producing and acting on that context remain trustworthy by detecting, correcting, and recovering from failures.
AI sovereignty must extend beyond the model boundary to encompass physical outcomes.
We are beginning conversations with a small number of automotive, energy, industrial, and connected-product organizations interested in helping shape and pilot the Immutaverse platform.
An initial Immutaverse pilot would map one product or fleet across device identity, firmware, model and software provenance, cloud dependencies, and observed behavior, then test whether cross-layer inconsistencies can be detected before they become field incidents.
We want to partner with OEMs whose products are expected to remain in service through 2040 or beyond: what assumptions are you embedding today that AI may invalidate tomorrow?
