AgentProvenance

 verifiable agent observabilityDemos Documentation
Demos/Documentation

AgentProvenance v0.8.0

English | 中文

Portable, reliable agent execution evidence. This release brings native amd64 capture and validated KVM/K3s deployment to the same evidence model used by local recording. It also makes persistent capture, TLS coverage and storage failure behavior explicit rather than relying on a successful demo alone.

Start with evidence

The Quickstart imports an existing signed multi-agent capture, verifies it and opens the dashboard on macOS or Linux. No VM, Docker or model API key is required for replay. The next step is doctor followed by launch for an installed agent; signing requires --sign-key. The demo index preserves the progression from one agent to a team to cross-pod execution.

Highlights

  • Linux amd64 alongside ARM64. Architecture-selected BPF objects cover syscalls and native TLS probes. amd64 adds kernel capture timestamps, legacy open/unlink paths, and separate C/Go calling-convention handling.
  • KVM and K3s. A systemd collector runs inside the guest, using local-record; a node-local informer attributes externally scheduled Pods. A single sensor observes multiple workloads. No VM scheduler or new core graph model is introduced.
  • Container TLS and Go responses. Automatic discovery reconciles visible OpenSSL and unstripped Go targets, including shared overlay libraries. amd64 Go ABIInternal 1.23-1.26 response capture is paired by goroutine/frame and decoded return sites, including concurrent stack-growth regression tests.
  • Persistent native collection. Accepted batches survive collector interruption, late bindings can recover attribution, and transactions avoid duplicate events on replay. Capacity, losses, missing files and cleanup failures remain observable. See the spool contract.
  • Correctness and diagnostics. Shared ingest is atomic; failed JSONL rows leave no partial evidence. Capture time and retention use actual instants. Database readiness is separate from HTTP liveness and historical coverage gaps.

Validation evidence

Checked lab reports document their own environments and assertions; they were not generated by the documentation edit:

  • WSL2 and a KVM guest: 27 live syscall/TLS assertions, including queued-event capture time and Go TLS request/response plaintext.
  • K3s in the KVM guest: one sensor, eight workloads, eight cgroups, 1,289 events, and graph verification with zero errors or warnings.
  • Local/Pod parity: shared workload commands and runtime graph semantics agree; physical IDs, timestamps, event counts and additional application context are not required to be identical.
  • Container TLS: 30 assertions across two generations of Go/OpenSSL workloads.
  • Late binding and crash recovery: 13 checks against schema 17, including closed intervals and stable event IDs after a second restart.
  • Upgrade: 9,500 historical events preserved from schema 16 to 17 and through a normal guest reboot. This does not emulate abrupt power loss.

CI runs race tests, vet, formatting, portable Phase 1 acceptance, daemon HTTP faults, Linux amd64/arm64 builds, generated binding checks, and live amd64 syscall/TLS tests on Go 1.23-1.26. CI reports and the lab reports are separate validation layers.

Upgrade and boundaries

Back up the data directory before upgrading. Store opening performs the schema migration; a newer unsupported schema is rejected before migration writes. Existing compressed signed demo bundles remain compatible and are not rewritten. Deployment instructions are in the KVM/K3s runbook.

  • The sensor observes the kernel where it runs, including inside a KVM guest. It does not inspect an arbitrary guest from the host.
  • TLS coverage depends on symbols, ABI and attachment time. ARM64 Go TLS reads, BoringSSL and arbitrary stripped/static TLS are not covered. A short-lived process can finish before discovery attaches; reports must retain that gap.
  • Falco-specific spool restart recovery is unchanged. Common atomic-ingest fixes apply, but native stream recovery is not a compatibility-worker promise.
  • The 100k-event benchmark is a single-node baseline, not an SLA. Multi-day soak, real disk faults and run-scoped coverage need further validation.
  • Local signatures establish integrity relative to a trusted key/checkpoint, not complete or truthful capture on a compromised host.
  • Central Evidence Service remains a design, not a multi-tenant SaaS release.

See CHANGELOG for the complete release delta and closeout criteria for the delivery boundary.