S.5051 Frames a Governance Layer for Custodial Agents
A Senate bill about consumer platform interoperability defines statutory duties for an autonomous agent. Read closely, those provisions map across the same four delegation-and-accountability layers, arrived at from a different direction.
On July 21, 2026, Senator Mark Warner introduced S.5051, the AI AGENT Act, in the U.S. Senate. It is a competition bill: it gives consumers the right to authorize a “custodial user agent” to act for them on large online platforms, and it requires those platforms to open non-discriminatory interfaces for it. It is not an enterprise governance bill, and it is not close to law. But the duties it writes for that agent, read section by section, map across the same four layers this series has spent four parts building — developed independently, for a different problem, on a separate policy track.
Published August 30, 2026 · Legislative status checked August 30, 2026
What the bill actually does
S.5051 is titled the Artificial Intelligence Access, Gatekeeper Exchange, and Nondiscriminatory Transfer Act of 2026, or the AI AGENT Act. It was read twice and referred to the Senate Committee on Commerce, Science, and Transportation the same day. The official record lists zero cosponsors and there is no companion bill in the House. That is the entire status: introduced and referred. No further congressional action has occurred. If enacted, FTC regulations would be due within one year and NIST technical standards within 180 days. The Act would take effect on the earlier of the FTC's promulgation of implementing regulations or one year after enactment.
The mechanism: a large online platform (more than 50 million U.S. customers or subscribers in a month — the Amazons, Googles, and Metas of the world) must let a user delegate a custodial user agent to manage their “online interactions, electronic commerce decisions, user-generated content, and account settings…on the same terms as a user.” The agent's provider registers with the FTC. The platform must offer a fair, reasonable, and non-discriminatory interface for it. And Section 3(g) writes six duties the agent itself must observe. That subsection is the payload of this note.
- The bill text: S.5051 — AI AGENT Act of 2026, congress.gov official record (sponsor, committee referral, action history), and the introduced-bill PDF on govinfo.gov, the authoritative text this note's section citations are drawn from.
- Introduced-text mirror: LegiScan bill text and status tracker.
- Legal analysis: Davis Wright Tremaine, “The Federal AI AGENT Act: Consumer Protection in AI Clothing?”, and DLA Piper, “Senator Warner Discussion Draft on Securing AI Agents: Top Points” — both discuss an earlier discussion-draft version of this bill, ahead of the July 21 formal introduction.
S.5051, read against the four layers
The bill was not written with an enterprise-architecture vocabulary. This is an interpretive mapping, not a claim of a complete, one-to-one correspondence — but its core delegation, access, control, and accountability provisions span all four layers, and several of them land with almost no translation required.
| S.5051 provision | What it requires | EAA layer |
|---|---|---|
| 3(d)(1) — registration | The provider is registered with the FTC before its agents may access the interface. Registration identifies the accountable provider, not each individual agent instance. | 1 · Agent / Workforce — provider-level identification 4 · Governance — registered accountability |
| 3(j) — extent of access | “Nothing in this section shall be construed to confer greater rights of access for a custodial user agent…than are accessible to a user.” The agent's reach is capped at what the human it represents could already reach — not what the platform's API happens to expose. | 2 · Capability / Tool — what it may touch |
| 3(c) — authentication and revocation | Delegation must be verifiable, and revocation must become effective promptly. That creates the basis for runtime access control rather than treating delegation as an irrevocable onboarding event — it does not, on its own, establish that every invocation is checked. | 3 · Control Plane — verifiable delegation and revocation |
| 3(f) — platform-side revocation | A platform may deny or revoke access for an unregistered provider, repeated fraud or malicious activity, or a user's revoked consent — a runtime deny path independent of the agent's own claims about itself. | 3 · Control Plane — enforced at decision time |
| 3(g)(1)(E) — records | “Maintain real-time records of actions taken on the user's behalf and make such records available to the user upon request.” An audit trail is not optional instrumentation; it is a named statutory duty. | 4 · Governance — who answers |
| 3(g)(2) — provider responsibility | A pattern of violations by any agent a provider operates is attributed to the provider, for deregistration and enforcement. The registered provider operating the agent answers for the pattern of violations — not the agent itself. | 4 · Governance — who answers |
| 3(g)(3) — non-waiver | These duties “may not be waived, limited, or modified by contract, by terms of service, or by any form of user consent.” The obligation is constitutional to the arrangement, not a term a clever contract can route around. | 4 · Governance — who answers |
One duty is worth reading twice because it does something this series has not seen a statute do before: Section 3(g)(1)(D) holds the agent to “the care, skill, and diligence that an ordinarily prudent person would reasonably be expected to exercise in a like position.” That is a fiduciary-adjacent, common-law negligence standard, applied to a piece of software acting for a consumer. It is an external standard of conduct, not merely a policy the agent is asked to quote. But it is not runtime enforcement by itself. A legal duty establishes conduct and accountability after the fact; it does not, on its own, intercept or block an action at decision time. That requires translating the duty into controls that can constrain an action before execution and preserve evidence afterward — which is what Part 3 of this series calls the Control Plane, and what the records duty in 3(g)(1)(E), above, starts to require.
A tension worth flagging on its own terms. Section 3(g)(1)(E)'s records duty carries an exception: “with the exception of any records that a user has previously directed a custodial user agent to delete.” A deleted record cannot be treated as evidence that no action occurred. Any future standard or profile built on this duty would need to state whether the deletion itself, its authorization, and the identity of the prior record remain auditable — otherwise the audit trail the bill requires can be made to disappear by the same consent that authorized the underlying action.
Where the analogy holds, and where it doesn't
This is a field note, not a claim that a Senate bill validates an architecture. Three things keep the parallel honest rather than convenient.
Scope is different on purpose. S.5051 governs a consumer's agent acting on a consumer-facing platform — shopping, social media, messaging. It has nothing to do with an enterprise deploying its own agent workforce internally, which is the problem this series and the reference implementation behind it actually address. Operating constitutional-agent or HRAO-E for an internal enterprise workforce would not, by itself, make an organization a custodial-user-agent provider under this bill. The value of the parallel is that two groups working the delegation-and-accountability problem from opposite ends — a legislature regulating platform access, and an enterprise-architecture practice governing internal agent workforces — arrived at similar questions independently. This is an independent policy framing of similar delegation-and-accountability questions, not empirical evidence that the EAA model is correct, adopted, or complete, and it is not evidence the practice complies with, or is covered by, this bill.
The bill leaves real gaps open, and it says so. Section 4(g) tasks a nine-agency interagency working group with “developing proposals to prevent harms to businesses and the Government resulting from custodial user agents undertaking actions…as a result of fraud, misuse, or genuine mistake” — which is the bill's own acknowledgment that the introduced text does not yet allocate loss when an agent acts unpredictably or exceeds its authorization. Davis Wright Tremaine's analysis of an earlier draft flagged this directly, and flagged a second gap the introduced text still does not close: distinguishing a platform's legitimate persuasion of an agent from impermissible manipulation of it. The closest the bill comes is Section 3(g)(1)(B)(iii) — the agent must not act inconsistently with “the reasonable expectations of the user” — which is a standard for judging the agent's own conduct, not a control against a platform or third party trying to steer it. Prompt injection and comparable manipulation of an agent's judgment are not named anywhere in the bill.
It is not close to being law. One sponsor, committee referral, no vote scheduled. DWT's own framing of the earlier draft — that it “is likely to evolve substantially” — is the correct level of confidence to hold about the introduced text too. Treat this as a data point in how the delegation-and-accountability problem is being framed by people with no stake in this series, not as a regulatory deadline.
The part that outlasts the bill's odds
Bills stall. The vocabulary a bill popularizes on its way to stalling does not always stall with it. Two structural choices in Section 3(g) are worth carrying forward regardless of what happens to S.5051 specifically.
First, the non-waiver clause. Section 3(g)(3) puts the duties outside what a contract, terms of service, or user click-through can modify. That is the same move this series has made about hard constraints from Part 0 onward: some obligations are constitutional to the system, not configuration a deployer can turn off under commercial pressure. Seeing a legislature reach for that same structure, independently, for a different actor, is a useful data point that “non-negotiable by design” is not a stylistic preference of this practice — it is one established way to keep core duties from becoming commercially negotiable.
Second, Section 4(c)(6) tasks NIST with identifying or developing open protocols for “verifiable delegation” — scope-limited revocable credentials, real-time revocation, and auditable records of an agent's actions. That is a standards-track description of exactly the evidence discipline this series has tried to hold itself to on every page: a claim is not established because an agent asserts it, it is established because a record survives review. It sits adjacent to NIST's ongoing agent-identity work and to CTE's three public-comment submissions concerning NIST AI 800-2, whose receipt CAISI acknowledged. If an enactment-triggered NIST process opens, its published scope would be relevant to the research questions tracked here. Nothing to act on today — the process would not exist unless and until the bill is enacted — but worth having on the map now, while it is still one sentence in a bill that has not been marked up yet.
About This Series
Michael K. Saleme — Enterprise Agent Architect
A field note reading S.5051's custodial-user-agent duties against the four-layer Enterprise Agent Architecture model developed across Parts 1–4 of this series. The bill is consumer-platform interoperability policy, not enterprise governance, and it is early-stage legislation, not settled law. What it demonstrates is convergence on the same delegation-and-accountability questions from an independent direction — not compliance, endorsement, or coverage.
This page is the canonical version of this analysis.
The same delegation-and-accountability questions apply to an internal agent estate. Explore the Governance Stress Test framework.
Cite the Position Paper
This field note develops the Governance layer of the Enterprise Agent Architecture position paper, which is published and peer-citable on Zenodo under CC BY 4.0. Cite the concept DOI — it always resolves to the latest version.
Saleme, M. K. (2026). Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise. Zenodo. https://doi.org/10.5281/zenodo.21105314
BibTeX
@misc{saleme2026eaa,
author = {Saleme, Michael K.},
title = {Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise},
year = {2026},
publisher = {Zenodo},
doi = {10.5281/zenodo.21105314},
url = {https://doi.org/10.5281/zenodo.21105314}
}
Michael K. Saleme
Enterprise Agent Architect · Cognitive Thought Engine