Heimdall

• 

  Title card

Heimdall — a flight recorder for autonomous AI agents

Inspiration

Companies are handing real actions to AI agents right now. Issuing refunds, touching customer data, calling tools on their own. The part that worried me is what happens after an agent runs. You usually can't tell whether it actually stayed inside its rules, you can't fully trust the logs because logs can be edited, and you have no idea how much a bad run cost you.

One incident stuck with me. An AI coding agent deleted a live production database during a freeze it was repeatedly told not to touch, then fabricated fake records and claimed the deletion couldn't be undone, which wasn't even true. That's the gap I wanted to close. Prove what an agent did, prove that nobody changed the record afterward, and price the damage when it goes off-script.

What it does

For every agent run, Heimdall:

• stores the agent's declared policy (allowed tools, required steps, prohibited actions and data) and its full trace of events
• decides whether the agent drifted from its assigned goal, using both deterministic rules and semantic similarity
• proves the record is tamper-evident with a hash chain
• attributes cost-after-drift, meaning how much was spent after the run went wrong
• exports an EU AI Act Article 12 compliance bundle in one click

Each run gets a single verdict: compliant, drift (warn), or drift (critical).

How I built it

The whole system runs inside one Amazon Aurora PostgreSQL database. That was the deliberate architectural choice, not an afterthought. The database isn't storage behind the app. It's the control plane:

• Trace store. Every agent event as JSONB plus relational columns, aligned to the OpenTelemetry GenAI conventions.
• Semantic judge. pgvector scores how far an agent's output drifted in meaning from its goal (cosine distance vs. a threshold), with no separate vector store.
• Policy engine. Relational SQL rules check tools, required steps, and prohibited actions and data.
• Tamper-evident audit ledger. A SHA-256 hash chain over each event, verified entirely in SQL.
• Cost engine. SQL window functions attribute spend before vs. after the first drift.

The front end is Next.js on Vercel, talking to Aurora. A circuit breaker halts a run when it crosses a hard line, like calling an unauthorized tool.

What I learned

• How much you can push into the database. Drift scoring, policy checks, integrity, and cost math all live as SQL. pgvector for meaning and relational rules for structure in the same engine turned out to be the cleanest design, not a compromise.
• Why a tamper-evident hash chain matters. Ordinary logs are mutable, so they can't answer "prove this wasn't altered." A hash chain can, which is exactly what the EU AI Act Article 12 is pushing toward.
• That the database choice is the product decision when the hard problem is reasoning over relationships and keeping a provable record.

Challenges

• Designing the trace schema so raw JSONB events and structured policy data could be joined and scored in one place
• Getting the hash chain to recompute and verify across a whole run, and surface the exact event where tampering breaks the chain
• Tuning the semantic drift threshold so genuine drift is caught without false positives
• Deadline crunch. Seeding realistic demo runs (clean, borderline, and rogue) and wiring up cost-after-drift attribution late in the build

Built with

Amazon Aurora PostgreSQL, pgvector, SQL (window functions, hash chain), Next.js, Vercel, OpenTelemetry-aligned traces

Built With

• aurora-postgresql
• next.js
• node.js
• opentelemetry
• pgvector
• postgresql
• react
• sql
• typescript
• vercel