Attribute serving decisions without turning logs into a secret store
Capture trusted actor/resource/policy context, distinguish authorization decisions from completed effects, and protect bounded event delivery and retention.
On this page
The question for today
What you’ll understand
- Attribute events to authenticated principals, service actors and canonical resources.
- Exclude credentials and unnecessary sensitive content while preserving decision evidence.
- Test log encoding, delivery gaps, access control and capacity under failure.
A useful serving audit can answer who requested an action, which model or document was involved, what policy decided, and what the system actually did. A raw prompt log rarely answers all of those questions and can become another source of sensitive data. Design structured events around the enforcement boundaries and correlate them through a trusted operation identity. Keep authorization, reservation, execution, release and response events distinct so an allowed decision is not mistaken for a completed action or a denied response for proof that nothing happened.
Record trusted attribution and the decision’s exact scope
Capture the authenticated principal and tenant, the service actor executing on its behalf, canonical model/version/adapter or document identifiers, action, policy version, decision, reason category and operation correlation ID. Treat caller-provided request IDs and claimed usernames as untrusted fields with a separate label. If retries or delegation occur, preserve their relationship to the original operation without inventing a single actor for the whole chain. Record timestamps and clock domain/uncertainty where cross-service ordering matters.
A decision event should identify what was checked and when, including a policy snapshot or lease if used. An execution event should describe the actual target and outcome, while a reservation event records its own accounting transition. Correlation helps reconstruct these stages but does not make an incomplete trace complete. Use bounded reason codes and verified resource references so operators can investigate a denial without logging full confidential documents, generated answers or model parameters.
Minimize secrets and encode untrusted fields as data
Exclude access tokens, passwords, secret keys and unnecessary sensitive prompt/document content from ordinary security events. A diagnostic mode must not quietly disable this rule across production traffic. If correlation requires a protected pseudonymous reference, define its access and key/rotation policy; hashing a low-entropy secret is not automatically safe anonymization. Logs themselves need tenant-appropriate access, retention and deletion policy because even resource names and usage patterns can reveal confidential relationships.
Use a structured encoding and bounded field lengths so a supplied string cannot forge another event with control characters or delimiters. Validate fields from other trust zones, safely represent or omit the bad field, and preserve the security event with an appropriate reason. Protect event transport and storage, and distinguish tamper evidence from complete event capture. A hash chain without a trusted retained checkpoint does not by itself show that a tail was not deleted or that missing events ever existed.
Verify delivery and failure policy with independent evidence
Inject controlled collector downtime, malformed log fields and storage-pressure conditions, then compare an independent operation ledger with collected events. Count missing, duplicate and delayed records using their stable event IDs. Specify whether a security-critical action fails closed, uses durable local buffering or follows another explicit policy when auditing is unavailable; there is no universal correct choice for every action. A best-effort stdout write is not automatically a durable audit receipt or exactly-once delivery.
The queue lab illustrates one finite-rate delivery-pressure term. Reset, set both λ=4,μ=2, predict backlog twelve at t=4, then take eight Steps. Reset and set both λ=2,μ=4 predicts zero at t=4 from initial four. Edits pause while retaining time, so reset and set both rates before comparison. The fluid model contains no durable store, event identities, secret redaction, finite buffer, drops or acknowledgments. Real audit completeness requires the independent ledger and actual failure-path tests.
Work it through
Count a declared uncompressed audit workload
A fictional service sustains one hundred requests per second, emits four security events per request, and stores each event as exactly 256 bytes. Count an uncompressed twenty-four-hour payload only; ignore indexes, replicas and variable-size effects.
The event rate is 100×4=400 events/s. At 256 bytes each, the payload rate is 102,400 bytes/s, or 102.4 decimal kB/s.
One day contains 86,400 seconds, so the payload is 102400×86400=8,847,360,000 bytes, or 8.84736 decimal GB.
Compare that payload with the actual collector/storage throughput and retention policy, then add measured overhead and peak headroom. This arithmetic does not prove delivery, secret exclusion, completeness or tamper resistance.
The specified payload is about 8.85 GB per day. Capacity planning and evidence integrity are separate properties that need separate verification.
The living notebook
Explore the model
Interactive lab · queue
Inspect delivery pressure without claiming durable audit storage
Reset → set both λ=4,μ=2 predicts q(4)=12 after eight Steps; Reset → set both λ=2,μ=4 predicts q(4)=0. Parameter edits retain time; reset both rates for a fresh run. No finite buffer, dropped events, redaction, acknowledgments, event IDs or durable log is simulated.
- Fluid backlog
- 4
- Net rate · λ − μ
- −1 /s
- M/M/1 mean residence
- 1 s
Fluid backlog starts at 4 and follows max(0, 4 + (λ − μ)t). The separate M/M/1 residence-time formula assumes Poisson arrivals, exponential service and λ < μ. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forA growing delivery backlog can threaten evidence availability, while log integrity and secrecy require different controls.
Pause & reason
Check your understanding
Your turn
Try it yourself
An audit collector receives 102,400 payload bytes/s but can persist only 80,000 bytes/s for sixty seconds. With no loss or compression and an initially empty buffer, how many bytes accumulate? Does a zero-error HTTP response prove they were durably stored?
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Integrate the rate difference over the stated interval, then separate application response from a durable collector acknowledgment.
Compare with the solution
The excess rate is 22,400 bytes/s, so sixty seconds accumulates 1,344,000 bytes. A response without an application error does not prove these bytes reached durable storage; the delivery/acknowledgment contract must establish that separately. A finite buffer can fill, so the system also needs an explicit overflow and security-critical-action policy, verified under collector failure rather than inferred from a normal response.
Keep the idea
Take it with you
- Record trusted actor, target, action, policy and lifecycle stage as structured evidence.
- Exclude reusable secrets and minimize sensitive content throughout diagnostics and retention.
- Verify completeness, delivery, tamper evidence and capacity as distinct audit properties.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.