When the Satellite Starts Thinking: The Cybersecurity Problem of AI in Orbit

Satellite imagery used to travel a long road before anyone could make sense of it. A satellite collected data, sent it down, and only then did compute on the ground classify the imagery, hunt for objects and anomalies, and compare them against prior passes. A human stayed at the end of that chain, turning analysis into a decision.

That chain is getting shorter.

As AI moves onto the spacecraft itself, a satellite moves beyond simply capturing imagery and starts interpreting what it sees, before any of it reaches the ground. It can filter, identify an object, classify an event, prioritize what matters - and, depending on the architecture, eventually act on its own.

On paper this looks like a natural step: less data to downlink, faster decisions, near-real-time access to the information that actually matters.

But something else travels to orbit along with that capability - a layer of interpretive logic that used to live almost entirely on the ground, and that now has to be trusted.

That’s where this gets interesting from a security standpoint. The question is no longer just whether someone can get unauthorized access to a satellite. It’s harder than that: can we be confident the satellite correctly understands what it’s looking at?

The shift is already happening

On September 9, 2026, at the International Space Summit in Paris, Marlan Space and Loft Orbital announced a $1 billion project to deploy a constellation of fifty Earth-observation satellites with onboard AI processing. The stated goal is to analyze what the satellites observe directly in orbit and send down events and alerts, not raw imagery.

Worth separating two layers here. One is the claimed capability, in the consortium’s own language: satellites that will “think, act, and deliver alerts in seconds”. That’s marketing copy, not an independently verified technical fact - and as of this writing, none of the fifty satellites is operational yet; the first launch is planned for October 2026. The other layer is what’s already been demonstrated and documented, independent of this particular project.

And there’s already a fair amount of that. In spring 2026, NASA’s Jet Propulsion Laboratory, working with Loft Orbital, demonstrated an in-orbit vision-language model called NAVI-Orbital, built on Google DeepMind’s Gemma 3 and deployed aboard the YAM-9 satellite. It analyzed imagery and identified objects of interest in response to natural-language queries, without an analyst in the loop on the ground. The system ran on an NVIDIA Jetson AGX Orin, providing the onboard compute needed for the demonstration.

So what once looked like an isolated proof of concept is now moving toward constellations of dozens of spacecraft and billion-dollar budgets. The question isn’t whether this shift happens - it’s how fast the field can catch up on threat modeling once the architecture has already shifted.

When processing becomes decision-making

The classic remote-sensing satellite works like this: sensor captures a signal → spacecraft transmits it to Earth → ground infrastructure processes the data → a human makes a decision. All the analytical work happens off the vehicle, in a controlled environment.

An AI-enabled spacecraft rewires that sequence: sensor → onboard processing → AI inference → decision → spacecraft action → Earth. Increasingly, the human in that loop isn’t looking at raw data anymore - they’re looking at a conclusion the system already reached. Sometimes they’re looking at it after the spacecraft has already acted on it.

Here’s the thesis worth stating plainly up front: decision-making itself becomes part of the attack surface. An attacker used to need control over command execution. Now it may be enough to influence what the system bases its conclusion on - and the fact that a spacecraft is “behaving correctly” from a code-execution standpoint stops guaranteeing much of anything.

A satellite that reasons about what it sees isn’t just running one more piece of software. It’s a system whose compromise no longer has to look like a compromise.

The security boundary has moved

Lay out the full chain of components on an AI-enabled spacecraft - hardware, firmware, flight software, ML framework and libraries, the model itself, its update mechanism, input data, inference, decision, action - and an uncomfortable question follows: which of these does a defender actually trust?

The traditional attack surface already has an established security vocabulary. The Aerospace Corporation built SPARTA (Space Attack Research and Tactic Analysis) for exactly this - an unclassified, ATT&CK-style matrix for the space domain, with tactics and techniques mapped to standards like NIST SP 800-53. Command links, comms, ground stations, authentication, firmware vulnerabilities - all of that already has detection and response coverage.

The AI-related layer is still building its vocabulary. That includes the integrity of training data, the integrity of the model itself, its update mechanism, inference inputs, and the integrity of the decision that comes out the other end. Both space security and AI security already have their own languages for threat modeling - SPARTA for space systems, MITRE ATLAS for attacks on ML. But the two overlap only partially, and it’s precisely at that overlap - where sensor spoofing intersects with onboard model poisoning - that the least-mapped risk sits.

Worth drawing the line clearly here: there are currently no publicly confirmed incidents demonstrating this exact attack path against an operational spacecraft. Everything that follows is threat-modeling territory, built on architectural realities, not a description of known attacks.

What is an IOC for an AI Model?

This is where the more interesting - and least worked-out - part of the problem starts.

