Show HN: K9 Audit – Causal intent-execution audit trail for AI agents (opens in new tab)

(github.com)

5 pointszippolyon14d ago3 comments

On March 4, 2026, my Claude Code agent wrote a staging URL into a production config file — three times, 41 minutes apart. Syntax was valid, no error thrown. My logs showed every action. All green.

The problem was invisible because nothing had recorded what the agent intended to do before it acted — only what it actually did.

K9 Audit fixes this with a causal five-tuple per agent step: - X_t: context (who acted, under what conditions) - U_t: action (what was executed) - Y*_t: intent contract (what it was supposed to do) - Y_t+1: actual outcome - R_t+1: deviation score (deterministic — no LLM, no tokens)

Records are SHA256 hash-chained. Tamper-evident. When something goes wrong, `k9log trace --last` gives root cause in under a second.

Works with Claude Code (zero-config hook), LangChain, AutoGen, CrewAI, or any Python agent via one decorator.

pip install k9audit-hook

3 comments

proofrelay8d ago

Interesting. One pattern we’ve run into is that the hardest part of post incident analysis isn’t the action log, it’s reconstructing the state of authority and context at execution time. A defensible execution record usually ends up needing a bundle like: input context, delegated identity/permissions, policy version in force, intended action, actual outcome, and a cryptographic link to the previous step in the workflow. Without sealing that bundle at execution time, you’re left playing mix and match with logs and systems later. This isn’t really practical if you’re trying to produce an audit grade reconstruction of the decision chain.

zippolyonOP8d ago

The bundle K9 seals at execution time covers most of what you described: X_t captures agent identity, session ID, hostname and PID at the moment of execution; Y_t hashes the constraint version in force; each record chains via SHA256 prev_hash so the bundle can't be reconstructed after the fact.
To be direct: K9 is currently designed for single-agent auditing. The delegation gap is real and unsolved.

For two-agent scenarios, the approach we're considering is treating the spawn itself as a first-class DELEGATION record in the chain — parent agent in X_t, granted scope in U_t, policy version in Y_t, and R_t+1 answers "was this delegation within policy?" The child agent's subsequent records carry a parent_delegation_id back to that sealed grant. Authority at execution time becomes reconstructable.

The harder question is what happens when B sub-delegates to C: the effective policy for C should be the intersection of the full chain — not just what C's config says, but A's rules ∩ A→B grant ∩ B→C grant, computed at execution time. We don't have a design for that yet.

You've clearly worked on this at a level beyond what we've reached. How have you approached the intersection problem in practice — do you compute effective authority at execution time, or seal the intersection when the delegation grant is issued?

zippolyonOP13d ago

When it comes to auditing LLM-based agents, using another LLM tool is like having one criminal write a clean record for another. Therefore, I believe that a causal AI observation model must be introduced, and only with determinism can probability theory be audited.

j / k navigate · click thread line to collapse