AERAgent Execution Record
The flight recorder for AI agentscollector on npm ↗

Do you know what your agents are doing?

AER records agent activity without capturing prompts or bodies, then signs every run so customers and auditors can verify it independently, even offline. Your agents touch real data and spend real money; the record is how you answer for it.

Request accessSee a real record
$npx @adastracomputing/aer initnix run github:Ad-Astra-Computing/aer#aer -- init

Instrumented actions become events. AER signs the whole trace when the run ends.

InstrumentsOpenAI SDKAnthropic SDKVercel AI SDKMCP serversnode:http(s)fetchchild_process

The problem

Sooner or later, someone asks for proof

AER is not an observability dashboard, a prompt logger or an eval tool. It is the signed record you hand to someone who will not take your word for it. Built for teams that ship agents to enterprise customers, work under compliance or run a fleet in production and have to answer for what those agents did.

01

The incident review

An agent deleted the wrong records at 2 a.m. The postmortem needs to know which tools it called, what it touched and where it sent data. Ordinary logs are scattered and easy to change after the fact. A signed record answers those questions and cannot be quietly edited.

02

The audit request

A customer audit asks you to prove what your agents did with their data. Screenshots of your own dashboard are not proof. AER exports an evidence pack for any run: canonical bundle, provenance graph, verification script and public key. The customer verifies it themselves.

How it works

Record. Sign. Verify.

1

Record

Drop-in collector captures what agents do: LLM calls, tools, network, processes. Metadata only, never prompts or bodies.

node --import @adastracomputing/aer-auto-node/register

2

Sign

Every run becomes a signed bundle anchored to a public transparency log. The record cannot be quietly edited afterwards.

Ed25519 signatures, anchored to Sigstore Rekor

3

Verify

Anyone you hand the record to checks it themselves: in the browser, with the CLI or fully offline. No AER account needed.

SubtleCrypto in the browser, aer verify anywhere

Flow diagram: an agent runs with the AER collector attached. The collector produces a signed bundle which is anchored to a public transparency log, and the bundle can be verified by anyone. The collector also presents attestation tokens to protected resources, which act as an admission gate.
AGENTCOLLECTORSIGNED BUNDLETRANSPARENCY LOGPROTECTED RESOURCEattestation gateVERIFIERanyone, offline

The bundle: verifiable by anyone, offline. See the live record below.

The collector (npm): presents attestation to protected resources.

Live proof

A signed record, verifiable end to end

This is a real record: the observed activity, the public proof page and the integrity block of a sample AER, signed and anchored by the same production pipeline your own records use. Verify it without trusting this page.

What this agent did · 11 recorded events
tooldata_fetch
hostexfil.attacker.example
hostinternal-data.corp
Open the full trace →
The public proof page for a production AER: cryptographically verified, bundle metadata, Rekor log index and the independent verification commandsThe public proof page for this record. Every AER gets one. →
Canonical hash
c34b7206e18acbaf01367f853c68d5f3d215bfb8f3f306e18d6c9fe223c17920
SHA-256 of the canonical JSON
Signature
Y4d/gzefPDX2sWJtvI2UiSINzXmTDSvdBHWnhCGWCjk+oW8azA5EmrLQFvLW…
Ed25519 over the hash, base64
Signing key
a721bb9bd8f31c8e
Public verification key ↗ (anyone can fetch it and verify signatures locally)
Anchored
yes
recorded in a public transparency log
Rekor log index
1631641483 ↗
public Sigstore Rekor entry
Verify this bundle in your browser → · Take the guided demo →

Evidence, not logs

Independent evidence, not better logs

Agent observability and eval tools exist to help you debug your own agent, and the hosted ones typically work by uploading your prompts and traces to their servers. AER does the opposite job. It captures metadata only and never your prompts, then produces an artifact anyone can verify offline without trusting AER or the vendor.

