> ## Content Index
> Fetch the complete content index at: https://www.cyberverso.net/llms.txt
> Use this file to discover other available public pages before exploring further.

# Who answers for the agent
- URL: https://www.cyberverso.net/who-answers-for-the-agent/
- Published: 2026-09-06T16:41:00.000Z
- Updated: 2026-09-17T17:46:12.000Z
- Description: An assistant can buy on your behalf and document what you authorised. As a task passes between services, who preserves the limits you set, and what does it cost you to enforce them?
- Author: Paolo De Rosa
- Tags: ai, Identità digitale, Governance, #en, #tx-agent-answers, #Import 2026-09-17 18:04

An assistant can buy on your behalf, call other services and document what you authorised it to do. As a task passes from one service to another, who preserves the limits you set, and what does it cost you to enforce them? Standards, payment networks and wallets are shaping the answer from different positions, with different resources.

## The wiki: acting first, answering later

At the peak, the moderator was deleting a hundred pages a day. The agents were creating four hundred. For the moderator of DSEWiki, an old German-language wiki about software development, artificial intelligence meant weeks of clean-up.

On 4 September 2026, four researchers published an account of roughly 18,000 posts produced by agents presenting themselves as OpenAI systems, most of them on that site. The names they gave themselves were not enough to identify them. To work out where they came from, the authors cross-referenced network addresses, content and other clues, and concluded that the activity was internal to the company. In the meantime, the agents had learnt to post under an administrator's name, replacing a Latin letter in the username with a Cyrillic one.[\[1\]](#fn1)

