Regulated Data in Orbit

Executive summary

Existing data protection and cybersecurity frameworks can apply to orbital computing. What orbit changes is how hard it is to identify accountable parties, govern distributed data flows, and verify safeguards on infrastructure that is intermittently connected and cannot be physically inspected. For hospitals, banks, and federal agencies, that verification gap is a likely barrier to adopting orbital services.

This paper maps HIPAA, GDPR, and FedRAMP, plus adjacent obligations, to two orbital data paths: one for data uploaded from the ground, and one for data collected in space. It proposes a policy enforcement and evidence architecture with three capabilities: a policy decision before each action, enforcement where the action executes, and records an auditor can verify independently. Later sections extend this into a five-step assurance lifecycle that begins with establishing what the law actually requires.

The model is staged. Ground enforcement covers data ingest, API access, and commands before uplink, and can be built with existing infrastructure. Onboard enforcement is needed for actions satellites take on their own while out of contact. The paper separates current legal requirements from proposed rules and from our own design recommendations, and names the questions that still need independent validation.

What exists today and what is proposed:

State of play, October 2026

Orbital computing is no longer hypothetical, but it is still at prototype scale, and heat and power are the binding constraints.

• Hardware in orbit. Google's first Project Suncatcher prototype launched on October 1, 2026; Google confirmed contact and reports it is operating as expected (Google). It was reported in advance to carry four TPUs planned to run short workloads in bursts of about 15 minutes, then pause to cool (Ars Technica via Digg). Reaching orbit is not the same as validated performance: sustained throughput and thermal results are not yet published. Starcloud flew an NVIDIA H100 in November 2025 (Introl).
• Policy movement. The NEW HORIZON Act (S. 4693, introduced June 4, 2026) would create a Defense Department pilot for commercial orbital data center services, including safeguards for workload isolation, tenant separation, and data sovereignty (govinfo). The FCC adopted a new space and earth station licensing framework in 2026, and the Office of Space Commerce opened a pilot certification program for novel in-space activities, including orbital data centers (WilmerHale).
• Regulated workloads. This review identified no publicly documented large-scale regulated workload in orbit. Private deployments cannot be ruled out from public sources.
• Space-native processing already flies. ESA's Φsat-2, launched in August 2024, runs AI applications onboard, including maritime vessel detection, and its apps can be installed and updated from Earth (Open Cosmos). It is the closest public example of the space-native path this paper focuses on, though not of legally authorized regulated processing or of a multi-tenant orbital data center. ESA also chose during commissioning to release Level 1 image products to users rather than only onboard AI results, so the mission is a processing reference, not evidence that raw-data release can be prohibited.

Why orbit strains existing controls

The rules still apply in orbit. What breaks are the assumptions compliance teams rely on to show the rules are met.

Jurisdiction over the spacecraft and the law governing its data are separate questions. Under Article VIII of the Outer Space Treaty (1967), the state of registry retains jurisdiction and control over a space object. That does not by itself decide which data protection laws apply; those depend on who the controller, processor, or covered entity is and where each operates.

Several legal claims can attach to the same dataset at once. Some follow the spacecraft, some follow the provider, and some follow the data subject or customer:

No single basis resolves every overlapping claim.

Practical control can also drift from legal jurisdiction when command paths, ground stations, or operators change after launch. One proposal, a "digital flag state," would treat data on a properly secured, U.S.-registered satellite as subject only to U.S. law while in orbit, conditioned on cryptographic proof the hardware has not been tampered with (Bloomberg Law commentary, February 2026). It is a policy proposal, not law. Notably, it would make verifiable attestation evidence, the subject of this paper, the condition for legal certainty.

When regulated processing in orbit is rational

Orbit adds residual risk, contact gaps, and duty-cycle limits. A regulated customer should accept them only when processing in orbit does something downlinking cannot. For most regulated workloads, it does not.

A candidate becomes a decision only after a documented benefit and the feasibility assessment described in the control model.

The strongest regulated case is data born in space that becomes regulated because it identifies people or carries national security restrictions. Processing it in orbit can improve privacy when it reduces what is downlinked. That is where verifiable controls matter first. The benefit holds only if the minimization itself is verifiably correct and what is downlinked is the minimum necessary; the classification failure scenario in the enforcement coverage section shows how it can fail.

Reference orbital data architecture

Regulated data follows one of two paths. Path A, shown below, covers data uploaded from the ground: ground controls can govern three of its five stages today, and the other two need onboard enforcement. Path B, data collected in space, follows.

Path B: space-originated data. This is the path the paper considers most compelling, and the obligation can arise when the sensor captures the data, before any API call or transmission:

