You logged everything and still can't prove who did it

There is a piece of writing that everyone selling AI logging tools has now published. It goes like this: the EU AI Act's Article 12 requires high-risk systems to record their events automatically over the system's lifetime, but the text never says those records must be tamper-proof. A log you can quietly edit is not evidence; it is a claim. Therefore you should sign your logs. Put the signing key outside the agent's trust boundary, give every action a cryptographic receipt, and chain the receipts so any later alteration is detectable.

That argument is correct. It is also finished. Asqav signs each action with post-quantum ML-DSA. FireTail discovers your AI estate and pours it into tamper-evident, centrally retained storage. Salt captures an immutable trail of every AI-to-API call. The pattern is the same across all of them, and it is the right pattern. I am not here to argue with it.

I am here to tell you that integrity was the easy half, that it is now solved, and that the half everyone is walking past is the one that will actually decide whether you can answer a regulator.

Integrity is so solved that rival implementations interoperate

Here is the clearest evidence that signing is no longer the hard problem: independent teams who have never coordinated can verify each other's work.

We open-sourced Kanoniv's identity and delegation layers under MIT precisely because we think they are commodity infrastructure. A did:agent: identity, an attenuated delegation chain that can only ever narrow authority, a proof you can attach to a tool call and verify in five lines with no network round-trip. None of that is a moat. To prove the point, five independently built agent-auth engines, ours and four others, cross-verified each other's Ed25519 delegation chains. Different DID methods, different key encodings, different canonical JSON, and they all resolve to the same thirty-two bytes and the same yes-or-no answer. Trust artefacts are already portable across agent systems built by strangers.

When five competitors can interoperate on a primitive, that primitive is a commodity. Signing is a commodity. If your AI governance story ends at "we sign our logs," you have shipped the part that everyone, including your competitors, already agrees how to do.

So let me show you the part nobody has shipped.

One agent, three perfect logs, no answer

Picture a single autonomous agent resolving a billing dispute. It reads the customer's history in your CRM. It issues a credit in your billing platform. It closes the ticket in your support desk. One actor, one task, three systems.

Every one of those systems is a model citizen. The CRM signs its access logs. The billing platform signs its mutation logs. The support desk signs its ticket events. Three tamper-evident records, each independently verifiable, each beyond reproach on integrity. Your signed-logging vendor's dashboard is entirely green.

Now the supervisory authority asks the only question that matters under Article 12: show me everything this one actor did.

You cannot. Not because a log was altered. Nothing was altered. You cannot because the CRM recorded the action against a service-account identifier, the billing platform recorded it against an OAuth client_id, and the support desk recorded it against an email-shaped bot address. Three immortal, untampered logs. Three different names for the same actor. And nothing, anywhere, that proves those three names are one agent doing one connected thing.

Integrity is intact. Traceability is broken. You have satisfied the letter of "tamper-evident" and missed the entire point of "traceable." This is the gap, and signing does not touch it.

Why "just give the agent a stable identity" isn't the fix

The reflexive answer is the one the field has already converged on: assign every agent one durable identity, stamp it into every log line, and propagate a correlation context across services with OpenTelemetry or W3C Trace Context. Give the agent a DID and carry it everywhere. Then all three logs say the same name and the problem dissolves.

In a greenfield system you control end to end, this works. I believe in it enough that we built it and gave it away. But notice the assumption hiding inside it, because that assumption is the whole essay: stamping one identifier everywhere requires that every system in the path accepts your identifier.

They don't. A DID governs identity issuance. It lets you mint a stable name for your agent and prove the agent holds the corresponding key. It says nothing about the identity namespaces of systems you do not own. Your CRM vendor is not going to honour did:agent:. Your partner's billing API will authenticate the call as its own provisioned client and log it that way. Trace context only propagates through systems instrumented to carry the header; the legacy support desk strips it at the door. Even a name-stable agent identity (same agent, same DID across sessions, which we support) is only legible inside the trust domain where your verifier runs. The moment the actor crosses a boundary you don't control, your canonical identifier is gone, and the foreign system writes down whatever name it uses.

This is exactly why our architecture separates the two as different layers. Issuing an agent identity is Layer 0: open source, free, table stakes. Resolving "the same agent across platforms" is a separate layer entirely, and it is separate because it is a different and harder problem. Conflating the two is the mistake at the centre of the whole conversation. A DID is necessary. It is nowhere near sufficient.

This is entity resolution wearing a compliance hat

Strip the regulatory framing away and state the residual problem in plain terms. You hold records from heterogeneous systems. Each system refers to the same real-world actor under a different identifier. You must decide which records refer to the same entity, and you must be able to defend that decision.

That is not a novel AI-governance problem. That is entity resolution, a discipline with forty years of literature, probabilistic record linkage, and proven open-source tooling behind it. It is the problem of deciding that "J. Smith, 14 High St" and "John Smith, 14 High Street" are one customer. The governance conversation has reinvented it without recognising it, which is why nobody is reaching for the tools that already solve it.

