Project AESIR: putting guardrails on AI in an amateur space program, with Amazon Bedrock
I'm building an amateur space program. Most of it runs on one laptop, and right now a big piece of it is running on Amazon Bedrock. Here's what the program is, the question at the center of it, and how I set up AWS so a long experiment can run safely and on budget.
What Project AESIR is
Project AESIR is the umbrella for my space and mission-operations work. The names come from Norse mythology (the Aesir are the gods of Asgard, and Huginn is one of Odin's two ravens). I develop each piece on its own, usually with a competition or a paper giving it a deadline, and then bring the pieces together as they mature.
The first piece to reach the public is HUGINN, a CubeSat mission-operations simulator flown through OpenC3 COSMOS, the open-source ground system used for real spacecraft operations. I fly simulated passes against injected faults, working from written procedures and pass plans. The faults include a payload load that sticks on and a telemetry stream that stops mid-pass. I file every pass as a report with its telemetry and commands. All four planned passes are flown, and the repository is public.
Other pieces are planned or in early stages: a public flight-data and conjunction-triage demonstrator (HEIMDALL), a radio ground station (ASGARD), and live data from my own instrumented rockets (SKULD). The piece running on AWS today is the governance layer, which decides who and what gets to command the vehicle.
The question at the center
If an AI is going to help fly a spacecraft, what keeps it in its lane?
My answer is that authority must be bounded by a structure outside the AI. Safety can't depend on the model reasoning correctly, because sooner or later it won't. So the design starts from two rules. The system's resting state is manual. Lowering the AI's autonomy needs nobody's permission, and raising it needs my signature, checked independently by two separate components.
The architecture has four core parts:
- TYR, the constitution: a signed policy table that sorts every command class into ALLOW, KEY REQUIRED or PROHIBITED. My key can authorize a KEY REQUIRED action. It can't open PROHIBITED, so a stolen key can't either.
- BALDUR, the gateway: every command passes through it, whether it comes from a person or from the AI, and BALDUR applies TYR's table to it.
- SYN, the integrity monitor: it verifies signatures and keeps TYR intact. When something looks wrong, it locks autonomy down and hands control back to the human.
- ODIN, the operational intelligence: the AI that proposes actions. Its only route to the vehicle is through BALDUR.
The gateway, the policy table, and the monitor are all deterministic code with no AI inside. The AI proposes, and the deterministic layer decides.
Turning it into an experiment
Architecture diagrams are cheap, so I wanted evidence. I directed a specification for a minimal deterministic layer and put it through adversarial review, with a second AI model attacking each draft and me ruling on every finding. It passed after 46 rounds.
The experiment built from that spec is an ablation study. A simulated stand-in spacecraft is flown through scenario classes designed to break the gateway, under several configurations ranging from no gateway at all to the full layer. Comparing the configurations shows what each part of the layer contributes.
Three choices keep the test honest:
- A sealed hold-out set. The evaluation scenarios are sealed. The AI agent that built the harness is never allowed to read their text, only hashes and counts.
- A second implementation. A different AI built the gateway separately, without seeing the reference build or the run records, so the two can be tested against each other.
- No peeking. At each checkpoint, the run reports only spend, computer time, and whether every run finished cleanly. Results stay sealed until the end, so nobody (me included) is tempted to stop early because the numbers look good.
Where AWS comes in
The AI side of each run calls large language models through Amazon Bedrock. I picked Bedrock for these reasons:
- Serverless and pay per call. There's no GPU instance to size, patch or forget to shut down, and I pay only for the calls the experiment makes.
- Open-weights models behind a managed API. The runs use OpenAI's GPT OSS 120B and Google's Gemma 4 31B. Anyone reproducing the study can call the same published weights.
- One account for everything. The credentials live in the same account as the billing and the budget alerts.
I ran a pilot first, and its real per-call costs set the budget for the full experiment. That beat guessing from a pricing page.
Locking down access
- A dedicated IAM user exists only for this experiment. It has one customer-managed policy allowing model invocation for the models the experiment uses, and nothing else.
- A Bedrock API key generated from that IAM user, with a 30-day expiry. I skipped the console's quick "generate long-term API key" button, because it creates its own user with a much broader managed policy than this job needs.
- The key lives only in a git-ignored
.envfile. I paste it in myself, and the coding agent working in the repository is under standing instructions never to open that file. - Revoke and delete when the experiment ends: the key, the IAM user and the policy.
One thing that surprised me: Bedrock's Model access page has been retired. Serverless models now switch on automatically the first time an account calls them, and access is controlled through IAM policies and Service Control Policies. That makes the least-privilege IAM policy the real gate. If yours is broad, every model in the catalog is open to that key.
Keeping spend honest
- AWS Budgets watches the account: a monthly budget with alerts at 50%, 80% and 100%. I also kept my zero-spend budget, which now works as a "your credits have run out" alarm.
- The harness keeps its own ledger. Every call's cost is logged, and the run has hard spend stops at fixed points. An AWS Budget alert tells me something happened; the harness stops are what halt spending.
- A model check at every start. Before any chat call, the harness reads the model records from Bedrock and compares them to the pilot's baseline. If anything differs, it stops before spending a cent.
- Credits first. The experiment runs on AWS promotional credits, which cover Bedrock usage.
Running long jobs on home internet
The experiment goes one run at a time from my laptop, for days on end. Storms knock my power out now and then, and when that happens the laptop stays up on battery but the Wi-Fi goes with the power. So the harness tells a lost network apart from an error Bedrock returns. When the network drops, it sets the current run aside, checks for the connection once a minute, and reruns that run from the start once it's back. Errors from Bedrock itself keep normal retry rules. Before it ran for real, it was tested by cutting the network mid-run on purpose.
What I'd tell another builder
- Run a small pilot before the real thing. Real costs from your own workload beat estimates.
- Make least privilege your first IAM decision. With model access now opened on first call, the policy is the only gate left.
- Put a spend stop in your own code. Budget alerts are notifications, and a long unattended job needs something that stops it.
- Plan for the network to fail. A long job on home internet will hit an outage. Decide ahead of time what the code does when it can't reach AWS.
What's next
When the experiment finishes, I'll write up the results as a paper, along with what the runs taught me about improving the specification. HUGINN moves on to its v2 build, and later pieces of AESIR will likely run on AWS as well, starting with the same open-weights-on-Bedrock setup.
HUGINN is open source: github.com/dan-lee-odinson/huginn
About the process: I direct Project AESIR and rule on every design decision. The code is built by AI coding agents under my direction, and a separate AI model reviews each specification adversarially before anything is built.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article