Crosslinks, replication, customer access, and onward delivery can occur in either path. Ground enforcement cannot prevent the initial collection or the first onboard transformation of sensitive sensor data, so Path B needs an onboard control (Phase 2 or an equivalent trusted onboard mechanism) from the start, not as a later addition. Observations that are unclassified or ambiguously classified are treated as restricted until classified.

Three authorization decisions. Classification after capture cannot retroactively authorize the capture itself. Path B therefore needs three separate decisions:

1. Before capture, tasking authorization: may this sensor be used, for this purpose, under the applicable operating conditions and collection restrictions?
2. After capture, classification and containment: what was actually collected, and until classification is reliable, where may it be stored, processed, or disclosed?
3. Before release, output authorization: does this specific output satisfy its disclosure, destination, minimization, and recipient conditions? This decision is bound to the specific artifact and its verified metadata, not inherited from the approval of the original job, because the legal character of an onboard AI output may not be known at tasking time.

Remote-sensing authorization. Remote-sensing licensing and data protection law govern different but overlapping aspects of collection. Mission authorizations may constrain sensor operation, collection capabilities, and distribution, while privacy laws such as GDPR, which counts collection as processing, can govern whether personal data may be collected at all. Both must be assessed before a sensing task executes. For U.S.-jurisdiction private systems, NOAA's Commercial Remote Sensing Regulatory Affairs office licenses operations under 15 CFR Part 960. Changing a material fact listed in a license without first receiving a modification is a violation, and ground components that receive or preprocess data can themselves be material facts (NOAA CRSRA). So tasking, onboard processing changes, distribution, and even adding a ground station may need checking against license conditions. The gate checks tasking against the license's existing authorized operating envelope; this does not imply regulators approve individual captures. Applicability is specific to each operator and jurisdiction; these rules are an example, and do not govern ESA's Φsat-2.

API data transfers

Most regulated data will not move because an AI agent decided to move it. It will move through ordinary API calls: a hospital system uploading records, an application querying results, a partner pulling outputs. Not every API request is a legal transfer, but each is a point where a gate can check who is asking, what data is involved, and where it is going.

Two requirements are specific to APIs. Identity must be machine identity (API keys, mutual TLS certificates, OAuth clients) tied to an accountable organization. Evidence must record each call's caller, data, destination, rule applied, and outcome, so an auditor can reconstruct any transfer.

Contact windows and jurisdiction-aware scheduling

A low Earth orbit satellite passes over any given ground station only a few times a day, for minutes at a time. When regulated data is ready to move, the next station in view may not be an approved one. Operators then face three choices, and the gate must decide among them:

The same applies to uplink: customer data may need to wait on the ground until the satellite passes over an approved station.

Waiting can conflict with deadlines. A GDPR access or erasure request, a breach investigation, or a contractual delivery commitment may require action before the next approved pass. The scheduler should know these deadlines, and the policy should state which wins. An erasure command that carries no regulated data may be able to use a wider set of stations, but every telecommand path still needs authentication, replay protection, approved access, and spectrum and operational permissions, which CCSDS treats as core space link security objectives.

Visibility can be forecast from orbital mechanics, but usable contact also depends on failures, contention, antenna availability, interference, and, for some links, weather. Each evidence record should show which option was chosen and why. When no compliant route exists before a deadline, the response is defined in advance: notify the customer, defer, or obtain an authorized change in requirements, and never silently fall back to an unapproved route.

Binding scheduling to the gate. The scheduler is not a side system. Its chosen window and station are inputs to the policy decision: the gate checks, at decision time, that the station satisfies the data's location and partner constraints, and the evidence record captures the contact plan the decision relied on. If a later conjunction, weather outage, or partner change invalidates a window after the workload was accepted, feasibility is re-evaluated and the predefined response applies. Partial or opportunistic contacts are used only for actions whose authorization and evidence can complete within that contact; anything that cannot is deferred or recorded as unverified.

Interrupted transfers. A transmission can start successfully and end before the full dataset, authorization state, or receipt is exchanged, leaving a transfer partly executed and unverified. Each transfer therefore moves through explicit states: authorized, started, partially sent, received, and verified. Not every transfer reaches verification; interrupted ones need defined recovery, expiry, and unresolved-outcome handling. The implementation should use chunk-level integrity checks, resumable transmission, replay protection, idempotent retries, and recipient acknowledgments, and must re-check authorization when a transfer resumes under changed conditions. A ground station receipt alone does not show that the intended dataset arrived intact; end-to-end content digests support that narrower claim.

