The Telematics for Autonomous Systems

In the 1990s, the auto insurance industry confronted a problem that had resisted solution for a century. Risk models were built on proxies, age, gender, geography, vehicle type, because direct observation of driving behavior was not technically feasible. The models worked statistically, in aggregate, but they were systematically inaccurate at the individual level. Good drivers in the wrong demographic paid too much. Bad drivers in favorable categories paid too little. The pricing was fair on average and wrong for almost everyone.

The solution was not better statistics. It was better data. The telematics device, a small unit installed in the vehicle, transmitting real-time data on speed, acceleration, braking, cornering, and time of day, made it possible to price risk based on how the car was actually being driven, not on proxies for how it might be driven. Usage-based insurance, built on continuous behavioral signal rather than actuarial inference, produced premiums that reflected individual reality rather than demographic approximation.

The result was better pricing, lower fraud, demonstrably improved driving behavior, because when people know their behavior is being measured and priced, they adjust it, and a fundamentally more accurate relationship between risk and capital.

The analogy for autonomous AI agents is precise. Certification-based insurance for AI agents is the equivalent of the pre-telematics auto insurance model. It prices risk based on proxies, certification scores, audit results, framework compliance, rather than actual behavioral data. It is better than nothing. It will not be sufficient at scale.

The telematics for autonomous systems is the continuous behavioral monitoring layer. And building it correctly requires understanding three things: what it must capture, where it must sit, and why its independence from the systems it monitors is not optional.

What it must capture

The research on AI governance audit requirements converges on a consistent set of data categories that forensically complete records must include.

At the decision level: every input to the agent, prompts, retrieved documents, tool outputs, external data, at the moment of every significant action. Not summarized. Not sampled. Complete, with millisecond-precise timestamps, model version identifiers, and the confidence signals the model generated.

At the tool invocation level: every call the agent made to every external system, APIs, MCP servers, databases, communication tools, with the parameters passed, the responses received, and the authorization context under which the call was made. This is the layer that most current logging architectures omit or capture incompletely. It is also the layer where most consequential agent failures occur.

At the causal context level: the last several messages before every tool call and decision point, the state of the agent's context at the moment it chose to act. This is what distinguishes a forensically useful record from a log. A log records what happened. Causal context capture records why, the information state that produced the decision.

At the identity level: the cryptographic identifier of the specific agent instance, the role it was operating under, the scope it had been granted, and the human or system that authorized its deployment. Not a shared service account label. A verifiable identity that cannot be repudiated.

The research on AIUC-1 compliance is explicit on what auditors now require: not screenshots, not policy documents, not assertions. Substantive and verifiable evidence, documentation that can be independently confirmed to be accurate. The Q2 2026 standard update moved away from screenshots explicitly, in recognition that point-in-time visual evidence does not satisfy the forensic requirements that insurance and regulatory adjudication impose.

Where it must sit

The single most important architectural decision in building this layer is where it sits in relation to the systems it monitors.

The intuitive answer is to build it into the agent, an SDK, a library, a logging module that the agent calls as it operates. This approach is deeply flawed, for a reason that the legal framework from Part II makes precise.

An audit trail that is generated by the system being audited is not independent. It is self-reported. Under DORA's requirement for independent audit trails of third-party ICT providers, a log generated by the LLM provider's own infrastructure and stored in the provider's own systems does not satisfy the independence requirement. In a dispute involving the provider, the log's chain of custody is compromised.

More fundamentally: a log generated inside the agent is subject to the agent's own failure modes. An agent that has been compromised through prompt injection, that is drifting from its behavioral baseline, or that is operating under manipulated inputs, that agent's self-reported logs may not accurately reflect what it is doing. Software running on a compromised host can be instructed to misrepresent its own activity. This is not a theoretical concern. It is a documented attack pattern.

The behavioral monitoring layer must sit outside the agent, in the data path between the agent and the systems it acts on. Every request from every agent routes through it before reaching any downstream system. The monitoring layer captures the action, signs it cryptographically, chains it to the previous entry, and forwards the original request, invisibly, without modifying the agent's behavior, in under 100 milliseconds.

This architecture makes tamper-evidence a property of the record's position, not its policy. The record is captured before the action reaches the system being acted on. It is signed before the agent has any opportunity to influence the record. The cryptographic chain means that any subsequent modification breaks every subsequent link, the tampering is detectable without access to the original system.

This is the same architectural principle that underlies every independent audit function. The auditor does not sit inside the audited entity. They sit outside it, with independent access to the evidence. The behavioral monitoring layer for AI agents must be designed on the same principle.

The technical architecture of an immutable record

The research on AI governance audit infrastructure identifies a consistent set of technical requirements for records that can withstand regulatory and legal scrutiny.

