The Proposed AI AGENT Act: Designing Access for User-Authorized Agents

A Competition Bill with Implications for Agent Access

On July 21, 2026, a bill designated S.5051 was introduced in the U.S. Senate. Its short title is the AI AGENT Act of 2026; its full name is the Artificial Intelligence Access, Gatekeeper Exchange, and Nondiscriminatory Transfer Act of 2026. The bill’s official title is “A bill to promote competition and reduce consumer switching costs in the provision of online services, and for other purposes” — it is not drafted as a regime governing AI agents in general. As background, Senator Warner’s office had released a discussion draft on June 29, 2026.

On the congressional record, the bill was read twice and referred to the Committee on Commerce, Science, and Transportation; in the records published as of August 2026, we could not confirm any hearing or vote beyond that referral. The text sets an effective date should the bill be enacted: the earlier of the date the Federal Trade Commission (FTC) promulgates regulations, or one year after enactment. No obligation is in force today, and the text is not settled.

We think the bill is worth reading anyway, because of its subject: not the AI agents a company runs itself, but the ones that arrive from outside on a customer’s behalf. Agent permission design is usually framed as a question about your own operational agents — what to delegate, and how far. This bill writes down the reverse in procedural detail: the decisions made by the receiving party.

Whose agent is this, and on what basis do you recognize it as such? How much of your system may it operate? When you refuse, what do you tell the other side? And how do you stop it?

What follows re-reads the bill in the order those questions arise on the receiving side, then sets out separately, as MIF’s own view, what would remain with individual companies outside the bill’s scope.

Who Would Bear the Duties: Platforms and CUA Providers

Start with the bill’s central concept, the “custodial user agent” (CUA). The text defines a CUA as a software-based agent that is expressly authorized by a user to interact with a large online platform provider on that user’s behalf in a transparent, documented, scope-limited, and revocable manner. No particular AI method or implementation technology forms part of the definition.

The bill would create two kinds of duty-bearer, with different scopes. One is the “large online platform provider.” A large online platform is a product, application, or service provided by an online platform with more than 50,000,000 customers or subscribers in the United States in any calendar month during the preceding 12-month period; the online provider that provides, manages, or controls it is the large online platform provider. The text says “more than 50,000,000,” not “50,000,000 or more” — and what that size threshold limits is the platform side’s duty to make an interface available, not the scope of the bill as a whole.

The other is the “custodial user agent provider,” meaning any entity that operates or offers one or more CUAs, including a user who operates a CUA on their own behalf. There is no size requirement on this side; both registration duties and conduct duties would apply.

The “online provider” the text names is a consumer-facing communications, retail, or information services provider, with social media, electronic commerce, personal finance, and artificial intelligence services given as examples. Whether an operational agent driving the admin console of a business-to-business SaaS product falls within that definition is not something the text answers directly.

What the Bill Would Require Before Access Is Granted

Seen from the receiving side, the provisions before access is granted fall into four groups. The grouping is ours, for readability; the text does not divide them that way.

The first is provider registration. A CUA provider would have to register with the FTC as a condition of, and prior to, any CUA it operates or offers accessing an interface. The FTC could set uniform terms and scope of service allowing registration through self-attestation, and within 180 days of a registration being submitted, the FTC or a recognized certification body would evaluate it. The FTC could also recognize independent certification bodies, and a certification in good standing would be treated as a rebuttable presumption of compliance with the CUA duties below.

The second is verifying that a request genuinely originates with the user. Within 180 days of enactment, the FTC would establish rules and procedures ensuring that a request for access on behalf of a user is a verifiable request.

The third is delegation and revocation by the user. The same provision would require that a user have a transparent, easily implementable method to revoke a prior delegation, including a mechanism to promptly communicate revocation requests to the platform provider.

The fourth is the scope of what may be requested. The FTC could establish specialized terms of service, including the authorized scope of delegated access, appropriate for CUAs in specific commercial settings, given the privacy, financial-security, and personal-safety implications of that access.

The text also provides that nothing in the section is to be construed to confer greater rights of access for a CUA to a large online platform than are accessible to a user. That an agent does not become more powerful than the person it acts for is obvious, but stating it expressly makes it a usable starting point for receiving-side design.

The bill also says who would build the technical foundation. Within 180 days of enactment, the Director of the National Institute of Standards and Technology (NIST) would identify open protocols or, where none exist, develop and publish model technical standards. The classes named are online messaging, multimedia sharing and social media services, electronic commerce, personal finance, and artificial intelligence, together with verifiable delegation — that is, open protocols and standards for scope-limited and revocable delegation credentials, verification of CUA identity and registration status, real-time communication and effectuation of revocation, and the creation of auditable records of actions taken by CUAs on behalf of users.

Regulations implementing the Act would be promulgated within one year of enactment by the FTC, in coordination with the Consumer Financial Protection Bureau, the Federal Deposit Insurance Corporation, and the Office of the Comptroller of the Currency. A further provision would have the FTC establish, within 180 days of enactment, an interagency working group that adds the Treasury, Homeland Security, Commerce, the Attorney General, and the Securities and Exchange Commission to those agencies, to develop proposals for preventing harms to businesses and the Government when CUAs take actions on a principal’s behalf through fraud, misuse, or genuine mistake.