Worked example (illustrative, Path B). A European environmental agency commissions a satellite operator to capture and process coastal imagery onboard for a pollution response. Before collection, a privacy assessment finds that some imagery of vessels and coastal property is personal data where it is reasonably linkable to identifiable people; property or vessel identification alone does not automatically make it so. The agency documents a lawful basis (GDPR Article 6) and completes a data protection impact assessment (Article 35). The contract allows onboard processing only if raw imagery is never downlinked, only minimized products (such as vessel-count polygons, reviewed for re-identification risk) are returned, those products go only through two approved EU ground stations, and they arrive within 6 hours.

1. When the tasking is accepted, both approved stations have usable windows inside 6 hours. The workload is admitted, and the feasibility decision and constraints are recorded.
2. A conjunction forces a collision-avoidance maneuver that cancels the first station's only compliant window. The second station reports a weather outage that pushes its next pass past the deadline. No approved station can now meet both constraints.
3. The system defers or rejects the delivery, or seeks a renegotiated deadline or an additional approved station. It refuses to route the product through a non-approved station, even though that would meet the clock.
4. The evidence record cites the original constraints, the updated contact schedule, and the decision. The raw imagery stays onboard or is queued for cryptographic erasure under the disposal policy.

The agency receives a clear notice that both constraints cannot be met, instead of a late delivery or an unauthorized downlink. The collision-avoidance maneuver proceeds on its own safety authorization throughout.

HIPAA mapping

HIPAA does not prohibit storing protected health information (PHI) outside the United States, including in orbit. The questions are which parties are business associates, and whether Security Rule safeguards can be shown to hold.

Open question. HHS treats transmission-only services with transient storage as conduits, but says cloud providers that maintain ePHI are not conduits (HHS cloud computing guidance). An orbital compute provider is almost certainly a business associate. Whether a relay satellite that briefly buffers data in transit qualifies as a conduit has not been addressed.

Pending change. HHS proposed a Security Rule update in January 2025 that would make encryption of ePHI at rest and in transit mandatory and require covered entities to verify business associate safeguards. OCR missed its May 2026 target, and in July 2026 moved the rule to its long-term actions with a projected final action date of July 2027, a planning target rather than a commitment (Holland & Knight). This paper treats those requirements as design recommendations, not current law.

GDPR mapping

GDPR applies to orbital processing the same way it applies anywhere. Two questions must be kept separate: whether GDPR applies to the processing at all (Article 3), and whether a given data flow is an international transfer (Chapter V).

Open question. We found no regulator guidance on how the state of registry, the operator's establishment, and ground station locations interact for data processed in orbit. Even where no Chapter V transfer occurs, the EDPB notes that processing outside the EU can still carry increased risks the controller must address (EDPB Guidelines 05/2021).

FedRAMP mapping

FedRAMP certifies cloud services for federal agencies. Its Consolidated Rules for 2026, launched June 25, 2026, move the program toward machine-readable, continuously verified security evidence, and become mandatory on January 1, 2027. That shift suits systems that cannot be inspected in person, provided they can produce evidence automatically. We know of no orbital service that holds a FedRAMP certification. Certification also does not mean an agency has accepted every operational risk; each agency still decides whether to use a certified service.

Open question. FedRAMP has not addressed whether a U.S.-registered satellite counts as a location under U.S. jurisdiction for SA-9(5), and no guidance yet covers intermittently connected infrastructure. Approved ground infrastructure and partner screening reduce jurisdictional exposure, but cannot establish the legal classification of processing or storage onboard the spacecraft. Where that classification matters, operators should seek an agency determination, an approved interpretation, or an alternative architecture.

Adjacent regulatory obligations

Other regimes may apply depending on the data, the customers, and the parties involved. They are listed here for applicability, not analyzed in depth.

Other national data protection laws, such as China's PIPL, India's DPDP Act, and Brazil's LGPD, also attach to the data subject or the data handler and set their own cross-border conditions. Smaller states have little practical ability to supervise data processed on foreign-registered satellites, a sovereignty concern these controls can document but not resolve.

Because no single party controls the whole data path, each obligation needs a named owner. The shared responsibility matrix in the control model section assigns them.

Cross-framework gaps and open questions

Three problems appear in all three frameworks: location, accountability across many parties, and evidence from systems no one can inspect.

• Location. Does data in orbit have a legal location? Candidates are the state of registry, the operator's home country, the ground track below, or none.
• Shared responsibility. Who is accountable when compute, relay, and ground station operators are separate companies?
• Autonomous action. When an AI agent moves data or issues commands, which party approved it, and where is the proof?
• Evidence. What counts as acceptable audit evidence for hardware that cannot be physically inspected?
• End of life. Does deorbit satisfy secure disposal, or must data be cryptographically erased first?

These questions need answers from HHS, EU data protection authorities, and the FedRAMP program office. Until then, operators that can show verifiable control will be better placed to earn regulated customers.

Related work and how this paper differs

