When an AI agent acts autonomously and something goes wrong, the legal question is rarely limited to what the agent did. It is whether anyone can prove what it was authorised to do.
One US court has already ruled on a version of that question, and two more active lawsuits circle a related blind spot. Corporate counsel have reason to ask their CIOs for tamper-evident authorisation records, and many organisations would struggle to produce one, because the infrastructure to create such a record barely exists. The gap is not really about documentation. It is about infrastructure for producing defensible evidence.
The Case That Draws the Line
Start with the case that rules on it most directly. In Amazon v. Perplexity, a federal court granted Amazon a preliminary injunction in March 2026 that would have barred Perplexity’s Comet shopping agent from the password-protected areas of Amazon.com, including account pages, order history and checkout.
Applying the Computer Fraud and Abuse Act, the court found at this stage that a user instructing an agent to act does not, by itself, establish authorisation from Amazon to reach those areas. The Ninth Circuit stayed the injunction days later while it considered Perplexity’s appeal, so the legal position remains unsettled.
But the distinction it turns on is the one that matters here: a user’s instruction is not necessarily the same thing as legally recognised authority. Where those differ, authority may depend on the record of what each relevant party permitted, not only the intent behind an instruction.
The same blind spot is surfacing in suits that have nothing to do with online shopping.
In Commonwealth of Pennsylvania v. Character Technologies, the state alleges that Character.AI chatbots presented themselves as licensed medical professionals, an unauthorised practice of medicine.
In Nippon Life Insurance Company of America v. OpenAI, the insurer alleges that ChatGPT engaged in the unlicensed practice of law by helping a self-represented litigant reopen a settled claim. OpenAI has moved to dismiss the case, arguing that ChatGPT is a tool rather than a legal practitioner and that responsibility rests with the user.
Neither is a delegated-access case. But each could force an adjacent question in discovery: who defined what this system was allowed to do, and can they prove which boundaries were in force when it acted?
Why Existing Logs Are Hard to Defend
Ask a general counsel where the record proves an agent acted within its authorised scope, and the honest answer, in most organisations, is that it depends which system you check. Enterprise AI governance has prioritised capability over accountability, and many of the authorisation records that do exist were not built to withstand legal scrutiny.
Application-layer audit logs are valuable for operations and debugging, but their evidentiary strength depends on how they are created, protected and retained. Unless they use append-only controls, signed events, trusted timestamps or equivalent safeguards, administrators may be able to modify them. They capture what the system was configured to record, not necessarily an independently verifiable account of what happened when the agent acted.
Conventional ledger logs are more durable, but durability is not proof of authority. On its own, such a log does not verify that the signer had the power to authorise the agent or bind that authorisation to a legally accountable principal. It is a ledger entry, not automatically a proof of authority.
A defensible authorisation record needs three properties at once: created at the moment of authorisation, cryptographically bound to an accountable identity and tamper-evident. Many application-layer setups do not deliver all three together, and those that do essentially rebuild protocol-level guarantees in-house.
A suitable protocol can provide those guarantees by default, although the legal meaning of the recorded authority still depends on how it was defined and who had the power to approve it.
What Protocol-Level Authorisation Actually Means
The alternative is to record authority one layer down, in the protocol rather than in any single application, so the record of who stood behind an agent, and what scope was declared for it, lives in shared infrastructure both sides of a dispute can verify independently, not in one company’s database.
The difference from application-layer logging is architectural, not semantic.
This is an emerging field, not a solved one. Standards such as ERC-8004 and W3C decentralised identifiers give an agent a persistent handle and, in ERC-8004’s case, a reputation and validation trail.
What they do not automatically establish is accountability: who, in the real world, stands behind the agent and had the authority to register it. Protocol-level authorisation records aim to answer that, and more than one approach is taking shape.
Concordium’s Agent Registry is one such approach. It gives each agent an on-chain identifier and uses the CIS-8004 Agent Registry standard, adding an accountability layer through Concordium’s identity system.
When an agent is registered, the chain records its owner, active status, metadata location and a cryptographic hash of its Agent Card. The published card cannot later be replaced without the chain exposing the mismatch.
That distinction matters. Being recorded on a blockchain does not make every action performed by the agent public. It makes public the information submitted to the blockchain.
For the Agent Registry, that includes the registration transaction, the agent’s identifier, its owning account address, its status, the Agent Card location and the card’s cryptographic hash. The Agent Card itself is hosted at a public URL and may include the agent’s description, provider, capabilities and service endpoints.
What is not automatically public is the agent’s off-chain activity: its prompts, API calls, internal decisions, customer interactions or execution logs. Those remain inside the systems where the agent operates unless they are separately recorded or published.
The identity behind the owning account is also not publicly exposed. Concordium’s identity framework separates a public account address from the personal information connected to the verified identity behind it.
That model works in three parts.
What is proven: the chain records that an accountable Concordium account owns this agent and that its published Agent Card is the same version committed on-chain. Where that card declares the agent’s scope and boundaries, anyone can verify that the declaration has not been silently replaced.
What stays hidden: the personal data behind the account’s verified identity is never written to the chain. The public can see the owning account address without seeing the name or personal details behind it.
When it can be disclosed: under the applicable legal process, the identity connected to the account can be disclosed through Concordium’s identity disclosure process, involving the relevant authority, Privacy Guardians and Identity Provider. No single company or network participant can reveal it alone.
The record itself is tamper-evident, so any later change to the committed Agent Card is detectable.
There is also a privacy trade-off.
If an organisation writes an agent’s full permission policy directly into the public Agent Card, those permissions become publicly readable. A company that wants to keep detailed permissions confidential could instead commit a cryptographic hash of a private policy.
During an audit or dispute, it could produce the original policy and show that its hash matches the commitment recorded at the relevant time. That approach can prove the policy has not changed, without publishing its full contents in advance. It is technically possible, but it is not currently a standard authorisation feature built into the Agent Card format.
A concrete case makes the boundaries clear.
A bank registers a customer-service agent authorised to retrieve account information but not to initiate transfers. It includes that scope, its version and the moment it took effect in the Agent Card, or in a private policy whose hash is referenced by the card, before committing the record to the Registry.
If a transfer later goes wrong, the bank can show that the committed version of the policy never granted that power, and can prove which accountable account registered it and when.
It cannot prove from the Registry alone that the account holder had the correct internal corporate mandate or that the agent followed the restriction during execution.
The same example shows the limits. Three layers stack up.
Identity: who stands behind the agent.
Declared authority: the scope and boundaries committed for it, and when that version took effect.
Execution evidence: what the agent actually did, and whether each action stayed inside that authority.
The Registry is strongest on the first and on preserving the integrity of the second. Proving the third still needs execution logs, ideally signed with the agent’s registered key and tied back to the relevant record.
Protocol-level registration does not replace that layer; it gives it a verifiable foundation to attach to. And like any shared standard, it is only as useful as its adoption: a record helps only if a counterparty or a court can verify it, and the conventions for agent identity are still being written.
The Liability, Compliance and Procurement Consequences
On liability: when an enterprise can produce a tamper-evident record of who stood behind an agent and the scope declared for it, and can tie the agent’s actions back to that record, its position in a dispute changes.
It is no longer only asserting that it governed the agent responsibly. It is showing the record.
On compliance: the EU AI Act requires high-risk AI systems to support automatic logging of events over the lifetime of the system under Article 12.
Providers must retain logs under their control under Article 19, while deployers have related retention duties under Article 26. The minimum period is six months unless other applicable law requires a different period.
Following the political agreement reached in May 2026, the high-risk rules are set to apply from 2 December 2027 for systems used in areas including biometrics, critical infrastructure, education and employment, and from 2 August 2028 for systems integrated into regulated products.
A protocol-level record could help support that expectation by design rather than by procedure. But it is an enabling layer, not a complete compliance programme: conformity still rests on governance, oversight, documentation, execution logging and retention.
What the record strengthens is the assumption that the identity, policy or declaration underneath that evidence was captured faithfully in the first place.
On procurement: legal and risk teams have reason to ask vendors a question that rarely appeared on earlier checklists: where does your authorisation record live, and can it survive discovery?
The answer “in our database” no longer settles it unless the vendor can explain how that database prevents undetected alteration.
The model Concordium offers is not one in which all agent activity becomes public. It is one in which selected facts about the agent can be made independently verifiable.
The registration, owning account, status and committed Agent Card are public. The personal identity behind the owner remains protected. The agent’s off-chain activity remains private unless the operator chooses to record or disclose it.
The record exists and can be produced. That is the point.
The Foundation for Regulated AI Deployment at Scale
As AI agents take on more consequential roles in financial services, healthcare and critical infrastructure, the authorisation question moves to the centre of enterprise governance.
Recorded at the protocol level, it is not a compliance tool bolted on after the fact but part of the foundation regulated AI deployment will need, and the Agent Registry is one way to put it in place.
The question, then, is not whether your organisation needs authorisation records it can defend. It is whether your current deployment could withstand the kind of scrutiny these three cases are beginning to create.
Records held in mutable systems may give you operational control without defensible proof. Unless changes are detectable, identities are accountable and execution evidence can be tied back to the authority in force at the time, that is the distinction discovery will expose.