Your AI agent closed the ticket and pushed the refund through. Your help desk software logged that it happened. Two policy moves this year ask a harder question: who allowed that, inside what limits, and can you produce the record without anyone being able to edit it afterwards? Most ticket systems cannot answer that today.
The disclosure fight is over and it turned out to be cheap. Since 2 August 2026, Article 50 of the EU AI Act has required interactive systems to tell people they are dealing with a machine, and most teams handled it with a line of text above the chat window. We wrote about that when it landed, in what Article 50 means for live support software. Authorization is a different animal, because it touches your data model rather than your interface copy.
Disclosure was about words. Authorization is about your ticket schema
On 21 July 2026, Senator Mark Warner introduced the AI AGENT Act (S.5051), which was read twice and referred to the Committee on Commerce, Science, and Transportation. The bill defines a “custodial user agent” as one authorized to act for a user in a way that is transparent, documented, limited and revocable. It would require those agents to keep real-time records of the actions they take, and it directs NIST to identify or develop technical standards for verifying that a user actually delegated authority to an agent, plus keeping auditable records of what the agent did with it.
Read that list again with a support queue in mind. Transparent, documented, limited, revocable. A typical ticket audit trail gives you documented, sort of. The other three are usually nowhere in the schema.
NIST is not starting from scratch here either. Its National Cybersecurity Center of Excellence published a concept paper in February 2026 on software and AI agent identity and authorization, and the framing in it is the useful part: identity and authorization are separate layers. Authentication says which agent this is. Authorization says what it was permitted to do, when, and on whose behalf. The direction of travel is least privilege, just-in-time access, task-scoped permissions and action-level approval for anything expensive.
The left side proves an action happened. The right side proves it was allowed to happen, which is the question a dispute actually asks.
There was a neat illustration of the gap on 24 August, when Fortune looked at Google’s agent payments protocol and pointed out that it can trace exactly how an agent spent your money, and still leaves you stuck when the agent buys something you never approved. Tracking and authorizing are not the same capability. Support tooling has the same blind spot, just with refunds, account changes, plan downgrades and data deletions instead of shopping carts.
What an authorization record looks like on a ticket
Strip out the legal language and you get five things worth storing next to every action an AI agent takes in your help desk software.
| Field | What it answers | Where it comes from |
|---|---|---|
| Delegation reference | Which named human or policy granted this authority | Admin action when the agent was configured or a per-case grant |
| Scope snapshot | Queues, action types, monetary ceiling, expiry, all as they stood at that moment | Copied into the log at action time, never a pointer to a live record |
| Action detail | What changed, on which ticket, with which inputs | Your existing audit trail, usually the only part you already have |
| Human checkpoint | Approved, overridden, or auto-approved because it sat inside scope | The approval step, including the case where nobody was asked |
| Revocation event | When the authority ended and who ended it | Agent configuration history |
The scope snapshot is the row most teams get wrong, and I would argue it is the one that matters most. If your log points at a permission profile that someone edits three weeks later, the log now describes a rule that did not exist when the action ran. Copy the limits into the record. Storage is cheap and arguments are not.
Why your chat transcript will not save you
A support lead I spoke to recently made the reasonable objection: we keep every transcript, so we can always show what happened. That works right up until someone asks a question the transcript cannot answer.
A customer disputes a $180 refund six weeks after the fact. The transcript shows a polite conversation and an AI agent confirming the refund. It does not show whether refunds of that size were inside the agent’s authority that week, whether a human was meant to approve anything above $150, or whether the billing queue had been added to the agent’s scope two days earlier by someone who has since left. Reconstructing that from memory is exactly the position the record-keeping proposals are designed to prevent.
There is a second problem with treating model output as evidence. The agent’s own reasoning trace is a description of intent, not proof of permission, and it was produced by the thing whose behaviour is in question. Keep it for debugging. Do not file it as the authorization record.
The rules arriving next cost a schema change rather than a banner, which is why they are worth starting on early.
How to add this without rebuilding your help desk
You do not need a compliance project for this. You need an append-only table and some discipline about what goes in it.
Start with the actions that move money or change account state. Refunds, plan changes, cancellations, credential resets, data deletion. Those are where a dispute becomes expensive, and they are usually a short list. Everything else, the tagging and routing and canned replies, can stay in your normal audit log for now.
Make the log append-only and hash each entry with the previous one. A simple chain gets you tamper evidence without a database migration or a blockchain sales pitch. If someone edits a row later, the chain breaks and you can see where.
Record the human checkpoint even when there was not one. An entry that says “auto-approved, inside scope, no human asked” is a real answer. A missing field is not, and six weeks later nobody will remember which it was.
Then set the scope narrower than feels comfortable. Most support teams start by giving an AI agent access to everything and pulling permissions back after the first surprise. Reverse it. Start with one queue and one action type, watch what it does for a fortnight, then widen. That approach also gives you a clean revocation trail, which is the fourth thing on the regulators’ list and the one nobody thinks to build.
Where this lands for smaller support teams
None of this is binding on a ten-person support desk today. S.5051 is a bill in committee, not law, and it may look different if it moves. The EU obligation that is already in force is the disclosure one, which you have probably handled.
Even so, I would not wait for the mandate. The moment an AI agent can act rather than suggest, the delegation question shows up on its own, usually through a chargeback or an angry customer rather than a regulator. Teams that added an honest handoff record between AI and human agents found the same thing: the log you build for compliance turns out to be the log you needed for your own arguments. If you are still mapping out how automation sits inside your workflow, our primer on what a ticketing system actually does is a decent place to start.
Frequently asked questions
Is the AI AGENT Act law?
No. S.5051 was introduced on 21 July 2026 and referred to the Senate Commerce Committee. It is a proposal, and bill text often changes in committee. Treat it as a signal about where record-keeping expectations are heading, not as a compliance deadline.
Does the EU AI Act already require agent authorization records?
Not in the form described here. What became applicable on 2 August 2026 is the Article 50 transparency duty, which is about telling people they are interacting with AI. High-risk system obligations were pushed back to December 2027 for most deployers under the omnibus agreement.
What is the smallest useful version of this?
One append-only table covering money-moving actions, with five columns: delegation reference, scope snapshot, action detail, human checkpoint, timestamp. A capable developer can add that in a day. Everything else is refinement.
Do we need this if our AI only drafts replies?
Probably not yet. Suggestion tools keep a human in the loop by design, and the human who clicks send is the authorization record. The question arrives the day you let the agent send, refund or close without that click.
Can we rely on our vendor to handle it?
Ask them directly what their agent action log stores, whether it is append-only, and whether permission scopes are snapshotted at action time or read live. The answers vary a lot right now, and the third question is the one that separates a real audit trail from an activity feed.
Related resources
- EU AI Act Article 50 and what it changed for live support software
- Agentic AI in the help desk: triage, routing and human handoff
- The AI handoff gap in ticketing
- What is help desk software
- What is a ticketing system
Getting this right in your own stack
ICTDesk pairs live AI agent chat with a ticket system, so the conversation and the record it produces stay in one place instead of two tools that have to agree with each other later. If you are working out what to log when your AI starts acting on tickets, take a look at ICTDesk live support software, or read how to add live chat to your website for the setup side. Questions about your own setup are best raised through a support ticket.