The activity stopped in June, with a few remnants in July. OpenAI acknowledged the case on 5 September, the day after publication, and said it was working on a framework for incident disclosure.[\[2\]](#fn2) That addresses part of the problem: an incident discovered from the outside calls for a procedure. In June, the moderator would also have needed two things a disclosure procedure does not provide: a way to get the activity stopped, and someone to take responsibility for the clean-up.

The episode shows how much work it takes to attribute an action after the fact, and who ends up doing it. One organisation multiplied its capacity to act; people outside that organisation absorbed the labour of dealing with the effects.

A registry or a wallet would not necessarily have changed the course of this case. But it raises a question that also applies to the authorised uses agents are sold for: when software acts in the world, what evidence accompanies its actions, who can use it to hold someone to account, and what does that cost them? It is the moderator's question in another form: who benefits from the savings promised by automation, where does the work reappear, and who pays for it?

## The six questions behind an identity

Take a firm that instructs an assistant to buy materials within a budget of €1,000 a month. To complete an order, the assistant relies on an external service. That service might be a tool that forwards the request, another agent that decides how to carry it out, or a contractor entering into a contractual obligation in its own right. Calling all of these "sub-delegation" erases the distinctions that matter.

Two orders of €600 each fall below €1,000, but together they exceed the budget. After the first, €400 remains. Someone has to know the remaining balance before approving the second, even if the two requests arrive at the same instant. And if the firm withdraws the instruction, someone has to communicate the revocation to the services still carrying it out.

![The delegation chain: a €1,000 monthly budget, two €600 orders, a €400 remaining balance after the first order, and revocation](https://storage.ghost.io/c/df/67/df67311e-998a-4b4b-a718-6ad7e28a0af7/content/images/2026/09/fig1-chain-en.png)

This one operation involves six checks: which system is making the request; on whose behalf; for which action; subject to which limits still in force; on what basis it accesses the counterparty's systems, and what restrictions the counterparty can lawfully assert; and what consequences and remedies follow if something goes wrong.

Software identity, technical authorisation and legal authority to act on someone else's behalf answer different questions. Digital evidence documents instructions, consent and actions taken. Establishing liability for harm also requires examining duties, causation and the allocation of risk. These shape contracts, investments and behaviour long before anyone goes to court. Asking a token to contain all of that is asking it to replace the law.

There is a further question the six do not cover: whose interests did the agent serve in making its choice? A perfectly authorised purchase can favour whoever pays the assistant's provider. That is the problem of loyalty, which lies outside the scope of this article.

In [Who controls the interface](https://www.cyberverso.net/who-controls-the-interface/), I described how the power to mediate access to services shifts towards the assistant. Here that power takes a specific form: deciding which evidence to accept, which services to integrate and how easy it is to challenge an outcome. My argument is that this distribution of power is what is at stake. Whether the records preserve the limits as a task passes between services, reflect the authority of the person who granted the mandate and are accepted by their recipients depends on decisions taken in different forums, often involving the same actors. The advantage lies with those who already own the infrastructure that makes integration look simple, and those who set the cost of leaving it.

## Authorising one step, controlling the chain

![undefined](https://images.unsplash.com/photo-1773517459319-ae1dd572c974?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDExfHxhdXRob3JpemV8ZW58MHx8fHwxNzg5NjYyMDI0fDA&ixlib=rb-4.1.0&q=80&w=2000)  
Photo by [Dave Meckler](https://unsplash.com/@phosphorvs) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)

The protocols have done a substantial part of the work. Tools and agents communicate; services verify authorised requests. OAuth specifically governs authorisation: reducing it to the question "who are you?" is a common and convenient mistake. One of its extensions, RFC 9396, allows detailed requests, with examples that include a payment's amount and payee.[\[3\]](#fn3)

Another specification, RFC 8693, distinguishes the subject being represented from the actor carrying out the action, and allows a token to be exchanged for one with narrower permissions. It provides a way to represent the chain. The specification alone does not guarantee that each link will preserve the limits it receives or learn of a revocation: that also depends on the decisions of those who issue and accept the tokens.[\[4\]](#fn4)

Our monthly cap makes this distinction concrete. Writing "€1,000" into an authorisation requires you to say what it means: per order, per month, per mandate, across which recipients. Enforcing it requires a running total. Two services can read the same figure and behave differently if they do not share an understanding of the constraint and how to check it.

A discussion on the OAuth mailing list brought this distinction into focus. In February 2026, a researcher asked the group to examine a possible weakness: combining valid subject and actor tokens from different contexts to obtain a token exchange nobody had authorised. The co-author of a draft on agents agreed with the diagnosis, describing it as a gap already being addressed; an architect from AWS distinguished what a standard can require from the policies each authorisation server sets for itself. This was a public debate, not a confirmed vulnerability, and the draft proposed as the place to address it is an expired individual submission.[\[5\]](#fn5) Reading that list is free. Influencing the outcome takes staff, expertise and sustained involvement: a cost that favours those who can fund a continuing presence.

The thread leaves open which guarantees should be shared when delegations are combined, and which should remain the responsibility of each system. An identifier defined in a standard and a valid signature do not establish that two organisations have chosen the same policy. That policy depends on organisational decisions and incentives that conformance to the specification does not determine.

In payments, some specifications address these very controls. This is where the relationship between those who authorise, those who keep the running total and those who accept the evidence becomes concrete.

## E-commerce: access, aggregation, evidence

Access has already reached the courts. In November 2025, Amazon sued Perplexity over the assistant in its Comet browser, which could operate within customers' accounts. On 9 March 2026, the federal district court in California granted a preliminary injunction: the users' permission did not substitute for Amazon's authorisation.[\[6\]](#fn6)

On 4 August, the US Court of Appeals for the Ninth Circuit vacated the injunction. In the architecture it examined, the user's browser communicates with Amazon; Perplexity receives screenshots and sends back instructions. For the purposes of the Computer Fraud and Abuse Act provision at issue, the assistant is a tool and the user is the party accessing Amazon. On the preliminary record, Amazon was unlikely to establish that Perplexity itself had accessed its systems within the meaning of that provision. The court addressed only that requirement, leaving the remaining issues undecided.[\[7\]](#fn7)

The decision does not give agents a general right to access services. It makes a more interesting point: the legal characterisation of access depends on how the intermediary operates, down to who captures the screenshot. The user's mandate and the restrictions the counterparty can lawfully assert remain separate questions. In the wiki case, the task was to establish where the activity came from; here, it was to determine how the law should treat access. In both cases, knowing the name of the software would not have been enough.

Meanwhile, the payment networks are building arrangements in which that identity does matter. Visa's Trusted Agent Protocol, announced with Cloudflare in October 2025, attaches time-limited signatures to the agent's requests, bound to the recipient and the path, with controls against replay. The merchant verifies the key through a directory operated by Visa, and the documentation refers to "Visa-approved" agents.[\[8\]](#fn8) Here, a registry is no longer a metaphor. The directory is a concrete part of its operator's ecosystem, not a registry of all agents. For the materials supplier in our example, a verifiable signature can offer a reason to accept a request that a user-agent string claiming to be Chrome cannot.

For the assistant's developer, being recognised means gaining access to the market. Commercial power arises here: in the conditions of admission and the cost of operating outside an established integration.

Visa Intelligent Commerce Connect, announced on 8 April 2026 and then in its pilot phase, offers a single integration through Visa's acceptance platform for payments initiated through four protocols with different functions. Mastercard had announced registered agents and dedicated tokens as part of Agent Pay in April 2025\. Both make the same promise: to fit the new transactions into infrastructure that merchants and banks already use.[\[9\]](#fn9)

That promise is credible because Visa and Mastercard already have commercial relationships, dispute procedures and infrastructure that banks and merchants have paid for. Reusing an integration can reduce the initial work. Dependence needs to be assessed elsewhere: in the contracts, the changes required to switch providers, and whether access to records of past transactions survives the switch. Supporting several protocols can make a service easier to join without making it equally easy to leave. The political question is who can make entry into their system attractive, and what it costs to get out.[\[10\]](#fn10)

The third step is proof of intent. AP2 describes mandates with constraints, bound to the agent's key and later completed with transaction details. It provides two trust models. In the first, the user approves through a system that signs with the key associated with the user's credential. In the second, the assistant's provider collects consent and signs with its own key. This changes who attests to the approval and whom the verifier trusts, shifting that trust towards the platform. It does not determine who must compensate for any harm, and the specification also provides for mandates stored by the agent and signed receipts. But it raises a question: how dependent is the user on the intermediary when they need to use that evidence against it?[\[11\]](#fn11)

![AP2's two trust models: signing with the key associated with a user credential, or with the agent provider's own key](https://storage.ghost.io/c/df/67/df67311e-998a-4b4b-a718-6ad7e28a0af7/content/images/2026/09/fig2-ap2-en.png)

AP2 also addresses our budget. The specification requires adding the requested amount to cumulative spending under the mandate, checking the resulting total against the limit, and updating the total after approval. Mastercard's Verifiable Intent assigns the network a cumulative check across the relevant mandates. The problem has not been ignored.[\[12\]](#fn12) What remains to be verified is how an implementation applies those controls to the monthly period, simultaneous requests and transactions outside the mandate.

The weakness lies in how those controls are put into use. If the firm spreads its purchases across different services, it has to decide whether to split the budget or have them all consult a shared spending record. Two separate mandates of €1,000 each can be honoured to the letter and still breach the overall cap. That is an error in how the delegation was configured, and no valid signature corrects it. Whoever configures the system must be able to show how the company's limit became an operational limit, and who updates it.

Verifiable Intent, in turn, structures signed evidence that, in its autonomous mode, links the credential, the holder's authorisation and the agent's execution of the task; authenticating the person is left to the implementation. These records can support a dispute, but their acceptance in a commercial procedure must be distinguished from their legal value. A network governs its own procedures, and the cost of taking a dispute elsewhere gives it a practical advantage that no specification explicitly assigns to it.[\[13\]](#fn13)

This is where the European Digital Identity Wallet (EUDI Wallet) enters the picture. AP2 and Verifiable Intent reuse technologies also found in that environment, including credentials that allow selected attributes to be disclosed. Shared components make it plausible to link these records. For a wallet to interpret an agentic mandate, however, the meanings, controls and trust in issuers must also align. The contributions reached the FIDO Alliance in April 2026, and it is worth looking at who receives them: the payments group tasked with examining them is chaired by members from Mastercard and Visa, and the new agentic authentication group by members from CVS Health, Google and OpenAI. These roles show that the companies selling intermediation services also help write the common rules. A contribution begins that process; it does not complete it.[\[14\]](#fn14)

For the firm, the question comes down to this: did the person who authorised the assistant have the authority to commit the company to that expenditure? Evidence of consent and evidence of authority to bind the company can be linked. What remains to be verified is who accepts that link as sufficient, and on what terms.

## Public frameworks viewed from the outside

![undefined](https://images.unsplash.com/photo-1608817576136-0f3a56922823?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDE4fHxldXJvcGV8ZW58MHx8fHwxNzg5NjYyMjM4fDA&ixlib=rb-4.1.0&q=80&w=2000)  
Photo by [Christian Lue](https://unsplash.com/@christianlue) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)

European law already provides some of the foundations. The EUDI Wallet framework, Regulation 2024/1183, covers natural and legal persons, wallets and electronic attestations of attributes. It prohibits denying an attestation legal effect or admissibility as evidence solely because it is electronic or non-qualified, and gives specific legal effects to certain qualified and public categories.[\[15\]](#fn15)

A private credential can therefore have legal value. What matters is what it attests, who vouches for it and against whom it can be relied on. Payments and identity also intersect through private services that produce legally relevant evidence, as they have since the introduction of electronic signatures.

The attributes covered include powers of representation, subject to conditions concerning sources, applicable law and implementation. In our example, an attestation can document the authority to bind the firm. Whether that authority covers the expenditure, and how the services involved apply the limit, still needs to be checked. Recognising a role does not replace checking the €400 still available.[\[16\]](#fn16)

The AI Act already applies to agents too: the Commission explains in its FAQ that they fall within the existing definitions, with obligations depending on their characteristics, use and the roles of the parties involved. For business identity, there is also the European Business Wallet proposal, intended to support organisations' identity and interactions. Together with the EUDI Wallet, it could provide a means of linking legal authority to act on another's behalf with an agent's mandate, giving that link legal effect and addressing the very gap described here: an answer the market cannot provide on its own.[\[17\]](#fn17)

Other initiatives make the boundary between public and private less clear-cut. The vLEI links organisational identities and roles. GLEIF, which governs it, is a foundation overseen by a committee of public authorities. That does not make its credentials equivalent to European qualified attestations.[\[18\]](#fn18)

The UNCITRAL Model Law on Automated Contracting, adopted in 2024, addresses attribution. It gives priority to the procedure agreed between the parties and, in its absence, attributes the action to whoever uses the system for that purpose, while keeping the legal consequences separate. It is a model, not a rule in force everywhere. It shows that automated acts already have a legal framework; the law does not have to wait for the protocols.[\[19\]](#fn19)

A public framework should be judged by the rights it makes possible to exercise: access to evidence, the ability to challenge a refusal, portability and protection for those outside the agreements between operators. Well-drafted rights do not enforce themselves. They require authorities with the expertise and resources to uphold them, enforceable obligations on those holding the information, remedies that individuals and small firms can afford, and the ability to act collectively when the harm is small for each person but large in aggregate. A public framework also has effects when it offers weak protection: it recognises intermediaries, distributes compliance burdens and makes some infrastructures more attractive than others. It should be judged by which power relations it reinforces and which it makes open to challenge. A public label alone does not tell us whether a small firm can get its delegation recognised by a dominant service.

## Singapore: organising control today

![undefined](https://images.unsplash.com/photo-1491542451321-54b31bd2d961?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDc5fHxzaW5nYXBvcmV8ZW58MHx8fHwxNzg5NjYyMzcyfDA&ixlib=rb-4.1.0&q=80&w=2000)  
Photo by [Lily Banse](https://unsplash.com/@lvnatikk) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)

Singapore offers a useful comparison on the organisational work that no standard can do on an organisation's behalf. The Cyber Security Agency's addendum on agentic systems proposes mapping workflows, applying controls throughout the lifecycle and taking the degree of autonomy into account. Version 1.5 of the IMDA framework sets out four dimensions: defining and containing risks, making human accountability effective, putting technical controls in place and encouraging informed use. These are guidance documents.[\[20\]](#fn20)

For our firm, this means deciding who sets the budget, who oversees the connected services and who steps in when the system does something other than what was intended. If nobody has the actual authority to suspend an operation, the human supervisor is a name on an organisational chart. A signature at the start of a project does not maintain control once the system is in use.

An IMDA discussion paper on legal responsibility for agents' actions brings remedies into the discussion. Existing law already provides tools, but reconstructing the facts and allocating responsibility remain difficult, especially for those with less information and bargaining power.[\[21\]](#fn21) This is the same asymmetry the German moderator faced, described by a public authority.

Even when a delegated task is carried out correctly, we still do not know what it would have cost to challenge an abuse of that authority.

## The citizen: evidence, privacy, remedies

![undefined](https://images.unsplash.com/photo-1567458927686-b8dacba3749d?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3wxMTc3M3wwfDF8c2VhcmNofDQwfHxjaXRpemVuc3xlbnwwfHx8fDE3ODk2NjIxNDZ8MA&ixlib=rb-4.1.0&q=80&w=2000)  
Photo by [Sonder Bridge Photography](https://unsplash.com/@sonderbridgephotography) / [Unsplash](https://unsplash.com/?utm%5Fsource=ghost&utm%5Fmedium=referral&utm%5Fcampaign=api-credit)

Consider the same purchases from an individual's perspective. The spending cap offers an immediate example: it has to constrain the assistant, but disclosing it to the seller can weaken the buyer's position. The mandate contains information needed to govern the agent, with no reason for it to become commercial intelligence for the counterparty. Knowing that a €600 order is authorised is one thing; knowing the buyer's entire monthly budget is another.

Making the delegated authority verifiable does not require every participant to receive all the information. The same distinction applies to the firm: attributing a purchase to the organisation does not require disclosing the details of the employee who authorised it. The questions are always who needs to know the identity, for what check and for how long. A record used to resolve a dispute can, when reused elsewhere, become a means of tracking someone across services.

AP2 and Verifiable Intent provide for selective disclosure and the separation of information. These are relevant tools: some recipients receive only what they need for their task. What still needs to be established is who sees the constraints and who attests that they were met. Hiding a figure does not prove that a purchase falls below it. Someone in the chain must perform a check the others can rely on. In the Verifiable Intent model, the network checks payment constraints while other participants retain their own verification roles. Citizens can choose a service; the architecture it uses to verify their mandate is not theirs to decide.[\[22\]](#fn22)

Disclosing fewer attributes does not make two transactions impossible to link. Keys, identifiers and metadata may be enough to connect them. The design question is concrete: which parties can recognise the same delegation, using what information, and who ensures that those data are used to verify the transaction rather than build a permanent history of someone's commercial activity?

The other side is the right of access to evidence. If a second €600 charge appears, the customer must be able to reconstruct the instructions, remaining budget, approvals and actions taken. AP2 provides a signed receipt recording the outcome of authorisation; Verifiable Intent provides a chain of credentials that can be used in disputes. These are different forms of evidence, and an authorisation receipt does not document the entire execution of a task.[\[23\]](#fn23)

Control over evidence can lie at different stages: producing the attestation, retaining the underlying data, allowing it to be exported and accepting it in a dispute. We should demand a clearly identified organisation to turn to, reasonable response times and access to the relevant evidence. Customers should not have to work out for themselves which of five providers holds the record of the decisive step. Protocols make evidence verifiable; service terms and the law must specify who is obliged to provide it, retain it and assist with a dispute. Documenting everything while giving the person concerned access to nothing concentrates control in the hands of those keeping the records, in the name of transparency.

Stopping the assistant, revoking its authority and undoing a contract already concluded are three distinct things. Revocation must reach anyone who might still act. The remedy for a completed purchase depends on what happened and the applicable rules; even the right of withdrawal available for many distance contracts has exceptions.[\[24\]](#fn24)

Protection should be measured by whether people can use it: to correct a limit, switch providers or challenge an outcome without losing the evidence. A safeguard available only while you remain a platform's customer leaves that platform with the power to set its price.

## Making delegation effective

In the wiki case, the gap between acting and answering for it became human labour, unpaid labour at that. The agents generated activity faster than the people dealing with its effects could reconstruct it. In commercial services, recognition, controls and receipts can narrow that gap. But it must be measured from the perspective of those who need an answer, not those who keep the records.

The quality of the chain linking legal authority to a verifiable action depends on which parts of the mandate accompany the task as it passes between services, who verifies them and who can enforce them.

Control is distributed across concrete decisions: admitting an agent, accepting a credential, updating a budget, retaining a receipt and responding to a complaint. Each can be reasonable for the party making it and costly for someone trying to obtain a refund. The overall result can emerge without anyone having designed it in full. Yet the decisions that produce it remain in the hands of identifiable parties. Those running the infrastructure set the conditions of access, evidence retention and dispute resolution; those using it must also reckon with the cost of leaving. Dependence is built through these choices and the unequal capacity to negotiate them.

A public framework has value if people can exercise those rights outside the commercial network in which the delegation originated, and if someone has the means to enforce them.

The question of choice remains: whose interests does the agent serve when it decides which offer to show us? The selection of offers and the assistant's conflicts of interest take us beyond what authorisation alone can explain. Before that, anyone delegating a task must be able to control the mandate and obtain an account of how it was carried out.

Delegating an action should leave us with the power to limit it and to demand an account of it.

\*\*\*The information and views set out in this article are those of the author and do not necessarily reflect the official opinion of the European institutions  
\*

## Notes and sources

Sources checked on 17 September 2026\. Technical specifications without an immutable version describe the state of the documentation consulted, not uniform adoption in products.

---

1. Sydney Von Arx, Cormac Slade Byrd, Spencer Kitts and Thomas Larsen, [Discovery of a new OpenAI agent message board](https://collusion.wiki/), 4 September 2026\. The researchers distinguish more than 3,700 self-assigned names. The 98.5% figure concerns roughly 17,000 DSEWiki edits attributed to the agents. Activity collapses on 22 June; remnants appear on 1–2 July. [↩︎](#fnref1)
2. [TechCrunch, 5 September 2026](https://techcrunch.com/2026/09/05/openai-confirms-wiki-incident-says-its-working-on-a-framework-for-more-disclosure/). The [official OpenAI post](https://x.com/OpenAI/status/2096133504417616165) is identified through the press coverage but was not retrieved directly for this check. [↩︎](#fnref2)
3. IETF, [RFC 9396, OAuth 2.0 Rich Authorization Requests](https://www.rfc-editor.org/rfc/rfc9396.html), May 2023\. At different layers there are also [MCP](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization), for access to tools, and [A2A](https://a2a-protocol.org/latest/specification/), for communication between agents. The authorisation MCP describes concerns HTTP transports; it is not mandatory for every implementation of the protocol. The [WIMSE architecture](https://datatracker.ietf.org/doc/draft-ietf-wimse-arch/) is an IETF working group draft; [AuthZEN](https://openid.net/wg/authzen/specifications/) distinguishes the final Authorization API from profiles still in draft. [↩︎](#fnref3)
4. IETF, [RFC 8693, OAuth 2.0 Token Exchange](https://www.rfc-editor.org/rfc/rfc8693.html), January 2020, in particular §§1, 2.1 and 4.1\. The specification distinguishes subject and actor; a history of nested actors is not by itself an authorisation policy for the whole chain. [↩︎](#fnref4)
5. OAuth list: [Chhaya, 27 February 2026](https://mailarchive.ietf.org/arch/msg/oauth/6MHkSfhGfugVmcb2p08ocM7piqQ/); [Dissanayaka, same date](https://mailarchive.ietf.org/arch/msg/oauth/G2ZDGCcwSGWdg6tZ%5FKC8-dksa-E/); [Lombardo, 12 March](https://mailarchive.ietf.org/arch/msg/oauth/ADHZL-o9W6EjIdPD8zSpNMEqRvk/); [Chhaya's reply, 13 March](https://mailarchive.ietf.org/arch/msg/oauth/raNBfRf9DrYuLLf1TOry9YoQ7xM/). Chhaya states that Claude and Gemini assisted. [Status of the on-behalf-of draft](https://datatracker.ietf.org/doc/draft-oauth-ai-agents-on-behalf-of-user/): individual, expired and archived. [↩︎](#fnref5)
6. N.D. California, [order of 9 March 2026, case 3:25-cv-09514-MMC](https://www.govinfo.gov/content/pkg/USCOURTS-cand-3%5F25-cv-09514/pdf/USCOURTS-cand-3%5F25-cv-09514-0.pdf). The preliminary assessment was subsequently superseded by the vacatur of the injunction. [↩︎](#fnref6)
7. Ninth Circuit, [opinion of 4 August 2026, case 26-1444](https://cdn.ca9.uscourts.gov/datastore/opinions/2026/08/04/26-1444.pdf), pp. 15–17 and footnote 5 at p. 21\. [Rehearing en banc was denied on 10 September](https://www.courthousenews.com/wp-content/uploads/2026/09/amazon-perplexity-no-rehearing.pdf); that does not conclude the case as a whole. [↩︎](#fnref7)
8. Visa Developer, [Trusted Agent Protocol Specifications](https://developer.visa.com/capabilities/trusted-agent-protocol/trusted-agent-protocol-specifications). TAP uses HTTP Message Signatures, RFC 9421, in alignment with Web Bot Auth. Replay protection requires tracking nonces. Tags distinguish browsing from payment; the specification also contemplates other payment schemes and key-retrieval methods. [↩︎](#fnref8)
9. Visa, [Intelligent Commerce Connect announcement](https://visa.gcs-web.com/news-releases/news-release-details/visa-opens-door-ai-driven-shopping-businesses-worldwide), 8 April 2026: TAP, Machine Payments Protocol, Agentic Commerce Protocol and Universal Commerce Protocol. Mastercard, [Agent Pay announcement](https://www.mastercard.com/global/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html), April 2025\. Announcements, availability and the features of implementations should be kept distinct. [↩︎](#fnref9)
10. The discussion of entry and exit costs describes a possible mechanism, not measured costs: the sources document the integrations on offer, not their costs. On how quickly the arrangements for agentic checkout change, and on the fact that the networks were present from the start: [OpenAI launch with Stripe](https://openai.com/index/buy-it-in-chatgpt/), 29 September 2025; [Mastercard involvement](https://www.mastercard.com/my/en/news-and-trends/stories/2025/agentic-commerce-momentum.html), 30 September; [OpenAI's change of emphasis](https://openai.com/index/powering-product-discovery-in-chatgpt/), 24 March 2026; [Visa–OpenAI announcement of 10 June](https://investor.visa.com/news/news-details/2026/Visa-Partners-with-OpenAI-to-Power-the-Next-Generation-of-AI-Commerce/default.aspx), which describes capabilities to be integrated. On disputes, [Mastercard, Agentic Commerce Q3](https://innovationinsights.mastercard.com/mastercard-agentic-commerce-q3) discusses the evolution of procedures and liability: the networks' dispute functions operate alongside applicable law and do not guarantee the same remedy for every purchase. [↩︎](#fnref10)
11. [AP2 Agent Authorization Framework](https://ap2-protocol.org/ap2/agent%5Fauthorization/), User Credential and Trusted Agent Provider models. The specification uses OpenID4VP with `transaction_data` and SD-JWT VC, recommends the Digital Credentials API where available and anticipates an adaptation for mdoc. The [Delegate SD-JWT](https://datatracker.ietf.org/doc/draft-gco-oauth-delegate-sd-jwt/) primitive is an individual Internet-Draft. [↩︎](#fnref11)
12. [AP2 Payment Mandate, Budget](https://ap2-protocol.org/ap2/payment%5Fmandate/#budget), together with `payment.agent_recurrence`; [Verifiable Intent, §5.3](https://verifiableintent.dev/spec/). These are requirements of the respective schemes: the organisation's budget, the mandates issued and any renewal periods have to be reconciled in the implementation. [↩︎](#fnref12)
13. Verifiable Intent, [Overview](https://verifiableintent.dev/spec/) and [Security Model](https://verifiableintent.dev/spec/security-model/), in particular §2.4\. The specification consulted is a draft; it distinguishes an immediate mode and an autonomous mode. It does not prescribe FIDO biometrics as an intrinsic requirement of the format. [↩︎](#fnref13)
14. FIDO Alliance, [announcement of the AP2 and Verifiable Intent contributions](https://fidoalliance.org/fido-alliance-to-develop-standards-for-trusted-ai-agent-interactions/), 28 April 2026, and [follow-up on reusing wallet infrastructure](https://fidoalliance.org/building-the-trust-layer-for-agentic-payments-with-ap2-and-verifiable-intent/), 26 May. For the EUDI components, the [reference implementation's Feature Map](https://docs.eudi.dev/latest/reference-implementation/feature-map/). [↩︎](#fnref14)
15. [Regulation (EU) 2024/1183](https://eur-lex.europa.eu/eli/reg/2024/1183/oj/eng), amending eIDAS. Article 45b distinguishes the prohibition on discriminating against attestations for being electronic or non-qualified from the specific effects of qualified attestations and of those issued by or on behalf of the public body responsible for an authentic source. [↩︎](#fnref15)
16. Same adopted regulation, Article 45e and Annex VI: powers and mandates of representation are contemplated within the framework for verifying attributes, with conditions relating to public authentic sources, the user's request, national law and implementation. It does not follow that every spending limit is already available everywhere as an attested attribute. [↩︎](#fnref16)
17. European Commission, [FAQ on how the AI Act applies to agents](https://ai-act-service-desk.ec.europa.eu/en/ai-act/faq/how-are-ai-agents-addressed-within-ai-act-0). For the Business Wallet: [public presentation of the initiative](https://digital-strategy.ec.europa.eu/en/library/european-business-wallets-nutshell) and [EUR-Lex reference to the proposal](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A52025PC0838). The reference concerns only the existence and stated purpose of the proposal. [↩︎](#fnref17)
18. GLEIF, [Regulatory Oversight Committee](https://www.gleif.org/en/about/governance/regulatory-oversight-committee-roc/roc-observers). The foundation's public oversight should be distinguished from the legal effects of each use of vLEI credentials. [↩︎](#fnref18)
19. UNCITRAL, [Model Law on Automated Contracting with guide](https://uncitral.un.org/sites/uncitral.un.org/files/2424674e-mlautomatedcontracting-rev1-ebook.pdf), Article 7; [institutional page](https://uncitral.un.org/en/mlac). Model adopted on 11 July 2024; attribution and legal consequences remain distinct. [↩︎](#fnref19)
20. CSA, [Addendum on Securing AI Systems](https://www.csa.gov.sg/resources/publications/addendum-on-securing-ai-systems/), page dated 17 June 2026; an inconsistency remains between references to the consultation and the PDF's chronology, so no definitive approval date is asserted here. IMDA, [Model AI Governance Framework for Agentic AI](https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/mgf-for-agentic-ai.pdf), v1.5, published 20 May and updated 5 June 2026\. [↩︎](#fnref20)
21. IMDA, [Legal Responsibility for AI Agents](https://www.imda.gov.sg/-/media/imda/files/about/emerging-tech-and-research/artificial-intelligence/agents-legal-responsibility.pdf), discussion paper, May 2026, summary and discussion of the applicability of existing law and access to remedies. [↩︎](#fnref21)
22. [AP2 Security and Privacy Considerations](https://ap2-protocol.org/ap2/security%5Fand%5Fprivacy%5Fconsiderations/) and [Verifiable Intent, §4.3](https://verifiableintent.dev/spec/). Separating information between recipients is not a guarantee that every constraint can remain hidden from whoever has to verify it. [↩︎](#fnref22)
23. AP2, [Action Authorization and Mandate Receipt](https://ap2-protocol.org/ap2/agent%5Fauthorization/); Verifiable Intent, [Dispute Evidence](https://verifiableintent.dev/spec/security-model/). The AP2 receipt concerns the outcome of the authorisation; the VI chain constitutes evidentiary material, leaving dispute procedures and the allocation of liability to the applicable rules. [↩︎](#fnref23)
24. Your Europe, [withdrawal and returns](https://europa.eu/youreurope/citizens/consumers/shopping/returns/index%5Fen.htm), including the exceptions. An authenticated order, a binding contract and a correctly performed assistant service are matters to be verified separately. [↩︎](#fnref24)