Every Policy Change, With a Name on It: Audit Trails for LLM Gateways

Production AI systems accumulate quiet changes. A key is created for a contractor. A model permission is widened "temporarily." A budget ceiling is raised during an incident and never lowered. None of these are requests, so none of them appear in request logs — and months later, when a security review asks who authorized what, the team reconstructs history from chat messages and memory.

That reconstruction problem is what administrative audit logs exist to prevent. nRouter's governance documentation describes them directly: every policy change, key action, and request outcome is recorded with actor, timestamp, and result, in a trail that cannot be edited or deleted. Teams evaluating the model can read the full description under Govern your production LLM traffic.

Three event families

The recorded events fall into three families, and a useful audit trail needs all three:

• Policy changes. Who modified a rule, at which scope — organization, team, or virtual key — and what the change did. This is the family most platforms omit, because policies are usually edited in an admin console whose history nobody keeps.
• Key actions. Creation, permission changes, and revocation of virtual keys. Keys are the standing credentials of an LLM platform; their lifecycle is exactly what an auditor asks about after an incident.
• Request outcomes. Not just that requests ran, but how governance treated them — including requests blocked in the path, with the reason recorded, such as a prompt-injection attempt stopped before dispatch.

Immutability is the load-bearing word

An audit log that administrators can edit is a narrative, not a record. The documented property — the trail cannot be edited or deleted — is what lets a compliance team treat it as evidence rather than as the platform team's account of events. It is also what makes exports meaningful: audit events can be exported for compliance review and archival, so the record can live in the organization's own retention systems instead of only in the vendor's console.

The review this enables

With the three families recorded and exportable, a quarterly review becomes mechanical: list every policy change and check each has an owner and a reason; list every key created and confirm each still needs to exist; sample blocked requests and confirm the block reasons match the policies in force. None of that requires new tooling — it requires that the events were captured at the time, with names attached.

Spend fits the same pattern. Every token is attributed to a request, a key, a team, and a model, so the financial record and the security record are the same record read two ways.

A check for your current platform

Ask of the platform you run today: can you produce, for last month, every policy change with its actor? Every key action? Every blocked request with its reason? If any answer needs a support ticket or a database dig, the audit trail is a gap, not a feature — and closing it is an architecture decision, made where the traffic and the policy changes actually happen.

Disclosure: I work with the nRouter team. Capabilities described are as documented on the linked page.