I recognise it because it is where Kanoniv began. Before any of this touched AI agents, the engine did customer entity resolution across CRM, billing, support, signups and partner leads. That is exactly the heterogeneous-identifier problem above, only for human customers. The worked examples are public: probabilistic linkage with Splink, deterministic reconciliation in dbt. The only thing that has changed for the agentic era is the type of entity being resolved. Customers became agents. The mathematics did not move.

There is even academic confirmation that this is the live failure mode. A January 2026 paper on agent identity naming makes the same point structurally: when an agent's identifier is bound to its location, migrating between providers or federating across organisations breaks references and fragments audit trails, leaving you unable to tell whether a later entry is the same agent or a different one. "Same or different?" is not a cryptography question. It is the defining question of entity resolution.

What a cross-system attribution layer actually has to do

I'm not going to hand you our engine. But the shape of the solution is not a secret, and the architecture makes the boundary clean: the resolution layer is where the hard work lives, so describing its job gives nothing away.

A cross-system attribution layer has four jobs. First, ingest and normalise: take signed logs from systems that share no common schema and project them into one action grammar, so a CRM read, a billing mutation and a ticket closure are comparable events. Second, find the surviving signal: across namespaces you rarely share a key, but you often share weaker evidence, like timing and causal adjacency, a correlation token that survived one hop, a payload fingerprint, or a delegation proof that names a parent authority. Third, link probabilistically: compute, from that evidence, the judgement that these N records across M systems are one actor's one task, with an explicit confidence. Fourth, and this is the part the integrity crowd will appreciate, sign the judgement itself, because an attribution you can't independently review is just one more unverifiable claim, and we did not climb out of that hole only to fall back into it.

Why is this hard? Because with no shared key you are doing inference, not lookup, and inference has to be calibrated. The two failure modes are opposite and both are compliance failures: a false merge invents an action the agent never took, and a false split conceals one it did. You have to be honest about confidence, and you have to show your working to someone whose job is to disbelieve you.

And it still breaks. When two systems share no overlapping signal at all (air-gapped namespaces, clocks skewed past the point of usefulness, PII redaction so aggressive it strips the very features linkage depends on), attribution degrades to a probability you may not be willing to sign. I would rather state that limit plainly than paper over it. A vendor who tells you cross-system attribution is always solvable is selling you the same overconfidence that made unsigned logs worthless.

It gets worse, and that's the wager

If you deploy one agent against three systems, this is a contained, solvable problem most days. But that is not where any of this is going.

Multi-agent pipelines are the direction of travel, and the regulation has already arrived there. Recitals 99 and 100 of the AI Act pull every agent in a high-risk chain into scope; the compliance boundary is the entire action layer, not the model at the centre of it. Each agent you add, and each system each agent touches, multiplies the boundary crossings. Integrity scales linearly: you sign more logs. Attribution scales with the connections between those logs, which is the part that grows fastest and the part nobody is building. The skipped problem is the one that compounds.

We made a bet about this, and you can read it directly off our pricing. We open-sourced the integrity layers (identity, delegation, verifiable tool calls) and gave them away. We kept cross-platform resolution and signed provenance as the paid layers. That split is not a packaging trick. It is a claim about where the hard, durable value sits. If signing were the difficult half, that is what we would charge for. We gave it away because it is finished.

The half worth paying for is the half this entire conversation keeps deferring: proving, across systems that were never designed to agree on a name, who actually did it. You can log everything, sign every line, and retain it for six months exactly as the Act requires, and still stand in front of a regulator unable to answer the one question the logs were supposed to answer. Integrity tells you the record wasn't changed. Only attribution tells you whose record it is.

On timing

As of June 2026, the high-risk obligations that include Article 12 have been provisionally deferred by the Digital Omnibus agreement of 7 May 2026: 2 December 2027 for standalone systems, and 2 August 2028 for AI embedded in regulated products, pending formal adoption. That does not weaken the case for doing this work now, it strengthens it. The deadline moved; the problem did not. Multi-agent systems cross more boundaries every quarter, so the harder attribution problem compounds while you wait, and existing law (GDPR, product liability, sector rules) already bites on AI-caused harm regardless of when the Act's high-risk clock starts.

References

1. EU AI Act, Article 12 (record-keeping), with Recitals 99 and 100 on multi-agent scope. artificialintelligenceact.eu/article/12
2. FireTail, Article 12 and the Logging Mandate: What the EU AI Act Actually Requires. firetail.ai
3. Asqav, EU AI Act Audit Trail Requirements. asqav.com
4. Salt Security, EU AI Act compliance and the immutable AI-to-API audit trail. salt.security
5. Agent Identity URI Scheme: Topology-Independent Naming and Capability-Based Discovery for Multi-Agent Systems, arXiv:2601.14567, January 2026. arxiv.org/abs/2601.14567

The work behind this

• Kanoniv layer architecture (open Layers 0 to 2, Cloud Layers 3 to 5) and the public customer and product entity-resolution examples using Splink and dbt: github.com/kanoniv/kanoniv
• agent-auth, and the cross-engine verification spec where five independent engines verify each other's Ed25519 delegation chains (spec/CROSS-ENGINE-VERIFICATION.md): github.com/kanoniv/agent-auth