Full publication

The Kinetic Gap: Why Physical AI Requires a New Assurance Discipline

Doc ID: ODA3-2026-08-INS-081 (companion to ODA3-2026-08-INS-080, the PAI-SF™ v1.0 framework release) Doc Type: Insight Audience: CISOs, Security Architects, AI Governance Leads, Compliance Officers, Standards Body Participants, Boards Publish date: 3 August 2026 | Review cycle: Quarterly

Methodology Note. This Insight examines a structural shift in AI assurance scope — from digital decision-making to physical consequence — and the discipline that shift implies. It references PAI-SF™ v1.0, published by ODA3 Institute on 3 August 2026, as one proposed architecture addressing that shift, not as the subject of the analysis. Claims here are analytical and forward-looking; they describe a structural gap and a candidate response to it, not measured adoption or outcomes.

Every era of computing created its own security discipline

Mainframes created information security. Networked computing created network security. The internet created web and application security. Cloud computing created cloud security. Artificial intelligence created AI security — model integrity, data poisoning, prompt injection, output safety.

Each discipline emerged because the underlying technology changed what could go wrong enough that the previous discipline's assumptions stopped holding.

Physical AI is doing that again.

Physical AI refers to AI systems that perceive, decide, and produce direct effects in the physical world through sensors, autonomous reasoning, and actuators — robotic arms, autonomous vehicles, drones, surgical robots, industrial automation, smart infrastructure. What distinguishes them isn't that they contain AI. It's that the AI's decisions terminate in movement, force, or physical state change, not in text or a recommendation a human reviews before acting on it.

That distinction changes the question security has to answer.

Three questions, three eras

For decades, security asked:

Can we trust the system?

AI introduced a narrower, harder question:

Can we trust the model?

Physical AI introduces a more consequential one:

Can we trust what AI is allowed to do?

That third question is different in kind, not just in degree. A wrong answer from a text model is often reviewable or correctable before execution. A wrong action from a physical system — a robotic arm that moves before a person clears the workspace, a vehicle that misreads a sensor and steers into the wrong lane — may already be irreversible by the time anyone notices.

Every physical action deserves at least as much assurance as the AI decision that produced it. Most of today's AI assurance infrastructure wasn't built with that standard in mind, because until recently, most AI decisions didn't produce physical actions at all.

Why existing assurance stops at the wrong place

Traditional AI assurance follows a short chain:

User → Prompt → Model → Output

Security and governance controls cluster around that chain — the model, the data feeding it, the output it produces, the person reviewing that output.

Physical AI follows a longer one:

Environment → Sensors → Perception → Model → Decision →
Autonomy → Actuator → Physical Effect → People

Everything after "Model" in that second chain is new territory for AI assurance — and it's exactly where AI governance frameworks, model security tooling, and traditional functional-safety engineering each stop short, from a different direction:

• AI governance and AI security were built to secure the decision. They generally don't extend into whether the actuator obeying that decision is independently constrained.
• Functional safety and industrial security were built to secure the machine. They address hazards from malfunction and failure — not necessarily from a model that's technically functioning correctly but has been deceived, manipulated, or pushed outside its design conditions.

Neither discipline is wrong. Each solved its part. What's been missing is the seam between them — the assurance question that only exists once a digital decision and a physical actuator are the same system.

That seam is the kinetic gap.

Why this was inevitable, not optional

This isn't a gap that emerged because any single organization wanted a new framework to sell. It emerged because AI acquired capabilities that assurance models weren't built to assume:

• eyes — continuous, real-time environmental perception
• hands — the ability to actuate, manipulate, and apply physical force
• mobility — operation across changing, unstructured physical environments
• continuous autonomy — decisions made without a human in the loop for every action
• shared workspaces — operation in physical proximity to people, not behind an API boundary
• distributed edge execution — decisions made on hardware that isn't continuously connected, monitored, or updatable in real time

