A bill now sitting with the Senate Commerce Committee would require an agent acting for a person to keep real-time records of what it did, act only inside the authority it was granted, and never hand that authority to another agent without explicit permission. Your stack can satisfy none of those three from what it currently writes down, because a trace records behaviour and every one of those duties is about permission — and the reason the bill hands NIST the job of finding a protocol for it is that no protocol in the standard agent stack carries one.
What S. 5051 actually says
The AI AGENT Act of 2026 — the acronym unpacks to Artificial Intelligence Access, Gatekeeper Exchange, and Nondiscriminatory Transfer — was introduced by Senator Mark Warner on 21 July 2026, following a discussion draft circulated at the end of June. It was read twice and referred to the Committee on Commerce, Science, and Transportation, which is where it remains. That is the ordinary fate of most bills, and it is worth saying plainly at the top: this is early-stage legislation with no committee action, and the smart money on any given bill is that it never gets a floor vote.
Read it as a specification rather than as a prediction and it becomes considerably more interesting, because the drafting is unusually specific about mechanism.
The bill's central object is the custodial user agent: an agent authorised to act for a user in a manner that is transparent, documented, limited and revocable. Those four adjectives are not decoration. Each one names a property that has to be represented somewhere in a system for anyone to check it, and taken together they describe a data structure, not a disposition.
Around that definition sit affirmative duties. A custodial user agent must safeguard the user's data, follow the user's instructions and reasonable expectations, avoid self-dealing and foreseeable harm, maintain real-time auditable records of the actions it takes on the user's behalf, refrain from acting beyond what the user authorised, and refrain from delegating its authority to another agent without the user's explicit permission.
Two agencies get jobs. The FTC is the principal enforcer and develops the security and identity standards an agent provider must meet. NIST is asked to identify existing open protocols — or, failing that, to develop and publish standards — for scope-limited, verifiable, real-time consent delegation and revocation, and for auditable verification of a custodial agent's identity, registration status, and the actions it took. That second mandate is the tell. Congress does not normally ask a standards body to go find a protocol when the protocol exists.
And there is a market-structure half that has attracted most of the coverage: platforms above a large user threshold — 50 million monthly users, as reported — would have to let a user bring at least one qualifying third-party agent onto the platform, rather than confining them to the platform's own.
| Provision | What it demands | Where it lands in a stack |
|---|---|---|
| Custodial user agent definition | Transparent, documented, limited, revocable | A grant object with a scope and an expiry |
| Real-time action records | Auditable, and available to the user | A user-facing surface, not a log pipeline |
| No action beyond authorisation | Enforcement, not intent | Below the model, at credential issuance |
| No onward delegation without permission | Per-hop evidence | Sub-agents, A2A peers, tool calls |
| NIST protocol mandate | Delegation, revocation, verification | The layer that does not exist yet |
Activity logs and authority records are different artefacts
Ask an engineering team whether they can produce a record of what their agent did and they will say yes, and they will be right about the thing they are thinking of. Traces, spans, tool-call arguments, model versions, token counts, latencies — modern agent observability is genuinely good, and the OpenTelemetry GenAI conventions have made it portable.
Now ask the questions the duties actually generate. Who granted this agent the ability to move money out of this account? What scope did they grant, in what words, and when? Was it still valid at the moment of the action? Did the thing that performed the action hold that grant, or did it inherit it from something that did? Can the user see the answer today, without a support ticket?
A trace answers none of these. It records that transfer_funds was called with those arguments at that timestamp by that service — which is a statement about behaviour. The bill's duties are statements about permission, and permission has its own fields: grantor, scope, purpose, expiry, revocation state, and the actor chain that arrived at the action. Our page on delegated access and consent records makes the same argument from the consent side, and the observation generalises: an audit trail built to answer "what happened" cannot be post-processed into one that answers "was that allowed". The join field is missing.
The engineering fix is small and boring, which is the best kind. Mint a grant object when a user authorises an agent to do something — grantor, scope, stated purpose, expiry — give it an id, and stamp that id on every action taken under it. Log the scope actually exercised next to the scope granted. That single field turns your existing trace into the second ledger, and it is a week of work, not a platform migration. What it is not is free later: retrofitting a grant id onto eighteen months of history is not possible, and the first time anyone asks these questions it will be about last quarter.
The sub-delegation clause is aimed at your architecture
Of all the duties, "shall not delegate authority to another agent without the user's explicit permission" is the one that collides with how agents are actually built in 2026. Sub-agents are not an exotic pattern; they are the default answer to context pressure, and the whole sub-agent patterns literature exists because everyone is doing it.
Trace the authority along a realistic chain. The user authorises the orchestrator through an OAuth flow — a real grant, with a scope, an expiry and a revocation endpoint. The orchestrator spawns a sub-agent, which is a function call: the sub-agent inherits everything and nothing is asserted, because there is no wire to assert on. The sub-agent hands work to a partner's agent over A2A, which carries an agent card and a task and no delegation field. That partner calls a tool over MCP with a bearer token scoped to its service. Four hops, one of which produced a record.
The protocols are not going to close this for you soon. A2A moved into the Agentic AI Foundation alongside MCP on 20 August, which we read at the time as consolidation without a delegation primitive — the governance merged, the missing layer did not appear. MCP's authorization work standardises how a server gets a token, not who is behind it; the deeper treatment is in MCP auth and OAuth 2.1.
What does exist, and is oddly unused for this, is OAuth 2.0 Token Exchange (RFC 8693). It has an actor claim precisely so a token can say "this service is acting on behalf of that principal", and it can nest, so a chain is representable. It is not a complete answer — it says nothing about purpose or about what the user was shown — but a team that wants delegation evidence today can have it without waiting for NIST.
The harder question is what "explicit permission" could reasonably mean, because the literal reading is unshippable. Nobody is going to approve a modal per sub-agent; an agent that asks four times per task is an agent nobody uses, and consent fatigue converts approval into a reflex, which is worse than no approval at all. The workable reading is that the permission attaches to the shape of the delegation rather than to each instance: the user grants a purpose-scoped authority that names what may be sub-delegated and to whom — internal sub-agents yes, third-party agents no, or this named partner only — and every hop records that it acted under that grant. That is a design most teams could implement, and it is also the only reading under which the record is worth reading.
The access mandate points the opposite way from the edge
Set the duties beside the interoperability half and a tension appears that neither half acknowledges.
The bill would compel the largest platforms to accept an agent the user brought with them. Meanwhile the actual web is moving the other way: Cloudflare blocks AI crawlers by default on new domains, and the enforcement that matters happens at the edge rather than in a robots file — the state of play is in bot verification and agent web access. One regime says let qualified agents in. The other says keep unidentified agents out. A third-party agent in 2027 could plausibly have a statutory right to reach a platform and no technical means of proving it should be let through the CDN in front of it.
They are less contradictory than they look, though, and the reconciliation is the useful part: both regimes converge on the same missing primitive. The edge wants a verifiable statement of who this agent is. The bill wants a verifiable statement of what this agent was authorised to do, by whom. Signature-based bot authentication supplies the first. The NIST mandate is about the second. An agent that can present both gets through the CDN and satisfies the record-keeping duty with the same credential; an agent that can present neither is a scraper with good intentions.
The payments world got to this conclusion first and has the sharpest version of it. AP2 represents a purchase as signed mandates binding a user's intent, the agent's cart and the payment — the mechanics are in AP2 and agent commerce. What that machinery proves is that a specific agent made a specific purchase under a specific mandate. What it cannot prove on its own is that the human meant to authorise this purchase, as opposed to having signed a broad intent months earlier that the agent later stretched. The gap between "the agent's action is attributable" and "the user authorised it" is exactly the gap the bill's record-keeping duties are written to close, and it is not closed by any amount of cryptography over the wrong object.
What to build, regardless of the bill
Mint a grant, not a session. When a user authorises an agent to act, create an object with a grantor, a scope, a stated purpose in the user's own words, an expiry and a revocation path. "Connected" is not a grant. A grant that never expires is a credential, and it is the one that shows up in the incident.
Stamp the grant id on every action, and log exercised scope beside granted scope. One field. It is what makes an existing trace answerable and what makes over-broad grants visible — the ones where you granted twelve scopes and the agent has used two for a year.
Make sub-delegation an operation, not an implementation detail. A sub-agent should receive a derived, narrower authority with its own record, not a copy of its parent's. Whether you express that with RFC 8693, with a signed internal assertion, or with per-hop credentials from a broker matters less than that a hop is a thing your system can enumerate afterwards. Sub-delegation you cannot enumerate is sub-delegation you cannot bound, which is the same argument as scoped credentials one level up the stack.
Treat the user-facing action record as a product surface. "Real-time records accessible to the user" is not a log export. It is a screen: what the agent did, under which authority, what it changed, and a button that revokes. Teams that build this find it does double duty as the trust affordance their product needed anyway, which is the argument in decision receipts and audit.
Rehearse revocation. Revocable is one of the four adjectives in the definition, and it is the one nobody tests. Pull a grant and find out what actually stops: the running task, the queued job, the cached credential in a sub-agent, the derived memory. Most stacks discover that revocation stops the next authorisation and nothing already in flight.
None of this is contingent on Congress. Every one of these five is already required somewhere — by the EU AI Act's transparency and human-oversight expectations, by ordinary SOC 2 access review, by the first enterprise customer who asks what your agent is allowed to do on their tenant, or by your own incident review after an agent does something nobody can account for. The bill is a well-drafted statement of a requirement that arrived before it did. Build for it and the legislative outcome stops mattering.
FAQ
Is the AI AGENT Act law?
No. S. 5051 was introduced on 21 July 2026 and referred to the Senate Committee on Commerce, Science, and Transportation. It has had no committee action, and most bills introduced in any Congress never receive a vote. Treat it as a well-specified statement of where consumer-protection thinking on agents has landed, not as a compliance deadline.
What is a "custodial user agent"?
The bill's term for an agent authorised to act on a person's behalf in a transparent, documented, limited and revocable manner. The four adjectives are the substance: an agent that cannot show its scope, cannot show its authority, has no bound on what it may do, or cannot be switched off does not meet the definition, regardless of how it is marketed.
Does this ban sub-agents?
Not as written. It bars delegating the user's authority to another agent without explicit permission, which is a requirement to represent and record delegation rather than a prohibition on multi-agent architecture. The practical reading is that permission attaches to the delegation's shape — what may be handed off and to whom — declared up front, rather than to each individual hop at run time.
Can I satisfy this with OpenTelemetry traces?
No, though you should keep them. Traces answer what happened; the duties ask what was permitted, and permission needs its own record: grantor, scope, purpose, expiry, revocation state and actor chain. The cheapest bridge is a grant identifier stamped on every action, which turns the trace you already emit into evidence about authority.
Does the interoperability provision mean I can point my agent at any large platform?
Only if the bill passes in something like its current form, and only for agents meeting FTC-developed security and identity standards that do not yet exist. In the meantime access is governed by each platform's terms and by edge enforcement, which has been getting stricter rather than looser.
Further reading
On this wiki:
- Delegated access & consent records — the record to keep, field by field.
- Decision receipts & audit — making an action explainable after the fact.
- Agent identity & permissions — the layer all of this rests on.
- The regulatory landscape — where this sits among the rules that already bind you.