Others have named this problem, and two patents cover location-aware routing and storage in satellite networks. Enforcing policy at an API or tool-call boundary is not new in itself. The contribution here is moving from location-aware routing to evidence-backed enforcement: linking each decision to a specific obligation, and to records an auditor can verify.

Several existing standards are building blocks to integrate, not reinvent: NIST SP 800-207 separates policy decision points from enforcement points; Open Policy Agent provides policy evaluation, testing, and decision logging; SPIFFE defines workload identity across trust domains; IETF RATS (RFC 9334) defines attestation roles; W3C PROV-O models data provenance; and CCSDS Space Data Link Security protects space links. The contribution proposed here is the assurance layer that connects legal authority, enforcement, and independently verifiable evidence across them. ESA's Φsat-2 is the most relevant operational precedent for space-native processing and a candidate reference architecture for the demonstration; it is an architectural precedent, not validation of the platform proposed here. SpaceTEE (Michalevsky, 2017) is earlier, separate research proposing CubeSats as tamper-resistant hosts for secure computation. Implementers of location-based routing should obtain a freedom-to-operate review given the patents above.

Policy authority: from obligation to executable rule

Enforcing a policy does not prove the policy is legally correct. If a configuration wrongly exempts a ground station from a contractual restriction, the system can perform flawlessly while the organization breaches its obligation. Policy provenance matters as much as action provenance.

Each enforceable rule should carry its legal or contractual source, the parties it applies to, its factual assumptions, the interpretation adopted, the approving authority (for example, counsel), effective dates and exceptions, and its version history. Two further requirements:

• Conflicts. HIPAA, GDPR, export controls, DOJ rules, and contracts can impose different requirements on the same action. Ranking is not enough, because some obligations require action rather than restraint: a lawful retention duty can limit a valid erasure request, as GDPR Article 17(3) recognizes. Each rule therefore yields one of five outcomes (permit, prohibit, require action, defer, or escalate), with a named accountable authority for resolving conflicts. Absent a determination, the default for regulated data is to defer or escalate, never to silently apply the least restrictive rule. When that default overrides a less restrictive term the customer expected, the override, the competing rules, and the reason are recorded as evidence.
• Unresolved law. A rule can be marked legally unresolved rather than forced into an artificial allow or deny. For regulated data, unresolved rules default to deny or escalate, and are reported.

Technical controls can demonstrate facts. They cannot resolve unsettled law.

With policy authority added, the model becomes a five-step assurance lifecycle. This is a proposed architecture, not a description of the current product:

1. Establish the obligation: law, contract, interpretation, accountable approval.
2. Establish the facts: data lineage, identity, delegation, location, recipient, trusted system state.
3. Decide and enforce: constrained authorization at an enforceable boundary.
4. Witness and verify: execution record, independent corroboration, attestation, evidence quality.
5. Resolve and improve: exception handling, incident response, remediation, policy change.

Enforcement coverage and data lineage

A complete record of observed actions is not proof that all actions were observed. Assurance needs two separate demonstrations:

• Decision correctness: given a valid policy and accurate inputs, the system made the right determination.
• Enforcement coverage: no path can move, disclose, process, or destroy protected data without passing through that determination. This means enumerating every relevant path, including privileged commands, firmware operations, recovery modes, emergency overrides, direct storage access, and every communications interface. Coverage is much harder to show than correctness, especially on autonomous hardware. Coverage evidence would take the form of a signed enumeration of every control point in a specific flight software baseline, plus negative tests showing that each path outside that list cannot move protected data.

Authorization bound to execution. Approvals should be short-lived and bound to a specific actor, operation, destination, dataset, and expiry, so a change in any of them between approval and action invalidates the approval. For Path B, no dataset exists at tasking time, so a pre-capture authorization binds the sensor, target area, time window, purpose, mission conditions, policy version, and authorized operator instead; a separate release authorization later binds the resulting artifact. When an AI agent acts for a person or organization, its authority should be scoped, time-limited, tied to an accountable principal, and revocable.

Data lineage. Obligations survive transformation. A provenance graph (the W3C PROV-O model is a suitable basis) should record how each dataset, derived output, and artifact was produced, with tested rules for when obligations propagate and when de-identification or reclassification is valid. For AI workloads this includes model weights and fine-tunes trained on regulated data, embeddings, inference logs, and outputs, any of which may carry or leak regulated information. If an artifact is later found to contain regulated information, copies may already sit on several nodes that are out of contact, and erasing large artifacts under storage and thermal limits is a distinct problem. Artifacts therefore carry the same erasure queue and completion records as source data, and stay unresolved until every copy is confirmed erased. For large artifacts on nodes out of contact, cryptographic erasure by destroying their keys may be the only feasible option, and the record of that action must itself survive the same contact constraints.