For a normal endpoint, a SOC has a settled vocabulary of indicators of compromise: file hash, malicious IP or domain, process tree, a registry change, a persistence mechanism. These are deterministic artifacts - a hash either matches a known-bad list or it doesn’t.

So what’s an indicator of compromise when the compromised component isn’t executing malicious code in any classic sense, but is simply producing wrong conclusions? A model poisoned during training, or one being fed manipulated input, keeps running perfectly legitimate code the whole time. No antivirus or EDR agent is going to fire on that.

The signals here have a different character: an unexpected model-version change with no documented update behind it; an unexplained shift in output distributions; classification anomalies that haven’t shown up before; abnormal confidence patterns; unusual inference latency; suspicious characteristics in the input itself; a divergence between redundant sensors that should be producing the same read; or update activity outside any planned maintenance window.

But this is exactly the point at which professional caution matters. These signals aren’t IOCs in the sense we mean when we say hash or IP address. They’re contextual indicators, not deterministic ones - any single one of them can have a perfectly legitimate explanation: data drift, a seasonal change in the observed scene, a scheduled model update. They only become meaningful in aggregate, and only in the context of a specific mission. Turn them into hard signature rules and you get a flood of false positives.

Operational does not mean trustworthy

Here’s a claim worth saying out loud, because it cuts against how SOC thinking normally works.

A system can be online, transmitting telemetry normally, showing no sign of malicious code, running entirely legitimate software, and triggering no traditional alert - and still be producing the wrong output. Availability isn’t the same thing as integrity.

Two different questions used to collapse into one. Worth separating them:

System integrity - can we trust what the system is executing?

Decision integrity - can we trust the conclusions it’s producing?

That distinction is doing most of the work in this piece.

A spacecraft can stay sound on the first axis while its integrity on the second is already compromised. Traditional incident response answers what process ran, what connection it made, what changed on the host. An AI-enabled satellite adds a different question: what did the system believe it was seeing? And that answer often doesn’t exist in any of the logs we’re used to collecting.

What if the data is the attack?

If the onboard model is ingesting imagery, telemetry-derived information, raw sensor data, or other observations of the environment, a defender has to think not just about the model - but about what the model is being shown.

This isn’t an invitation to turn the piece into an adversarial-ML research paper, but the concept deserves a clear statement: if input is deliberately distorted - physically, electromagnetically, or in software - a model can perform exactly as designed and still produce the wrong conclusion.

Which raises an uncomfortable operational question: if the model is behaving exactly as it should, but its input was manipulated, where does the incident actually begin? At the point the signal was distorted, at the point of inference, or at the point the system acted on a flawed conclusion? A classical incident-response model, built around “something broke”, doesn’t have a good way to ask this question, let alone answer it.

When the model becomes evidence

There’s another layer to this that a classic IR checklist doesn’t anticipate.

The classic forensic question is: what did the process execute? The AI forensic question is: what did the system perceive, what did the model conclude, and what action followed from that conclusion?

Reconstructing an incident on an AI-enabled spacecraft means answering what version of the model was running at the time, when and by whom it was last updated, what input it received, what it concluded and with what confidence, and what commands the spacecraft executed after inference. Reconstructing the incident means reconstructing not just what the system did - but what it perceived.

Fine. If traditional IR can’t see any of that - what should we actually be collecting?

Telemetry is no longer enough without context

A classic SOC is built on three sources: endpoint telemetry, network telemetry, identity telemetry. None of them answer the question above.

To reconstruct not just what the system did but what it perceived, a different set of artifacts is needed: the model’s version and hash at the time of the event, the provenance of the last update and who signed it, and the raw inference logs themselves. Beyond that, a SOC needs the distribution of outputs and the model’s confidence in each conclusion, the provenance of the input the model actually received, and cross-validation against redundant or neighboring sensors that should have produced the same measurement. It also needs the full chain from decision to the action the spacecraft actually took; the ability to roll back to a previous, trusted model version; immutable telemetry that can’t be rewritten after the fact; and ground-side correlation that lets an onboard conclusion be checked against an independent source.

No SOC pipeline today collects all of that systematically.

The problem isn’t a shortage of logs - there’s no shortage of logs in space telemetry. The problem is that without this set of artifacts, a SOC can’t answer even the simplest version of the question: can we actually prove the spacecraft saw what its conclusion says it saw?

Worth stating this one directly: if we can’t reconstruct what the model perceived and why it reached a given decision, we don’t have a complete incident response - no matter how much endpoint and network telemetry we’re sitting on.

The harder question

Space cybersecurity has spent years learning how to answer one question: how do you protect the spacecraft?

A different question is showing up now: can we trust what the spacecraft sees, how it interprets it, and what it decides to do based on that interpretation?

For a SOC analyst, the most dangerous endpoint isn’t necessarily the one that stops responding. It may be the one that keeps operating normally - while quietly producing the wrong answer.