In the last article, we followed one attack path through a captured drone: a glitch during boot exposed the firmware, and the firmware showed where to attack the radio link key. On a growing number of platforms, the same path leads somewhere else as well: to the models and data the platform uses to make its own decisions.

This article, written in collaboration with Ido Govrin, looks at what changes when AI runs on the platform itself: which models, decision logic and onboard data a captured system can give away, why securing the link does not protect them, and why AI at the edge belongs in the same capture-aware threat model as keys and firmware.

Ido Govrin is a Programs Associate at the Israel Innovation Institute, responsible for InnovaCyberBridge, a cybersecurity startup program run in partnership with the Institute. He served as a UAV systems operator, giving him firsthand operational insight into drone platforms and how they're used in the field.

‍

AI is becoming a physically deployed asset

Autonomous and semi-autonomous defence systems increasingly perform AI inference close to sensors and mission activity. That improves responsiveness and autonomy, but it also changes where valuable information lives.

Models, parameters, preprocessing logic and surrounding software can embody substantial R&D investment and operational know-how. Once deployed on an embedded platform, those assets may eventually be available to someone with physical access to the hardware.

Protecting the communication channel is not enough

Network security and encryption protect data in transit, but they do not fully address what happens when the computing platform itself is recovered.

An adversary may seek to understand how sensor inputs are processed, what features matter to the model, how decisions are made, how the system responds to environmental conditions or how proprietary algorithms are implemented.

The computing platform therefore becomes part of the AI security perimeter.

AI security intersects with embedded security

AI assets sit alongside the same firmware, credentials, secure-boot mechanisms and interfaces that support the rest of the system.

If hardware security is bypassed, firmware and model-related assets may become more accessible. If software is reverse engineered, it may reveal where models are stored, how they are loaded and which protections are applied.

This makes AI protection an embedded implementation-security problem as well as a model-security problem.

The model may not be the crown jewel

Engineering leaders can begin by identifying which AI-related assets would matter if recovered: model files, parameters, proprietary preprocessing, sensor fusion, decision logic, configuration or training-derived know-how.

Among these, decision logic often deserves particular attention: it does not simply represent engineering investment, but the operational edge itself, and an adversary who understands it does not need to defeat the system so much as anticipate it. Most fielded platforms do not carry decision logic this sophisticated, however, and even where meaningful AI is present, the model itself may not be the most valuable thing to protect. Data the platform carries locally - reference libraries, mission parameters, configuration stored onboard precisely so the system can operate without a live link to ground control - is not incidental to that capability; it is often the more exposed asset, and part of what allows the system to function at the edge in the first place.

Then map how those assets move through the system, where they are stored, where they are manipulated and which security mechanisms protect them.

Security needs to evolve at the speed of autonomy

As more intelligence moves from centralized infrastructure to the edge, more valuable information is physically deployed into potentially hostile environments.

The security model therefore has to evolve with the architecture. AI at the edge should be included in the same capture-aware threat model as keys, firmware and communications.

Coming next: Assume Capture, a security testing framework

Over six articles, we've looked at why capture is realistic, what it exposes and how attacks move across layers. The next article brings these together into five steps engineering teams can work through.

‍