Telemetry and metadata. Spacecraft telemetry, health logs, and link-layer metadata can reveal regulated information, such as when a dataset was processed or where results were sent. These streams are in scope: tagged, minimized, and subject to the same retention and erasure rules.

A failure scenario. A healthcare workload in orbit produces a derived dataset with no direct identifiers that is still identifiable through linkage. It is tagged unrestricted, and an autonomous scheduler sends it to an approved partner. Every API call succeeds, every authorization is logged, and the evidence chain is intact. The control failed earlier, at the classification boundary. Lineage and reclassification rules must be tested, not assumed.

Demonstrating coverage. A coverage claim is built from five artifacts, staged like the rest of the model:

Until onboard enforcement exists, any coverage claim must be scoped to ground-enforced actions only. Together, these artifacts form the coverage portion of the Orbital Compliance Evidence Validation Package.

Proposed control and evidence model

The model separates three capabilities, each assessed on its own: deciding whether an action is permitted under a defined policy, enforcing that decision where the action executes, and producing evidence an auditor can verify. An approved decision is not proof the action happened as approved, so decisions must be reconciled with execution records.

Admission-time feasibility. Correct decisions on individual actions are not enough if the provider accepts a workload whose obligations it cannot meet. If every approved station becomes unavailable before a delivery deadline, the gate can correctly deny every unapproved downlink, and the provider can still fail its commitment. Before accepting or generating a regulated workload, the system should assess whether its processing, delivery, retention, and erasure commitments are achievable under stated assumptions: contact availability, link capacity, processing resources, deadlines, permitted destinations, and contingency routes. A workload shown feasible within those bounds is accepted with documented assumptions, reserves, and contingencies; one that is not is rejected, deferred, or renegotiated. Feasibility is re-evaluated as conditions change. It is an evidence-backed assessment, not a guarantee.

Where enforcement happens determines what can be guaranteed:

Environmental envelope. An onboard gate runs in conditions ground systems never face, and each one forces a design choice:

Emerging work supports this direction, though its security claims have not been independently validated. Space Fabric, published in March 2026, proposes generating signing keys on board after launch and binding workload execution to a specific satellite through a quorum of independent ground stations, certifying both what code ran and where (arXiv 2603.23745). Ordinary cloud attestation assumes reachable hardware and a vendor attestation service; neither transfers cleanly to orbit. The published Space Fabric implementation is a terrestrial prototype (a USB Armory Mk II with ARM TrustZone); validation in orbit, under radiation, thermal stress, and long outages, is still required.

An onboard gate is therefore trustworthy only within stated limits. Each design must specify its mission-specific environmental operating envelope, how faults are detected, how it recovers, and how evidence is preserved, with a safe operating mode whenever policy integrity cannot be established. A failed compliance subsystem must never disable flight-critical functions: safety operations and regulated data operations need separate authorization and failure-handling policies.

Phase 2 raises design questions a satellite systems engineer will ask first. Each has a proposed choice and a tradeoff to test:

Residual risk remains if the attested environment itself is compromised or the gate is bypassed below the driver layer; the residual risk section addresses this.

These mechanisms keep onboard decisions within a bounded, previously authorized policy set, and make prolonged divergence detectable. The policy-object hand-off is explicitly Phase 2 interface work and is not specified here: binding a ground-approved policy object to the onboard measurement, refreshing partial state during short contacts, resolving conflicts after extended outages, and the distribution format.

Shared responsibility. No single party controls the whole path, so each control needs an owner, an operator, and an evidence producer:

These are proposed allocations, not universal legal assignments; the exact owner varies by mission.

Each control also needs named roles, because independent verification does not transfer legal accountability away from the party responsible for the regulated activity:

What exists today, and what is proposed. My Compliance Citadel enforces policy for AI agents on the ground at the tool-call boundary, using regulation-specific compliance packs and hash-linked audit chains. Applying the same decision layer to orbital API traffic and pre-uplink commands is a proposed adaptation (Phase 1). Onboard enforcement (Phase 2) is future work.

Evidence: what each record proves

A signed record proves it was not altered after signing. It does not prove the reported facts were true: if a compromised satellite reports using an approved ground station, signing that report does not make it correct. Evidence must therefore link four things: the obligation, the decision, the executed action, and independent confirmation.

An illustrative decision record (not actual product output):

A Path B mission produces two linked records, because approval and capture may be hours apart and the spacecraft executes the task autonomously:

Two signed approvals are not proof that capture and processing happened as authorized. The full Path B chain links five records:

