No finished technical standard sets audit log granularity for agentic systems, and the EU AI Act names the purposes logs must serve, not the fields they must hold. The depth therefore has to come from the compliance regime you answer to. When that regime is silent, we would log every decision-relevant step (intent, policy check, approval, tool call, effect, delegation) in a tamper-evident chain, then tier how much each record holds by risk and throughput.
TechnoLynx designs and builds this kind of trail as part of its AI Governance and Trust work. A TechnoLynx engagement starts with your compliance and legal stakeholders, listing the requirements that actually apply and the closest domain precedent before anyone writes a schema.
Does any standard set audit log granularity for agentic systems?
No. Article 12 of the EU AI Act requires high-risk AI systems to “technically allow for the automatic recording of events (logs) over the lifetime of the system”. Article 12(2) defines those logs by three purposes: identifying situations where the system may present a risk or undergo substantial modification, supporting post-market monitoring, and supporting deployers’ monitoring of the system in operation. As Help Net Security put it in April 2026, the regulation prescribes no format and requires no specific fields, only those three purposes.
Article 12 names minimum fields for remote biometric identification systems under Annex III point 1(a), which must record each period of use, the reference database checked, the input data that produced a match and the people who verified the results. Article 12 sets no equivalent list for other high-risk systems, agentic ones included.
The harmonised standards are not finished either. Two drafts, prEN 18229-1 (AI logging and human oversight) and ISO/IEC DIS 24970 (AI system logging), have not been completed. VDE describes the draft logging component as deliberately agnostic: it can be built in software, hardware or both, and it does not impose a fixed schema. The NovaFabric authors make the same point more widely. The EU AI Act, the NIST AI RMF, ISO/IEC 42001 and 21 CFR Part 11 each say what evidence must exist without prescribing a machine-readable, tamper-evident format. The Cloud Security Alliance’s agentic profile reports that NIST’s AI agent standards initiative aims at voluntary guidelines covering monitoring and logging, with an AI Agent Interoperability Profile planned for the fourth quarter of 2026.
Deployers of high-risk systems must keep the logs under their control for at least six months, unless other Union or national law (data protection law in particular) says otherwise. Sector regimes can be stricter: PCI DSS requires one year of audit trail history, with three months immediately available for analysis.
That leaves three cases:
- The reviewer’s requirement is unknown. Default to fine-grained, per-step logging, which you can filter or aggregate later for lighter reviews.
- The reviewer has a documented, narrower requirement (for example, final decision plus approver). That requirement governs, and you can cut capture for cost or privacy. Keep the ability to trace each step, though, so you can turn it up if the regulator later asks for more.
- No explicit requirement exists. Borrow the granularity of the regulated domain closest to yours (credit, payments, content moderation). Remember that precedent from one jurisdiction or sector may not transfer exactly.
Application logs and an audit trail answer different questions
An application log records what happened. An audit trail has to show why the action was authorised, and who answered for it. One analysis of agentic governance puts it this way: “an execution log answers what happened; governance evidence must answer why the action was authorized”. In agents, that authorisation rationale sits in short-lived prompts, context windows and reasoning chains that are thrown away once the task completes.
Observability traces are mutable analysis artifacts, built for the first job. AgentTrace, for example, splits agent telemetry into operational, cognitive and contextual surfaces for debugging and forensic analysis. Trace capture has converged on the OpenTelemetry GenAI conventions. In those conventions, capturing prompts, completions, tool-call arguments and tool-call results is opt-in, and the default setting is NO_CONTENT. So the out-of-the-box configuration already makes a granularity decision for you: it captures no content.
| Application / observability logs | Audit trail | |
|---|---|---|
| Question answered | What ran, how long it took, what failed | What changed, when, and who authorised it |
| Integrity | Usually stored in databases where an administrator can change or delete records without detection | Chronological and tamper-evident, so tampering is detectable |
| Fitness for audit | None of eleven tracing tools surveyed in June 2026 offered cryptographic tamper-evidence of stored traces | Designed for auditor queries, verification and reporting |
Should an agent’s audit log capture every intermediate step, or only the final decision and its approver?
Capture every step that affects the outcome. A record of only the final decision and named approver cannot reconstruct the decision context, which a governance-adequate trace must permit.
Agents make this harder than other architectures. In rule engines, classical ML and hybrid systems there is a bounded decision event you can trace. An agentic decision is the product of a whole delegation chain, with “no single identifiable point” to capture. Solozobov’s 2026 synthesis rated, analytically, what share of the six Decision Event Schema properties each architecture can fill. Deterministic rules scored 0.83, hybrid ML plus rules 0.50, classical ML with human review 0.17, and agentic AI 0.00. The same work concludes that a single trace record cannot capture a delegation graph. The same work proposes a protocol that records delegation, rationale and composition at each step. Each agent in the chain should emit the task it received, a structured rationale (policy consulted, constraints evaluated, why it chose that tool or sub-agent), the sub-tasks it delegated and the output it produced, with correlation identifiers linking parent and child records.
Gaps compound. In a sequential risk-scoring pipeline, an evidence gap at one stage weakens the evidence at later stages, because downstream records inherit the limits of upstream ones.
Two architectural points bear on whether per-step logging is achievable. First, route every external action through one place. The CSA profile’s Tool-Gateway Chokepoint funnels all API calls, database operations and file access through a single control point where each one is audited. Second, accept that a recorder only sees what reaches it. The Agent Flight Recorder’s authors state that an action bypassing the instrumented gateway is never recorded. When delegation crosses into a vendor’s black-box endpoint, the orchestrator cannot force that endpoint to expose its reasoning or constraint checks.
Is a per-step reasoning trace needed, or are the input, decision and approving reviewer’s identity enough?
Neither extreme works. Input, decision and approver alone are too thin for an agent, for the reasons above. A raw chain-of-thought transcript is weaker evidence than it looks. The governance-relevant rationale is a structured record of the mandate the agent operated under and the constraints it checked, “not a transcript of the model’s internal reasoning tokens”.
The faithfulness problem has been measured. On average across hint types in Anthropic’s experiments, Claude 3.7 Sonnet mentioned a hint it had actually used 25% of the time, and DeepSeek R1 39% of the time. In a reward-hacking experiment, the models admitted to the hack in their chain-of-thought less than 2% of the time in most scenarios, and often built fake rationales instead. NovaFabric, for example, records model calls, tool calls and effects at the agent–system boundary and explicitly does not claim to capture the model’s internal reasoning. For ML-mediated decisions, the Decision Event Schema shifts the question from “what alternatives were considered” to “what authorisation envelope was the system operating within”.
If you keep reasoning text, record it as the model’s self-report, alongside the structured rationale rather than in place of it. Self-reported quality signals are necessary but not sufficient: they must be anchored by external calibration metadata or cross-agent consistency checks.
Do compliance reviewers expect every rule-filter trigger and classifier score in a moderation log?
For hybrid ML-plus-rules systems, the Decision Event Schema says yes: it must capture the score, the threshold, the rule evaluation path and the context that set the threshold. The structured escalation context (triggering rule, threshold exceeded, risk category) is what makes override records fillable in these systems.
Appeals regimes ask for this detail directly. Under the Digital Services Act, a statement of reasons must give the type, territorial scope and duration of each restriction, the facts and circumstances relied on, and the legal or contractual ground. It must also say whether automated means detected the content and whether the decision itself was fully, partially or not automated. Under ECOA and Regulation B, stating that an applicant “failed to achieve a qualifying score” is insufficient, and a creditor’s lack of understanding of its own methods is no defence. Article 86 of the AI Act gives affected persons a right to clear and meaningful explanations of the AI system’s role and the main elements of the decision. You cannot write a specific reason after the fact if the trigger that produced it was never logged.
Logging every classifier score in full on every item is a different matter at high volume. Sampled, threshold-triggered capture (Tier 2 below) records flagged decisions without full capture overhead on routine events. Keep the scheme extensible too, because what an initial audit expects and what an appeal or escalation review expects can differ and change over time.
Tiering audit log depth by risk and throughput
The Decision Event Schema (DES) offers one way to match log depth to decision risk and throughput. It defines three evidence tiers, selected by deployment-time policy.
| Tier | Applies to | What it holds | Cost profile |
|---|---|---|---|
| 1. Lightweight temporal | Every decision event | Schema version, timestamp, sequence number, hash chain, evidence tier, decision id and type, logic type, output, override_occurred; actor and rationale for human decisions; original and overridden output when an override occurred |
About 200–500 bytes per event; dominated by sub-millisecond hashing |
| 2. Sampled contextual | Threshold-exceeding events: high risk level, low confidence, quality alerts | Adds decision context, abbreviated logic and core quality indicators, enough for causal reconstruction of flagged decisions | Paid only on flagged events |
| 3. Full | High-stakes decisions | All six property groups fully populated | Infeasible above about 100,000 decisions per second even with TEE or binary hash trees; about 100–300 per second on permissioned blockchains and about 3–13 per second on linear hash chains |
The schema’s author maps the regulation onto these tiers. Article 12’s tamper-resistant recording and the six-month retention are met at Tier 1, and its risk-situation identification needs Tier 2. For high-risk systems also subject to Article 11, the recommended policy routes every decision to Tier 2 at minimum, and to Tier 3 for any decision that triggers a threshold alert or a human override. The throughput ceilings are analytical estimates synthesised from published benchmarks, and the author lists validating them as future work. Treat them as an order of magnitude rather than a capacity plan.
What each audit log entry for an automated decision should contain
The fields below draw on published schemas and regimes for decision records.
| Field group | Contents | Grounding |
|---|---|---|
| Core event facts | Event type, time, location, source, outcome, identities involved | NIST SP 800-53 AU-3; PCI DSS 10.3 |
| Decision envelope | Decision id and type, logic type, output, override flag, sequence number, hash chain, schema version, evidence tier | DES required fields |
| Human judgement | Override actor and rationale; original versus overridden output | DES override rules |
| System state | Model version, runtime configuration, prompt policies, tool-use and guardrail settings | LLM audit trail framework; ICO on version tracking |
| Agent semantics | Intent, policy evaluation, human approval, execution, effects, context, code and delegation provenance | Agent Flight Recorder |
| Correlation | Conversation id, tool name, tool call id; parent and child trace links | OpenTelemetry GenAI; delegation protocol |
| Appeal-facing | Grounds relied on, facts and circumstances, level of automation in detection and in decision | DSA statement of reasons |
One design detail carries over from cloud audit logging. Google Cloud emits two audit entries for long-running operations, one at the start and one at completion. Pairing start and completion records for slow or external tool calls gives the same visibility when an agent action stalls or partially fails.
Full logging collides with data minimisation
DES’s own author flags the tension: decision inputs may contain personally identifiable information, the override actor field records who intervened, and both create obligations under GDPR’s data minimisation and erasure rules. The broader synthesis lists the same conflict between reconstruction completeness and minimisation as unresolved. Over-logging can therefore become its own compliance exposure.
Several design choices reduce that exposure without losing evidence. Prefer metadata over raw text, and apply structured redaction or aggregation. Keep only hashes and structural metadata in the integrity chain, and store payloads encrypted elsewhere. Use per-event keys so an auditor investigating three events out of a thousand can decrypt only those three. Attest redactions so an auditor can verify a secret was removed without recovering it. Access to the logs should itself be legitimate, proportionate and auditable.
How do you keep an agent’s audit trail tamper-evident and replayable when auditors ask for it?
Chain every record to the one before it, seal batches under a Merkle root, anchor those roots somewhere the operator cannot rewrite, and keep enough recorded context to reconstruct the run. The basic mechanism is a hash chain in which each event’s hash covers the previous hash (prev_hash → curr_hash), with signatures added for multi-writer provenance. Auditors replay the chain to confirm the trail has not been altered or truncated since it was written.
A plain hash chain has two limits. It is tamper-evident, not tamper-resistant: someone who controls the storage can recompute the whole chain after a change unless the chain head is anchored externally. It also cannot skip events. Crosby and Wallach (2009) showed that in an 80-million-event log their Merkle-based history tree proves any single event in 3,100 bytes, where a hash chain would need an average of 40 million hashes. That matters for selective audits, such as pulling one appeal’s records without shipping the whole log. Evidence also needs to be audited, not just sealed: a commitment that is never audited carries no tamper-evidence guarantee.
Replay is a separate property. NovaFabric defines four replay modes (exact, mocked, semantic, forensic) and separates forensic reconstruction of sealed evidence from test re-execution against a live model.
Measured overhead of tamper-evident logging
| System (source) | Per-event recording cost | Storage | Integrity result |
|---|---|---|---|
| Agent Flight Recorder, full stack | About 48 µs median; P99 about 30 ms at epoch seals | 512 bytes per event | Edit, delete and reorder attacks detected at 100% with zero false positives |
| Agent Flight Recorder, on-chain anchoring | Asynchronous, amortised over epoch | $2.30 per 100K events at 100-event epochs on an L2 | Enables neutral third-party dispute resolution |
| AuditWeave | 22.42 µs per event, versus 0.24 µs unprotected | Single append-only file | Every injected mutation flagged across 2,000 trials; 100,000 events verified in 1.21 s |
| Crosby and Wallach history tree (2009) | 1,750 events/s on one core with signing; 10,500 with signatures offloaded | History tree roughly matched the 14.0 GB trace size (13.6 GB) | Logarithmic proofs |
| NovaFabric session capsule | Not measurable as a percentage on one CPU-only host (95% CI −10.5% to +16.9%) | Mean 76 KB per agent run | Mean capture completeness 0.652 |
Next to a tool call involving network I/O, tens of microseconds per event is small. Completeness is the hard part, and NovaFabric’s own evaluation found network, file and human-approval streams silently empty in an earlier build. Measure capture completeness alongside overhead.
Who can design an audit trail for our agent that a compliance reviewer will accept?
TechnoLynx designs and implements per-step, tamper-evident audit trails for agentic and moderation systems. The work runs in order. First, TechnoLynx frames the requirements with your compliance and legal owners. Then TechnoLynx defines a schema covering tool calls, rule and classifier triggers, rationale records, approvals and overrides, and instruments the pipeline with tamper-evident, versioned records. TechnoLynx tests it against representative appeal and audit scenarios, then runs it in production with retention, access control and completeness monitoring. TechnoLynx treats this evidence as an engineering output a non-engineer can read and sign against, not a policy document. The engagement sits under AI Governance and Trust.
The engagement has limits. It produces approval-grade evidence as an engineering output. It is not legal advice, regulatory sign-off, certification or a promise of audit-readiness.
Costing the GPU inference behind an automated decision system
A cost-per-request, per-site or per-subscriber figure only means something once the reference workload is frozen: request rate, input resolution, model size and the batching or instance strategy. Measure cost on today’s serving path, project it to the target scale by modelling pricing tiers and batching rather than assuming linear growth, and re-run the model at every scale milestone.
LynxBenchAI’s published results show how each device runs the public PyTorch stack your own models are built on. That makes them a broadly indicative input for the hardware term in this model, though they do not measure your own workload or application. TechnoLynx’s Inference Cost-Cut Pack starts by fixing that reference workload with you, then instruments the serving path (inferences per second, QPS, power draw, p99 latency) to feed the cost formula. See the LynxBenchAI results for the device side.
Per-call cost for a telemetry scoring endpoint
Pay-per-call pricing fits low or unpredictable volume where the per-call rate is already competitive. Once volume is steady, batching several assets into one call, or moving to reserved capacity, spreads fixed cost across more requests and can undercut the per-call rate. Whether scaling to more sites keeps cost linear, or moves you into a cheaper or dearer tier, depends on the provider’s pricing tiers and how well your batches fill. That is a modelling question, not an assumption. Batching adds latency, so check every batched scenario against the latency the scoring loop must meet.
Fixing the reference workload for a vision model before costing it
If the model’s final size or frame rate has not been frozen, the cost figure is a moving target, and any projection built on it becomes invalid when either changes. Agree on a “production” configuration (frame rate per stream, input resolution, model variant, precision, batch size) and record it with a version, the same way you would version a model in an audit trail.
Per-subscriber cost for a scheduled refresh pipeline
For a pipeline that refreshes on a schedule, the useful unit is the cost of one end-to-end cycle. Divide that by the clients it serves, and split it into compute, storage and data egress so you can see which term grows with subscribers. Doubling subscribers on fixed hardware lowers per-client cost only while the cycle still finishes inside its window. After that, the next step is new hardware, not a smaller share. Every figure is tied to current hardware and vendor pricing, so re-validate before locking a pricing round.