None of that exists as of August 2026: the FTC registration regime, the recognition of certification bodies, and the NIST technical standards are all things the text provides for should the bill be enacted.

Limits Platforms Could Impose After Granting Access

After access is granted, the text is equally specific. A large online platform provider would have to facilitate and maintain an interface accessible to CUAs based on fair, reasonable, and nondiscriminatory terms.

That is not a call for unconditional, unlimited opening. A platform provider could establish reasonable thresholds related to the frequency, nature, and volume of requests by a CUA, beyond which it could assess a reasonable fee. It could likewise establish usage expectations, so long as they are fair, reasonable, and nondiscriminatory, including fees or usage limitations for providers that exceed them. Any fee or usage limitation would have to be reasonably proportionate to the cost, complexity, and risk of providing access, and a CUA provider could petition the FTC to review whether it is. Fees and usage terms would be publicly disclosed, with reasonable advance notice of any changes.

On security, the bill provides that a provider would, consistent with industry best practices, set privacy and security standards to the extent reasonably necessary to address a threat to the platform or to user data. Those standards would be filed with the FTC, which would make them publicly available, and suspected violations would also be reported to the FTC.

Interface changes would be constrained as well. A change to an interface or terms of use made with the purpose, or substantial effect, of unreasonably denying or undermining access by authorized CUAs would be treated as a violation of the duty to maintain access on fair, reasonable, and nondiscriminatory terms. The significance, as we read it, is that the wording covers not only purpose but substantial effect: the issue can be raised from the result, without proving intent.

The functional-equivalence provision is not a general duty falling uniformly on every large platform; it is conditional. A provider that maintains interoperability between its own large online platform and its other products, services, or affiliated offerings that constitute a custodial user service would have to offer a functionally equivalent version of that interface to competing CUAs. Within 120 days of enactment it would also disclose to competing CUA providers complete and accurate documentation describing access to the interoperability interface — source code would not be required — and give reasonable advance notice of interface changes.

Read from the receiving side, none of this is a binary between opening and closing the door. It describes a design you would operate with several dials — frequency, volume, cost, and security standards — once the door is open.

CUAs Have Duties Too: Non-Waivable Conduct Rules

Receiving-side design also has to account for the duties the bill would place on the CUA itself. A CUA would have to reasonably safeguard the privacy and security of user data provided to it by a user, or accessed on a user’s behalf. It would be prohibited from accessing or managing a user’s online interactions, electronic commerce decisions, financial accounts, content, or account settings in any way that will benefit the agent to the detriment of the user, will result in any reasonably foreseeable harm to the user, or is inconsistent with the directions or reasonable expectations of the user.

On data, it would be prohibited from collecting, using, or sharing user data beyond what is reasonably necessary to provide the services the user has delegated, and from using, sharing, or retaining that data for advertising, behavioral profiling, sale, or any other secondary commercial purpose.

Further duties would follow: to act with the care, skill, and diligence that an ordinarily prudent person would reasonably be expected to exercise in a like position and under similar circumstances; to maintain real-time records of actions taken on the user’s behalf and make them available to the user on request; and not to delegate, assign, or otherwise transfer authority granted by a user to another entity without the user’s express, specific, and revocable authorization.

The duties would not stop at the individual agent. A CUA provider would be responsible for establishing and maintaining reasonable measures for its agents to comply, and patterns or practices of violation would be attributable to the provider for purposes of deregistration and enforcement. The text also states expressly that these duties may not be waived, limited, or modified by contract, by terms of service, or by any form of user consent.

The role closest to what we later call the “accountable owner” — an organizational actor that carries responsibility — appears on the bill’s side too, as the CUA provider.

The Denial Process: Reasons, 14 Calendar Days to Cure, and an FTC Appeal

This part bears most directly on our subject. In what we have seen, the gap is rarely the ability to cut off outside access; it is the procedure around it — explaining why you cut someone off, giving them an opportunity to fix it, and being able to show a third party how the sequence went.

Where a platform provider denies a CUA access under its privacy and security standards, the bill sets out three steps. The provider would submit a report describing the basis for the denial to the FTC, in the form the FTC requires. It would provide the CUA provider a notice containing the rationale for why the agent failed to meet the privacy and security standards. And it would allow the CUA provider 14 calendar days to meet those standards, continuing to deny access during that period until the provider can demonstrate that the agent meets them.

A CUA provider could appeal a denial to the FTC, and the FTC could grant access if it finds the denial to be arbitrary, capricious, or not supported by the information the platform provider submitted. The reports would be made public with personally identifiable information and business-sensitive data removed.

Grounds for revoking or denying access are set out separately: the CUA provider has failed to register with the FTC; the agent repeatedly facilitates fraudulent or malicious activity; or the customer has revoked express written consent. The FTC would also establish rules and procedures for deregistering a CUA provider it determines has violated the duties. Enforcement would treat a violation of the Act as a violation of a rule defining an unfair or deceptive act or practice under the Federal Trade Commission Act, and in assessing any fine, the FTC would count each individual user affected by a violation as an individual violation.