Any one of these would stretch existing assurance models. Together, they describe a system category that industrial automation, cybersecurity, functional safety, cloud security, and AI security each address a piece of — and none addresses as a whole.

Physical AI Security: a discipline, not a specialization

The natural instinct is to treat this as an extension of something that already exists — a robotics-security add-on, a safety-engineering appendix, an AI governance sub-clause. That instinct undersells what's actually happening.

Physical AI Security should be understood as an emerging assurance discipline in its own right — sitting between AI decision-making and functional safety, not fully inside either one.

It's not robotics security, which typically assumes deterministic control logic. It's not safety engineering, which addresses malfunction, not adversarial manipulation of a learning system. It's not OT security, which protects the industrial environment but not the AI reasoning operating inside it. It's not AI governance, which stops at the decision and doesn't reach the actuator.

Cybersecurity. Cloud security. Application security. AI security. Each was a response to a genuine shift in what needed protecting. Physical AI Security is the next one on that list — the discipline that treats the full path from perception to physical consequence as a single assurance object.

Kinetic Zero Trust

Kinetic Zero Trust An AI-generated command should never be treated as safe merely because it came from an authorized, high-confidence model. Authority to decide is not authority to act physically. Every command capable of producing physical effect must be independently validated — against operating limits, sensor confidence, environmental state, and human-presence conditions — before it executes.

Enterprise Zero Trust rejected the assumption that an identity or device should be trusted just because it sits inside the network perimeter. Kinetic Zero Trust rejects the equivalent assumption for physical action: a command shouldn't be trusted just because the model that produced it was authorized and confident.

This is likely the most durable idea to come out of the physical-AI assurance conversation this year — independent of which framework, vendor, or standards body ultimately operationalizes it.

What this discipline has to account for

A discipline built around the kinetic gap has to treat as first-class assurance concerns:

• whether sensed input can be trusted, and what happens when sensors disagree
• whether an autonomous system's authority is explicitly bounded, and whether that boundary can be tested rather than merely declared
• whether a technically valid command can still be physically unsafe, and who checks
• whether human override remains fast and authoritative under real operating conditions, not just in a lab test
• what happens when confidence, connectivity, or environmental conditions degrade
• how a physical-AI incident is reconstructed, contained, and safely recovered from before the system returns to service

None of this is abstract. It's the difference between a warehouse robot fleet a CISO can sign off on and one they can't — and between a system an insurer can underwrite and one they can't price at all.

Notably Absent

• No consensus terminology yet exists across the industry for this discipline — "Physical AI Security," "embodied AI assurance," and "cyber-physical AI security" are all in circulation, and none has settled as the standard term.
• No independent body has yet formally recognized Physical AI Security as a distinct discipline with its own standards body, certification infrastructure, or practitioner credential — that recognition, if it happens, will take years, not a publication cycle.
• This Insight does not establish that any specific framework — including ODA3 Institute's own — has solved this problem. It argues that the problem is real and structurally distinct. Which architecture the industry converges on, if any, remains open.

The question that isn't going away

The first generation of AI assurance asked whether we could trust what AI says. The second asked whether we could trust how AI decides. Physical AI asks a harder question: can we trust what AI is allowed to do — in a warehouse, on a road, in an operating room, near a person who has no way to know the system is uncertain?

That question will increasingly define robotics, autonomous mobility, intelligent infrastructure, industrial automation, and every AI system capable of changing the physical world.

ODA3 Institute has proposed one architecture for answering it — PAI-SF™ v1.0, the Physical AI Security Framework, published alongside this Insight. Whether it becomes the reference point the industry converges on will be decided by implementation, evidence, and independent scrutiny over the years ahead, not by this publication date.

The question itself, however, is no longer avoidable.

Read the companion framework release: PAI-SF™ v1.0 — Closing the Physical AI Assurance Gap, covering the 12 domains, 41 controls, and structural design of ODA3 Institute's response to the kinetic gap.

© 2026 ODA3 Pvt Ltd. Published by ODA3 Institute.