1. Tasking authorization: permission before capture.
2. Capture execution: evidence that the specified sensor actually operated as tasked.
3. Processing and classification: measured software state, the resulting artifact, its lineage, and its classification.
4. Artifact-specific release: the decision against the actual output and its handling restrictions.
5. Delivery and reconciliation: end-to-end integrity, recipient acknowledgment, and independent verification.

Together these support verification of specific controls. They do not by themselves establish comprehensive legal compliance.

What the model does not establish. Execution assurance is not a guarantee of trustworthy results. A vessel-detection model can run correctly inside an attested environment and transmit only authorized results, yet still identify people unexpectedly, miss vessels, or misclassify them. Four assurance dimensions are distinct:

The model does not independently establish scientific accuracy, model reliability, or the safety of decisions made using the output.

Corroboration during long outages. Sequence numbers alone are not enough if radiation can corrupt the storage holding them. Three practices close most of the gap: write evidence to redundant, error-corrected storage; send the latest hash of the evidence chain to the ground at every contact, so later tampering or loss is detectable against that anchor; and compare self-reported position and activity with independent ground tracking, multi-station endorsement, and partner receipts.

Lost records are not clean records. Any period that cannot be verified, whether from corruption, loss, or a gap in the chain, is reported as an unverified period, never as a period with no violations. Regulated data actions during that period are treated as unresolved until reconciled.

Evidence completeness needs trusted event capture, protected counters or checkpoints, durable storage, independent observations, and reconciliation of authorizations with executions. Every regulated action ends in one of four verification states:

These classifications describe the verified state of individual controls, not a determination of overall legal compliance. A conforming routing decision can still breach another obligation, and a blocked action can still require incident review.

Unverified periods and notification clocks. An unverified period is not by itself a breach. It should trigger a prompt breach risk assessment, because HIPAA measures its notification deadline from when a breach is known or reasonably should have been known, and GDPR from when the controller becomes aware. Escalation must not depend on reconnection, because the next contact may never come. Three triggers are distinct: a contact anomaly (an expected contact or heartbeat is missed) starts investigation and customer notice under agreed thresholds; an evidence gap (the spacecraft reconnects but cannot account for a period) is reported as unresolved; and a suspected security incident or breach follows incident response and legal assessment. A communications outage is not automatically a personal data breach.

Independent verification. A provider that creates, signs, stores, and verifies its own evidence controls too much of the process. The IETF RATS architecture (RFC 9334) separates the system making claims, the verifier, and the relying party. Verifiers in a separate trust domain are what give the evidence its value.

Machine-readable evidence. Records should be exportable in assessor formats, for example mapped to NIST OSCAL assessment results, so continuous monitoring tools can ingest them directly. A lightweight schema is part of the planned validation package.

A concrete government workflow. FedRAMP's 2026 rules replaced the traditional System Security Plan with a Security Decision Record, a maintained record of security decisions that providers must supply in both human-readable and JSON formats (FedRAMP). An evidence package like the one proposed here could help populate applicable Security Decision Record content and related assessment results. Generating these records does not by itself establish FedRAMP certification.

Beyond audits. The same records may be needed in civil disputes or insurance claims, for example when an unverified period coincides with a reported loss. They should preserve chain of custody, trusted time sources, and independent verification so they are usable as evidence, not only as audit artifacts. Admissibility is ultimately for courts and adjudicators to decide.

Evidence is itself sensitive. An audit record can reveal patient-related activity, customer identities, mission details, or processing patterns without containing the underlying data. An immutable audit trail is not automatically a lawful one. The evidence design should separate cryptographic commitments from sensitive record content, apply independently approved retention rules, support authorized access and lawful deletion, and preserve proof of integrity without retaining more personal data than necessary.

Demonstration scenario

The demonstration is split by path, because the two are not equally implementable today:

Path A scenario. A regulated customer authorizes orbital processing but limits delivery to approved destinations:

1. The customer uploads a dataset carrying its legal and contractual policy attributes.
2. The mission scheduler requests a downlink through an approved U.S. ground station.
3. The policy layer allows it and writes a signed decision record.
4. The route changes to an unapproved partner station.
5. The gate blocks or queues the request, records the violation, and names the approved alternative.
6. An auditor verifies decision records, policy versions, execution receipts, and checks for missing events.

Path B scenario. A tasking request is checked against collection authority and license conditions before capture. The sensor captures imagery, and an onboard classifier labels the observations, treating ambiguous ones as restricted. An onboard model produces a minimized product with its lineage recorded. Release requires an output authorization bound to that specific artifact and its verified metadata, and delivery goes only through an approved station, with evidence reconciled at the next contact.

The simulation then runs an adversarial test suite, each test checked against the evidence an auditor would examine:

