AI agents add new inputs, new tools and new decisions to a drone inspection workflow, so the threat model needs new entries beyond the aircraft itself. The main shift is that text, images and data can now influence what a machine does. Update the model by listing what the agent reads, what it can trigger, and who approves.
What does a typical inspection workflow look like?
A simple pipeline: a crew or scheduler picks a site, a flight plan is generated, the drone captures imagery, software flags defects, and a report goes to maintenance. An AI agent might sit at three points: planning flights, interpreting images and writing work orders. Each point connects a model to something physical or financial.
CISA's Be Air Aware material on unmanned aircraft covers cyber and physical risks, including recognizing UAS threats and applying cyber hygiene, mainly aimed at critical infrastructure owners. It also links to general ICT supply chain guidance. That is the baseline for the aircraft and ground station. The questions below are about what an agent adds.
What changes when an agent is in the loop?
New untrusted inputs. Images, notes in a work order system, vendor documents and map data can all reach the model. OWASP's guidance on indirect prompt injection says content that a model ingests may contain instructions that alter its behavior. An inspection photo with embedded text is a small example of that class.
New tools. If the agent can create flight plans, change geofence settings, edit a maintenance ticket or email a contractor, those are actions with consequences. OWASP's excessive agency guidance recommends minimizing the tools and permissions offered to a model and requiring human approval for high impact actions.
New decisions. If the agent triages defects, a wrong "no issue" can be as costly as a wrong action. Treat model output as advice with a measured error rate.
New dependencies. Agent frameworks, vision libraries and model files join the flight controller, ground station and mobile app in your software inventory. A software bill of materials for the whole system, not only the airframe, is the starting point.
Which standards help?
NIST SP 800-82 Rev. 3 is a guide to OT security and lists transportation systems and other programmable systems that monitor or control physical processes among its scope. It recommends countermeasures that account for performance, reliability and safety. ISA/IEC 62443 covers industrial automation and control systems, with parts for asset owners and product suppliers. Neither is drone specific; use them as the OT backbone and add the agent specific controls above.
For the agent layer, NIST's AI Risk Management Framework organizes work into Govern, Map, Measure and Manage. It is voluntary and general, so pair it with concrete limits on tools and data.
What should you not conclude?
Do not assume incidents are common because the topic is new. We are not citing a specific drone incident here, because the sources we reviewed do not require one. The point is design: reduce what a fooled agent could do.
What to do
- Draw the workflow and mark every place an agent reads or writes.
- List each tool the agent has, and remove any write access it does not need.
- Require human approval for flight plan changes, geofence edits and safety critical work orders.
- Treat images, tickets and documents as untrusted data in prompts.
- Add the agent stack and models to your software inventory.
- Log agent actions in a store the agent cannot edit.
- Test defect triage against labeled samples and track misses.
Quick check
Is the drone itself the main risk?
It stays a risk, but the agent adds risks through its inputs, tools and decisions.
Do I need a new framework for agents?
Usually no. Extend your OT threat model with agent inputs, tools and approvals.
Sources
- CISA: Unmanned aircraft systems
- NIST SP 800-82 Rev. 3
- ISA/IEC 62443 series
- OWASP LLM01: Prompt Injection
- OWASP LLM06: Excessive Agency
- NIST AI Risk Management Framework
Last reviewed: 18 October 2026.