Cryptographic signing at the point of capture. Every event log entry is signed using asymmetric cryptography, Ed25519 or equivalent, at the moment it is written. The signing key is held by the monitoring infrastructure, not by the agent or the model provider. The signature is verifiable by any party with access to the public key, without the cooperation of the monitoring infrastructure or the agent.

Hash chaining between entries. Each entry contains the cryptographic hash of the previous entry. This creates a sequential integrity guarantee: alter any entry in the chain, and every subsequent entry's hash is invalidated. The tampering is detectable without access to the original logs, only the chain itself is needed to verify that it has not been modified. Merkle tree structures allow efficient verification at scale, enabling auditors to verify the integrity of specific events without exposing the complete log.

Append-only storage with WORM properties. The log is written to storage that does not permit modification or deletion, Write Once, Read Many. Records written to WORM storage cannot be altered by the operator, by the agent, or by any party with access to the host infrastructure. The immutability is a property of the storage layer, not of access controls that could be overridden.

Independence from model provider infrastructure. The monitoring infrastructure stores records in systems that the model provider does not control, does not have access to, and does not hold the keys for. This is the architectural operationalization of DORA's independence requirement. The evidence trail's integrity does not depend on any party whose interests might be adversarial to the organization relying on the evidence.

Behavioral baselines and the continuous risk signal

The technical architecture above produces a complete, tamper-evident record. But a record alone is not a risk signal. Risk signal requires a baseline to compare against.

What does normal look like for this specific agent, operating in this specific role, at this scale, with these tools? What is the expected distribution of tool calls per session, API calls per hour, token consumption per task, response latency per query? What are the endpoints this agent normally reaches, and what are the data volumes it normally transfers?

Behavioral baselines, established from observed normal operation and continuously updated as legitimate behavior evolves, are what transform a complete log into a detection system. The gap between baseline and observation is the signal. An agent that suddenly begins accessing endpoints outside its normal scope, that exhibits unusual cost patterns, that invokes tools in sequences that deviate from established patterns, that deviation is detectable only if the baseline exists, and only if the continuous record is available for comparison.

For the insurance market, this is the telematics analogy at its most precise. Usage-based auto insurance doesn't only record that the car was driven. It establishes individual behavioral baselines, this driver's typical acceleration profile, this driver's typical braking pattern, and prices risk against deviation from those baselines. The insurer who knows how you actually drive can price your premium more accurately than the insurer who only knows your age and postcode.

An insurer who knows how your agents actually behave, what their behavioral signatures look like in normal operation, how they deviate, when they drift, can price AI agent risk more accurately than an insurer who only knows your AIUC-1 certification score. Continuous behavioral signal is the precondition for accurate continuous underwriting.

Why this must be an ecosystem, not a product

Part I described the historical pattern: confidence infrastructure for transformative technologies is always an ecosystem, not a single institution. Hartford Steam Boiler did not alone make steam technology trustworthy. It created the inspection standards that others adopted, the actuarial data that informed underwriting across the industry, and the regulatory precedent that eventually became mandatory.

The same principle applies here. The behavioral monitoring layer is infrastructure. It is not a compliance product, not a security tool, not a governance dashboard. It is the data layer on which certification, insurance, and regulatory compliance all depend for their accuracy.

Certification bodies need it to verify that controls were active between audit cycles, not just that they existed when the auditor visited. Insurers need it to price risk continuously rather than statically, the telematics that makes usage-based AI insurance possible. Regulators need it to adjudicate liability, the tamper-evident record that allows the PLD's presumptions to be rebutted and DORA's 72-hour reporting obligation to be met.

None of these institutions can build the behavioral monitoring layer for themselves. A certification body that operated the monitoring infrastructure for the systems it certifies would compromise its independence. An insurer that controlled the data it used to price premiums would face obvious conflicts of interest. A regulator that required a specific technical implementation would constrain innovation in ways that typically backfire.

The behavioral monitoring layer must be independent of all of them, and must be designed to serve all of them. That is why it is infrastructure rather than a product. Infrastructure is what everyone builds on. Products are what organizations sell.

The infrastructure that makes the era possible

The steam engine era required Hartford Steam Boiler. The aviation era required Lloyd's pooled capital. The digital era required SSL certificates and PCI-DSS standards before e-commerce could scale.

The autonomous agent era requires the same convergence: a certification layer that establishes what safe looks like, an insurance market that prices the residual risk, and a behavioral monitoring infrastructure that produces the continuous, independent, tamper-evident signal that both depend on.

The agents are operational. The regulatory frameworks are written. The insurance products are being written. The litigation precedents are being set.

The behavioral monitoring infrastructure, the telematics for autonomous systems, is the missing piece. Not missing in the sense that it cannot be built. Missing in the sense that it has not yet become standard, expected, and required infrastructure for every organization that deploys agents that act.

That will change. The historical pattern suggests it always does. The question is whether it changes before the first wave of major AI agent liability cases forces the issue, or after.