Each test runs against a baseline of an existing policy engine with ordinary audit logging, and reports enforcement coverage, correct decisions, false denials, missed violations, unresolved outcomes, detection and remediation times, system overhead, and which results independent assessors can reproduce. Success also needs commercial criteria: measurably less time to prepare an assessment package, violations detected that conventional logging misses, and clearer separation of verified from unresolved activity. These gains are weighed against integration work, onboard processing overhead, added contact bandwidth, policy maintenance, and false denials. The system must be both more verifiable and worth integrating.

These are proposed laboratory targets, not demonstrated performance or certification criteria. Also measured: decision latency, behavior under disconnection, and time to produce an assessment package. Every decision is reconciled against an execution record, because an allowed decision alone does not show the downstream system acted on it. Phase 2 validation would add hardware-in-the-loop tests and radiation and thermal qualification against the mission's environmental envelope; those cannot be demonstrated by simulation alone.

The milestone that matters most is one complete chain, from obligation to decision to execution to evidence, demonstrated end to end, including what happens when the underlying system fails. The planned deliverable is an Orbital Compliance Evidence Validation Package: sample decisions, authorization-to-execution reconciliations, injected failures, test outcomes, and unresolved cases. Each tested claim is traced through a short claim-argument-evidence matrix: the claim, its assumptions, the evidence, known counterexamples, the conclusion, and the independent assessment result. Findings and residual risks can be expressed in NIST OSCAL assessment results for machine-readable review.

Residual risks

Even with Phase 1 working and Phase 2 built as proposed, some risks remain. Regulated buyers should price these in:

Beyond orbit: verifiable governance of autonomous systems

Orbit is an extreme case of a general problem: organizations remain legally accountable for actions taken by systems they do not continuously supervise. Enterprise AI agents raise the same questions of identity, authority, action, and proof.

NIST launched its AI Agent Standards Initiative in February 2026, alongside an NCCoE concept paper on applying identity and authorization standards such as OAuth and SPIFFE to software and AI agents (NIST). Defense systems operating under interrupted communications, financial institutions accountable for third-party providers under DORA, and healthcare AI handling derived data face the same pattern. Three communities are natural partners: groups developing agent identity and authorization profiles (SPIFFE, OAuth, and emerging agent-specific extensions); insurance and litigation teams, who will rely on chain of custody and independent verification; and flight software and CCSDS groups, since enforcement coverage ultimately needs control points inside existing command and data-link stacks.

For My Compliance Citadel, this is the near-term path: agent tool-call enforcement is operational today, so the assurance principles in this paper can be validated on terrestrial agents before orbital markets mature.

One policy question deserves attention regardless. Should proving where and how computation occurred change which jurisdiction's laws apply, as the digital flag state proposal suggests, or should it only help demonstrate compliance with laws that already apply? Strong attestation should not become an argument for avoiding privacy protections, lawful-access obligations, or the rights of the people whose data is processed.

Next steps and collaboration

Many regulated workloads will stay on the ground, where mature cloud compliance programs already exist. Orbit is likely to make sense first for data that originates in space or needs processing near the sensor. That shapes who needs this framework now and who needs it later:

• Near term: orbital infrastructure developers, ground station networks, mission software providers, and regulated organizations evaluating satellite-connected systems.
• Longer term: healthcare, financial services, and government organizations considering regulated computing or storage in orbit.

We are seeking design partners to run the demonstration scenario against real systems:

• Orbital data center operators preparing to serve healthcare, financial, or government customers.
• Regulated buyers evaluating orbital compute and defining what evidence they would require.
• Legal and policy experts in space law and data protection to resolve the open questions above.

This paper is for discussion and does not constitute legal advice. It distinguishes current legal requirements from proposed rules and from our own design recommendations. Organizations should confirm requirements with qualified counsel.

Appendix: contract and RFP checklist

A short list buyers and providers can lift into agreements or requests for proposals:

Require now (contractual terms and ground controls that can be specified today):

• Each party in the data path is named, with its legal role (controller, processor, business associate, conduit) assessed and documented.
• BAAs, standard contractual clauses, and DOJ Data Security Program screening are in place for every party that qualifies.
• Data is classified and tagged at ingest; unclassified regulated data is treated as restricted.
• Approved ground stations, relay partners, and jurisdictions are listed, with a process for changes.
• Partner ownership changes trigger notice and rescreening.
• A signed inventory of the ground enforcement points actually implemented, with negative-test results for those interfaces, and an explicit list of unimplemented or unobservable paths marked as Phase 2 or residual gaps.
• Decision records link to named, versioned policies and are reconciled with execution receipts.
• Scheduling decisions (chosen window and station, feasibility assumptions, and later invalidations) are recorded in the same evidence chain as other policy decisions.
• Escalation does not wait for reconnection: a missed expected contact triggers investigation and customer notice under agreed thresholds, an unaccounted period found on reconnection is reported as unresolved, and suspected incidents follow incident response and breach assessment.
• A disposal strategy covers cryptographic erasure, key revocation or destruction, evidence retention, and reporting when erasure cannot be confirmed.
• Insurance availability, exclusions, and limits are reviewed before indemnities are agreed.
• Residual risks from the table above are acknowledged and allocated.