The bill does not say why it goes into procedural detail at this level. But the sequence — notice of denial, a period to cure, an appeal — covers exactly the ground that tends to go missing when the receiving side decides on its own, and the attempt to standardize it is instructive as we revisit our own designs.

What the Bill Would Still Leave to Each Company

Everything above describes the bill. What follows is MIF’s analysis and should not be read as a statement of the bill’s requirements. It is how we take this material into designs for ourselves and for our clients, and the bill does not say these things.

We read the scope narrowly. The text’s “online provider” means a consumer-facing services provider, and the size threshold is more than 50,000,000; reading it as covering small-business systems or business-to-business SaaS as they stand departs from how it is written. Even so, the questions that arise when an outside agent acts for your customer have the same structure regardless of size or legal scope.

We have long held that the permissions given to an AI agent should be designed as a set of six elements, the same way they are for a human employee: identity, authorized scope, limits, accountable owner, audit trail, and access revocation. Setting them against the text is our mapping, not the bill’s.

Read side by side, much of what the receiving side previously decided case by case appears to be shifting to the text and to future standards. The concrete values for a given business process, and the internal arrangements around them, would stay with each company even once standards exist.

The table below is a starting point for drawing that line, not a statement of correct settings. The values you fill in change with your risk tolerance, your industry’s regulation, and how reversible your operations are.

Element	What the bill and future standards could standardize	What each company still decides
Identity	FTC registration of CUA providers as a precondition of access; rules verifying that a request originates with the user; NIST protocols for verifying CUA identity and registration status	How far registration or certification counts as grounds for trust, and for which operations; how you verify an agent before standards exist
Authorized scope	Standards for scope-limited and revocable delegation credentials; the scope of delegated access set for specific commercial settings; the principle of conferring no greater rights than the user has	Which of your own operations you open to delegation; whether access is read-only, permits changes, or allows transactions or payments
Limits	Reasonable thresholds on frequency, nature, and volume; fair, reasonable, and nondiscriminatory usage expectations; fees proportionate to cost, complexity, and risk	Business-specific values such as a per-transaction purchase amount or a daily request count; which metrics you cap and how you measure them
Accountable owner	The CUA provider carrying compliance measures as an organization; patterns of violation attributed to the provider	Who on your side approves access, and who holds the authority to shut it off
Audit trail	Real-time record-keeping by CUAs and disclosure to users; standards for creating auditable records; publication of denial reports	What you log on your own side, how you reconcile it against the other side’s records, and how long you retain it
Access revocation	User revocation and the mechanism to communicate it promptly; denial and revocation for non-registration or repeated abuse; deregistration by the FTC; notice of the reasons for denial and 14 calendar days to cure	How you detect anomalies; whether you scope a shutdown to the individual agent or to the whole provider; how you restore and re-authorize access

The right-hand column is hard to fill by reusing existing operational rules: approval flows and credit rules built with a human operator in mind do not assume an agent working at a far higher frequency and speed than a person.

This article addresses the decisions made by the party receiving an outside agent. Identity management for agents run inside a company, and any forecast of how far the bill will travel politically, are out of scope.

What Could Be Standardized—and What Would Remain Each Company’s Responsibility

As of August 2026, the AI AGENT Act is a bill referred to committee, and how it changes from here — or whether it is enacted at all — is unknown. The questions it raises, though, are material you can work with without waiting for that outcome.

The bill attempts to write registration, identity verification, delegation and revocation, access terms, and the denial process into a common framework. The operational side would remain with each company even if the bill became law: monetary and volume limits, the decision-maker inside your organization, the conditions that count as an anomaly, the scope of a shutdown, and the procedure for restoration and re-authorization.

Taking stock of whether agents acting for your customers might reach your service, and filling in the right-hand column above in your own words, is worthwhile preparation whatever becomes of the bill. At the very least, we think it leaves you better placed than receiving the first such request with no decision made about how you would say no.

Sources and Verification

This article was prepared as of August 2026, drawing principally on the text of S.5051 (the AI AGENT Act of 2026, as introduced in the Senate on July 21, 2026) and its bill-status record, both published through the U.S. Government Publishing Office’s GovInfo service. As background, we referred to an announcement from Senator Warner’s office concerning the discussion draft released on June 29, 2026. As secondary sources, we referred to a bill analysis by the law firm DLA Piper and reporting by the trade publication CyberScoop.

The FTC registration regime, the recognition of certification bodies, and the NIST technical standards described in this article are all things the text provides for should the bill be enacted; none of them exists as of August 2026. The mapping onto the six elements — identity, authorized scope, limits, accountable owner, audit trail, and access revocation — and the generalization beyond the bill’s scope are MIF LLC’s analysis, not the content of the bill.

As of August 2026 the bill has been referred to the Committee on Commerce, Science, and Transportation. The bill text and legislative status may change, and the bill may or may not be enacted. For the latest status, consult the official records of the U.S. Congress.