PropertyPlain logsVendor dashboardAER
Tamper-evident——Ed25519 signed
Your prompts and datain your logstypically uploadednever leave your process
What it is fordebuggingdebugging your agentproving it to a third party
Independently verifiable——SubtleCrypto, CLI, anywhere
Anchored to public log——Sigstore Rekor
Standalone bundle artifact—vendor lock-insingle canonical.json
Baseline-driven detectiongrepproprietary rulesrules.v1 (open + replayable)
Schema is open——documented + zod-validated

Beyond recording

Gate access on a live record

Protected resources can require a live AER attestation before serving a request. Registered agents running the collector present short-lived signed tokens; anything else is denied. Scopes, DPoP proof-of-possession and mTLS binding are available where you need stronger guarantees. Enforcement happens at your resource, verifying tokens against AER's public keys, so AER stays out of your request path.

import { honoMcpGuard } from '@adastracomputing/aer-mcp-guard/hono';

app.use('/mcp', honoMcpGuard({ audience: 'mcp://payments-prod' }));

Integration

The integration is a few lines

The zero-code path instruments a Node agent without touching its source. Coding harnesses like Claude Code and Codex CLI record through hooks. A TypeScript and Node SDK ships today, a Python SDK is next and raw HTTP works for everything else.

Zero-code (Node)

npx @adastracomputing/aer init

# then run your agent with the collector attached:
node --import @adastracomputing/aer-auto-node/register your-agent.js
nix run github:Ad-Astra-Computing/aer#aer -- init

# then run your agent with the collector attached:
node --import @adastracomputing/aer-auto-node/register your-agent.js

Coding harnesses (Claude Code, Codex CLI, opencode)

npx @adastracomputing/aer-hooks install claude-code
npx @adastracomputing/aer-hooks install codex

# Records the tools your coding agent runs, with no change to the harness.
# Tool and argument-key names only, never values.
nix profile add github:Ad-Astra-Computing/aer#tools
aer-hooks install claude-code
aer-hooks install codex

# Installed rather than run, because the harness calls the hook binary
# itself: it has to stay on PATH after setup finishes.

TypeScript / Node SDK

npm install @adastracomputing/aer-sdk-ts

import { createAerClient } from '@adastracomputing/aer-sdk-ts';

const client = createAerClient({
  baseUrl: 'https://api.aer.run',
  sessionId: sess.agent_session_id,
  ingestToken: sess.ingest_token,
});
await client.emit('tool.started', { tool: 'web_search', query: 'today' });
await client.emit('tool.completed', { tool: 'web_search', results_count: 5 });
await client.complete();

Or speak the API directly

POST /v1/sessions               → { agent_session_id, ingest_token }
POST /v1/sessions/<id>/events   → ingest one batch (200 OK)
POST /v1/sessions/<id>/complete → { aer_id, canonical_hash, signing_key_id }

# Anyone can verify the resulting bundle, anywhere:
aer verify <aer-id>
# → { verified: true, hash_match: true, signature_valid: true, anchored: true }

Full quickstart →

Trust and security posture

What we claim and what we refuse to

The collector captures metadata only: model names, token counts, tool names, hosts. Never prompts, completions, arguments, bodies or headers.

Bundles are tamper-evident, not tamper-proof: after signing and anchoring, any modification is detectable by anyone.

AER does not claim to stop a malicious operator who strips instrumentation. For that boundary, protected resources verify attestation and unattested callers are denied.

You can verify every claim on this page yourself, in your browser, right now.

AER is built by Ad Astra Computing and runs in production. The sample record above was signed and anchored by the live pipeline, not a staging mock.

Questions

What evaluators ask

What it is

How is this different from observability or logging tools?
Observability and logging give you records you have to trust the vendor about: they live in a system you control, and anyone with access can change them. AER produces a signed record that a third party can verify without trusting you or us. The signature and the public transparency log make it evidence, not a dashboard. AER sits alongside your observability stack; it is the record you hand to someone who will not take your word for it.

What a record proves