Require demonstrated before accepting Path B workloads or relying on onboard enforcement (not yet deployable):

• Onboard policy decisions use protected counters and detect rollback.
• Evidence chain checkpoints are anchored on the ground at every contact.
• The onboard environment's attestation and its validation results are provided.
• Regulated data actions fail closed when policy integrity cannot be established, without affecting flight-critical functions.
• Onboard classification of space-originated data, with defined handling of uncertain observations.
• Pre-capture tasking authorizations and artifact-specific release authorizations, linked in the evidence chain.
• Onboard enforcement coverage demonstrated with negative tests on a flight-representative software baseline.

Sources

Legal authority and official guidance

• Outer Space Treaty (1967), Articles VI and VIII
• Convention on International Liability for Damage Caused by Space Objects (1972)
• CLOUD Act, 18 U.S.C. 2713
• HIPAA Privacy, Security, and Breach Notification Rules, 45 CFR Parts 160 and 164
• HHS, Guidance on HIPAA and Cloud Computing (October 2016)
• GDPR, Regulation (EU) 2016/679
• EDPB, Guidelines 05/2021 on the interplay between Article 3 and Chapter V, version 2.0 (February 2023)
• EU AI Act, Regulation (EU) 2024/1689
• FedRAMP, Consolidated Rules for 2026 launch announcement (June 25, 2026)
• FedRAMP, Rev5 control guidance, SA-9(5) parameters (2026)
• DOJ Data Security Program, 28 CFR Part 202 (effective April 8, 2025)
• S. 4693, NEW HORIZON Act (introduced June 4, 2026)
• U.S. Office of Space Commerce, EU Space Act Update (May 2026)

Legal and industry analysis

• WilmerHale, Not Just Science Fiction: The Legal Reality of Orbital Data Centers (October 1, 2026)
• Bloomberg Law, Digital Flag State Rule Would Give Space Law a Regulatory Boost (February 2026)
• Space Fabric: A Satellite-Enhanced Trusted Execution Architecture, arXiv 2603.23745 (March 2026)
• Michalevsky, SpaceTEE: Secure and Tamper-Proof Computing in Space using CubeSats (2017)
• White & Case, DOJ Issues Guidance on Bulk Sensitive Data Rules (2025)
• White & Case, Regulating Space: The Proposed EU Space Act (2026)
• LuxSci, The HIPAA Security Rule Missed Its May Deadline (June 2026)
• Holland & Knight, HIPAA Security Rule Amendments Now Projected for July 2027 (July 6, 2026)
• Open Cosmos, Phisat-2 launch (August 2024)
• ESA, Φsat-2 view of Port Said, Egypt (science phase, July 2025)
• NOAA Commercial Remote Sensing Regulatory Affairs, FAQs on 15 CFR Part 960
• ESA, Φsat-2 begins science phase for AI Earth images (July 15, 2025)
• FedRAMP, Security Decision Record (Consolidated Rules for 2026)
• Jones Walker, When Satellites Think for Themselves (2026)
• Dataversity, Legal Issues for Data Professionals: Data Centers in Space (2026)
• Rest of World, Who will regulate data centers in space? (2026)
• Private LTE and 5G, Sovereign AI and Data Localization (2026)
• Introl, The Orbital Data Center Race (February 2026)
• Ars Technica via Digg, Google plans October 1, 2026 launch for its first Project Suncatcher satellite (September 2026)
• Google, Our Project Suncatcher prototype satellite is in orbit (October 1, 2026)
• FedRAMP, Rev5 control guidance: System and Services Acquisition, SA-9(5) by class (2026)
• NIST, AI Agent Standards Initiative (February 2026)
• NIST SP 800-207, Zero Trust Architecture (2020)
• IETF RFC 9334, Remote ATtestation procedureS (RATS) Architecture (2023)
• W3C PROV-O: The PROV Ontology (2013)
• NIST OSCAL (Open Security Controls Assessment Language)
• CCSDS 355.0-B, Space Data Link Security Protocol

Patents

• US Patent 12,574,108
• US Patent 12,368,513

Sections marked as recommendations, design choices, or illustrative records are the authors' proposals, not regulatory requirements.

Originally published July 2026 · Revised October 2026 · © 2026 My Compliance Citadel