EAA Series · Field Note

S.5051 Frames a Governance Layer for Custodial Agents

A Senate bill about consumer platform interoperability would define statutory duties for an autonomous agent. Read closely, those provisions map across the same four delegation-and-accountability layers this series uses, approached from a different direction.

Read

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 would give consumers the right to authorize a “custodial user agent” to act for them on large online platforms, and it would require those platforms to open non-discriminatory interfaces for it. It is not an enterprise governance bill, and it is introduced legislation, not law. But the duties it would write for that agent, read section by section, map across the same four layers this series has spent four parts building — for a different problem, on a separate policy track. This article maps those provisions onto EAA; it does not claim the bill's drafters arrived at them independently of this work.

Published August 30, 2026 · Legislative status checked August 30, 2026 · Revised September 7, 2026 for provision accuracy and proposed-law language

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. As of the August 30, 2026 check against congress.gov and LegiScan described below, the official record listed zero cosponsors and no companion bill in the House, and no further congressional action had been recorded beyond that referral. That is a description of the record on the date checked, not an independently reverified current status, and an absent related-bill listing would not by itself prove no companion exists. 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.

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 Directs the FTC to establish rules and procedures ensuring that delegation is verifiable and that a mechanism exists for a user's revocation request to be promptly communicated. That is a rulemaking mandate aimed at the eventual basis for runtime access control, not a duty the introduced text imposes directly on the provider today — and even once implementing rules exist, the target is prompt communication of a revocation request, not that revocation itself takes effect immediately or that every invocation is checked. 3 · Control Plane — verifiable delegation, prompt revocation communication
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. This gives the platform a legal basis to deny or revoke access; it does not itself specify a per-invocation enforcement mechanism. 3 · Control Plane — legal basis for platform-side denial or revocation
3(g)(1)(F) — redelegation Transfer to another entity, agent, or AI system operated by another entity is conditioned on the user's express, specific, and revocable authorization, and any permitted delegate is bound by the same duties as the custodial user agent itself. That's narrower than an unrestricted statement about every agent-to-agent handoff — it targets the cross-entity transfer case specifically. Even within that scope, it's one of the few places any governance text this series has reviewed actually addresses redelegation, rather than leaving it as an open gap. 1 · Agent / Workforce — redelegation scoped to the original grant
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 proposed statutory duty. 4 · Governance — who answers
3(g)(2) — provider responsibility The provider must maintain reasonable measures to ensure compliance with these duties, and separately, a pattern of violations by any agent it operates is attributed to the provider for deregistration and enforcement. The duty runs to the provider both ways — prevent violations, and answer for the pattern that occurs — not to 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 turns on activity, not industry. S.5051 covers a consumer's agent acting on a consumer-facing large online platform — shopping, social media, messaging — and its provider definition is broad enough to reach a user operating their own agent, not only a commercial vendor. Coverage depends on whether that defined activity is occurring, not on whether an organization happens to run agents internally. 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 — which is the narrower and more defensible claim to make here. The value of the parallel is that this article maps the delegation-and-accountability provisions of a platform-access bill onto EAA's four layers. That similarity is visible in the text; it is not evidence that the bill's drafters arrived at these questions independently of this work, nor is it 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.

Real gaps remain, on an outside reading. 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.” That provision calls for future harm-prevention proposals; it does not itself declare that the introduced text leaves loss allocation unresolved. Davis Wright Tremaine's analysis of an earlier draft raises that concern directly — that the bill does not yet allocate loss when an agent acts unpredictably or exceeds its authorization — and separately flags a gap this analysis agrees the introduced text still does not close: distinguishing a platform's legitimate persuasion of an agent from impermissible manipulation of it. The closest the introduced text 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 introduced text.

A recorded stage, not a prediction. The status described above is what was on record as of the date this was checked; it is not a claim about what happens next. DWT's own framing of the earlier draft — that it “is likely to evolve substantially” — is a reasonable level of confidence to extend to the introduced text too, but that is a judgment about likely legislative drift, not a fact about the bill's current status. Treat the substance of this note 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, 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. 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. This note maps the bill's delegation-and-accountability provisions onto EAA's four layers — a demonstration of textual similarity, not compliance, endorsement, coverage, or a claim that the drafters arrived at these questions independently of this work.

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 citable on Zenodo under CC BY 4.0. Cite the concept DOI — it always resolves to the latest version.

DOI: 10.5281/zenodo.21105314

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