Most security teams treat the audit log as a downstream artifact. Something to flush to S3 at the end of the request lifecycle, query when the lawyers ask, ignore the rest of the time. The diagram in the architecture review usually looks like this: business logic, then effects on the world, then a log entry fired off in the trailing edge of the response.
This works for human-driven systems because the human is the source of truth. They remember why they did the thing. They were sitting at a keyboard. The log is a paper trail, useful, but redundant, because the actor is still around and answerable.
It does not work for autonomous agents.
When an LLM-driven agent operates, there is no equivalent witness. The decision happened in the model's hidden state and is not recoverable. The "why" is not in any neuron. The only durable record of what the agent intended, considered, and did is whatever the runtime around it chose to commit to disk. If the runtime didn't write it down, it didn't happen, not in the legal sense, not in the post-mortem sense, not in the customer-trust sense.
So the audit log stops being a downstream artifact and starts being the actual product the runtime ships.
This reframe has consequences.
The runtime has to be on the hot path
You cannot reconstruct a record of agent behavior by reading model logs after the fact, any more than you can reconstruct a financial transaction by inspecting the ledger of a bank that wasn't running when the trade happened. The ledger is created by the act of mediation. There is no shadow-mode version of this; either the runtime saw the call, or the call is uncovered.
Every gate has to write
Identity attestation, rule evaluation, capability lease, action result, each one produces a record. The temptation is to log only failures, because failures are interesting and successes are noise. Resist this. A successful agent action that you have no evidence of is structurally identical to an unauthorized action that nobody noticed. They both leave the same trace: nothing.
The record has to be tamper-evident
Hash-chained, externally pinned, exportable. Not because we expect agents to lie, but because the record will at some point be challenged, by a customer, by a regulator, by an incident investigator, and the operational value of "we have the record" collapses if the record can be retroactively edited by anyone with shell access.
We came to this view by working backwards from the question: in five years, when the average autonomous agent has run ten million actions, what will the security team need to look at? It is not the model weights. It is not even the prompts. It is the linear, hash-chained, monotonically growing list of things the agent did, with the rule each one matched, the capability it leased, and the human who delegated it.
That list is the runtime's product. Everything else, the rule engine, the secrets vault, the policy DSL, is infrastructure that exists to make the list trustworthy.
So when we draw the architecture for Lupid, the ledger is not in the corner. It is the spine. The hot path produces it. The cold path queries it. The whole system is in service of a single artifact that grows by one row each time an agent acts.
If your runtime can't write the ledger, it can't be trusted to enforce the rules.