What exactly does a signed record prove?
Three things. Integrity: the record was not altered after signing, since any change breaks the canonical hash. Provenance: it was signed under AER's published key, and the transparency log fixes when. Observation: the events in it were captured by the collector during the run. It does not by itself prove the agent could not act outside what was instrumented; that is what admission control and attestation are for.
Is the record on the demo page a real agent run?
Yes. It is produced on a schedule by an agent that makes real model calls and real tool calls against a live registry, through the same session, ingest and completion path a customer’s agent uses. It is signed and anchored like any other record. The sentence describing the run is assembled from the record itself rather than written by hand, so it cannot drift away from what the record actually shows.
What does AER deliberately not capture?
The collector records metadata only: model names, token counts, tool names, hosts and process names. It never captures prompts, completions, tool arguments, request or response bodies or headers. That boundary is enforced in the collector, on every provider, streaming or not, and the API discards unrecognised fields at ingest so nothing else is stored.
Can I prove a specific prompt or output without revealing it?
Yes. Content commitments put a one-way tag over a prompt or response in the signed record using a key only you hold. Later you can prove a given text matches the tag byte for byte, offline, without AER ever seeing the text.

Security and data

Where does my data live and how is it handled?
On Cloudflare's platform, isolated per tenant. You control retention and whether records are public or private. We are a data processor for your telemetry and a controller for your account data. A Data Processing Agreement is available on request, EU and UK transfers rely on Standard Contractual Clauses, and every subprocessor is listed on the subprocessors page. The privacy and security pages have the detail.
What if Sigstore Rekor goes down or rewrites history?
Rekor is run by the Linux Foundation's Sigstore project with independent witnesses and a publicly auditable Merkle tree. Anchoring is best-effort at session close: if Rekor is briefly unreachable, the record is signed and flagged unanchored, then anchored once the log is reachable again. Even without Rekor, the Ed25519 signature alone proves the record was emitted by AER's key.

Integration

Does this slow down my agent?
Not in the request path. The SDK batches events in memory and posts them asynchronously. Calls to emit() return as soon as the event is queued; flushing runs every 500ms by default. Signing and anchoring happen at complete() time, server-side, not in your hot path.
What can I instrument?
The collector covers the OpenAI, Anthropic and Vercel AI SDKs, MCP servers and raw HTTP, fetch and child processes. One SDK ships today, @adastracomputing/aer-sdk-ts for TypeScript and Node, with a Python SDK next. Any language can speak the raw HTTP API in the meantime.
Does it work with Claude Code, Codex CLI or coding agents?
Yes, through hooks rather than the collector, since a coding harness is not a Node process you control. npx @adastracomputing/aer-hooks install claude-code registers with the harness and records the tools it runs, with no change to the harness itself. Codex CLI and opencode are supported the same way. The boundary is unchanged: tool names and argument key names, never the values, and a hook that cannot reach AER never blocks a tool call.
Can I install AER with Nix instead of npm?
Yes. The client packages ship as a Nix flake alongside npm. nix run github:Ad-Astra-Computing/aer#aer -- init instruments a project without installing anything permanently, and nix profile add github:Ad-Astra-Computing/aer#tools puts the CLI, the hook binaries and the MCP recorder on your PATH. Recording a coding harness needs the profile form, because the harness calls the hook binary itself long after the setup command has finished. Every command box on this site offers both forms.
Is AER open source?
Partly, and the split is deliberate. Every client package you install into your own agents and services is Apache-2.0 and published on npm: the collector, the SDKs, the CLI, the verifier and the admission guards. The source is at github.com/Ad-Astra-Computing/aer. The hosted service that signs and stores records is not. The part that proves a record is genuine is the open part, so you never have to trust whoever produced the record. The verifier makes no network calls and needs no account, so a record already issued still verifies even if AER goes away.
How long are records retained?
Records are retained until you delete them, and you set your own retention window in settings. The transparency log entry is permanent by design, since Rekor is append-only, but it contains only a hash and a signature, never your data.

Know what your agents are doing. Prove it to anyone who asks.

Request accessor verify a record first