The AI agent is already acting on your behalf — and the question nobody can properly answer yet is: how do you prove you actually authorized it?
Picture this: you asked an AI agent to find a shirt for under $30, but you made it crystal clear — do not buy anything. The agent finds the shirt. And makes the purchase anyway. When you try to dispute the charge, every company involved shows its piece of the story: the store says the order came from your account, the agent provider shows the instruction was just to search, and the payment service confirms the transaction. Each record might be correct. But none of them connects the charge to the task you actually gave: search, but do not buy.
This scenario did not come from a sci-fi script. It is a real technical and legal gap that is already forming as AI agents gain more and more autonomy to act on our behalf across different systems, from different companies, without a verifiable chain of authorization tying it all together. And the problem gets a lot more serious when we stop talking about shirts and start talking about money transfers, medical orders, or benefit appeals. But let us take it one step at a time. 👇
What changes when an agent acts in your place
A traditional chatbot suggests a shirt and waits. An AI agent can use your account, contact other services, and complete the transaction on its own. A single sentence triggers a sequence of actions spread across systems operated by different companies. And here is the critical point: each company can only verify the part it sees. Resolving a dispute requires an answer that cuts across all of them at once: did this agent, acting for this person, execute this action within the limits of this task?
AI agency is, at its core, the ability an artificial intelligence system has to act autonomously to complete tasks on behalf of a person. This goes far beyond answering questions or generating text: the agent can access external systems, fill out forms, interact with APIs, run searches, and depending on the permissions granted, close deals and execute real transactions. What was science fiction five years ago is happening right now, in production, with real users, real money, and real consequences.
When a human makes a purchase, there is a clear chain of responsibility: the person chooses, confirms, pays, and receives. If something goes wrong, there is a defined path for disputing it. But when an AI agent carries out that same sequence, spreading decisions across multiple systems at the same time, the chain of responsibility fragments in a way that most companies and regulators still do not know how to reconnect.
A bill points directly at the problem
In the United States, a recent bill put its finger right on this wound. Senator Mark Warner of Virginia introduced in July 2026 the so-called AI AGENT Act (S. 5051). The text defines a custodial user agent as one authorized to act for a person in a transparent, documented, limited, and revocable manner, and it requires these agents to maintain real-time records of actions taken on behalf of users.
Receive the best innovation content in your email.
All the news, tips, trends, and resources you're looking for, delivered to your inbox.
By subscribing to the newsletter, you agree to receive communications from Método Viral. We are committed to always protecting and respecting your privacy.
The proposal also directs NIST — the National Institute of Standards and Technology — to identify protocols or develop technical standards for verifying that a user delegated authority to an agent, as well as maintaining auditable records of the actions that agent performs. Sounds like the perfect solution, right? But there is an important detail.
The bill does not expressly require a verifiable chain of evidence that spans the different systems involved, from the moment the user initiates the task to the final outcome. In the shirt scenario, that chain would need to link the user instruction to the agent, the agent actions, and the records kept by the store and the payment service. Without that complete link, each company keeps seeing only its own piece.
Authorization and transaction: where the system breaks
The concept of authorization within traditional digital systems is relatively straightforward: you click confirm, type a password, read a verification code. There is a clear moment when your intention becomes a recorded action. With autonomous AI agents, that moment vanishes. The authorization may have happened weeks earlier, as part of a broad permission granted to an application, or it may have been delegated to another agent within a chain of systems the user did not even know existed.
Many websites use OAuth, an industry-standard security protocol for delegating access authorization to online services without exposing passwords. It generates an access token that the application presents to enter a protected service. The problem is that this persistent authorization may have been approved well before the current task. The application can still present a valid token that allows it to complete a purchase today, even when the current instruction says only to search, not buy.
In other words: the store sees a usable token and completes the transaction. The specific restriction for that task — do not buy — stays trapped inside the agent provider and never reaches whoever processes the payment. A transaction executed by an agent travels through multiple independent systems: the language model that decided, the API that sent the command, the vendor system that received the order, the gateway that processed the amount. Each one has its own records, but they do not communicate with each other in a structured enough way to answer the most basic question: did the user actually authorize this, under these conditions, with this scope?
And this is not hypothetical. Security researchers have already demonstrated how AI agents can be manipulated through prompt injection attacks, where malicious content encountered during browsing alters the instructions the agent was following. In that scenario, the transaction happens, the record shows the agent acted within permissions, but the real authorization never existed — and proving that after the fact, without an auditable chain, is nearly impossible.
The evidence needs to travel with the action
For this kind of accountability to actually work, five things would need to be in place at the same time: a verifiable link between the user account, the agent at that specific moment, and the task; task-specific limits; a verifiable connection throughout the entire transaction; a check before each action; and records whose subsequent alteration can be detected. The good news is that payment systems have already started assembling these pieces.
The first record identifies the authenticated account that approved the task and the agent that received the authority. The store cannot rely solely on the agent provider name. The provider links the account, agent, and task in an authorization record and digitally signs it, allowing the store and payment service to verify who issued it and whether it was tampered with.
The provider also preserves the original request and converts it into limits that other systems can enforce. For the shirt task: search for 15 minutes, no purchase, no passing purchasing power to another agent. Before the agent starts, the user sees and approves this structured version. If the translation is wrong, you can compare the rule against the words that originated it.
The task reference that connects everything
One way to create this link is to have a task reference travel along with each request. It is unique to a single job, carries no name, account number, or any direct identifier, and appears in the records of all participating companies. Engineers already use something similar — the trace identifier — to correlate events from the same operation as it moves between services.
This reference links records scattered across systems to a single job, but it does not confer authority on its own. That is why it needs to be tied to the rule approved by the user inside the digitally signed record from the provider. Since even a random identifier can connect activities across services, ideally it should be short-lived and visible only to the companies participating in that specific task.
Checking the rule where the money moves
Someone then needs to validate the rule at exactly the point where the money flows. At checkout, the store validates the signed authorization record and evaluates the proposed purchase against it. A no-buy prohibition blocks the transaction even when the application has broader access to the account. A bank transfer or the release of medical records could trigger a fresh confirmation. And any authority passed on to another agent would have to carry the same task reference and stay within the original limit.
After the decision, the store system records the agent, the task reference, the rule evaluated, the timestamp, the decision, and the outcome. The payment service stores the same reference, and the provider keeps the instruction and approved rule. Each company maintains a tamper-evident record, so that later changes can be detected. And the user gets a plain-language receipt: your agent searched three stores and attempted to complete a purchase. The purchase was blocked because buying was not authorized.
What is already being built — and what is still missing
The Agent Payments Protocol, or AP2, from Google, already meets some of these requirements. It creates records capable of showing the limits approved by the user and the information presented to each participant when a transaction is disputed. AP2 shows how evidence could travel between systems. What it does not yet resolve is who bears the loss, how long each company must keep that evidence, and how to retrieve it afterward.
NIST, meanwhile, is reviewing comments on a concept document published in February 2026 about agent identity and permissions. It asks how an agent can prove its authority, connect that authority to a person, and produce verifiable records. But the initial effort proposed covers only agents operating within organizations, where there is more control and visibility. Agents from untrusted external sources were left out of this first phase, although the document says public or individual agents may be addressed later.
And that is exactly where the thorniest problem lives. Consumer agents that cross boundaries between companies represent precisely the case NIST postponed. Each company maintains its own identifiers, its own authorization language, and its own retention rules. A dispute can go unresolved even when every company presents its records exactly as they were stored.
From a regulatory standpoint in the U.S. and globally, the situation is equally complex. Frameworks like the EU AI Act, GDPR, and various proposed federal and state-level regulations in the United States establish important principles around accountability and transparency, but none of them were designed with autonomous agents in mind — agents that make chained decisions and execute transactions without direct human intervention at every step.
Why this matters way more than a $30 shirt
A dispute over a $30 shirt you can probably shrug off without major trauma. But the records can fail in exactly the same way when an agent moves $40,000, submits a benefit appeal, or requests a prescription renewal in your name. In those cases, it might be easy enough to prove the agent had access to the service. Proving whether or not you authorized that agent to do exactly what it did on your behalf is a completely different story.
The information asymmetry here is enormous: whoever builds the agent knows exactly what it can do, and whoever uses it often has no idea. This makes authorization an act that needs to be far more granular, reviewable, and traceable than the current single-consent model allows. Some initiatives are already heading in this direction, like Anthropic MCP protocol and W3C discussions on agent identity, but the ecosystem is still far from any real convergence.
The most realistic path in the short term is not to wait for a universal technical solution or comprehensive regulation. It is to combine market pressure — users and companies demanding transparency in agent actions — with voluntary adoption of best practices by developers, such as detailed action logs, well-defined permission scopes, and accessible rollback mechanisms. It is not the ideal solution, but it is what is within reach right now. And until that bigger answer arrives, understanding that this problem exists is already an important step — because you can only start fixing what you have first clearly seen. 👁️
