Eight weeks apart, two federal bills arrived carrying incompatible theories of what an AI agent is. S.5051, the AI AGENT Act of 2026, treats it as a fiduciary and regulates the companies that operate it. H.R.10362, the Stop Rogue AI Act, treats it as an unmanaged asset on your network and regulates the organisations that deploy it. One is a competition measure, the other a cybersecurity measure. Neither has moved past introduction.

They converge on one requirement, and it is an engineering requirement rather than a documentation one: the record of what an agent did has to be produced somewhere the agent does not control. Both bills describe a per-action record, held by a party with an interest in its completeness, available to someone other than the operator. Neither can be satisfied by a log the agent writes about itself. That convergence is the part worth building to, because it survives whichever of these bills dies.

What do the two bills actually require?

S.5051 was introduced by Senator Mark Warner on 21 July 2026 and referred to the Senate Committee on Commerce, Science, and Transportation. It has no cosponsors. Its official title is not about safety at all: "To promote competition and reduce consumer switching costs in the provision of online services."

The mechanism is delegation. The bill invents the custodial user agent — "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" — and gives users a right to point one at any platform with more than 50,000,000 US customers in a month. In exchange, the provider takes on duties that read like professional obligations: safeguard user data, avoid self-dealing, act with the care of an ordinarily prudent person, and keep the data out of advertising, profiling and secondary commercial use.

Two of those duties are architectural. Section 3(g)(1)(E) requires the agent to "maintain real-time records of actions taken on the user's behalf and make such records available to the user upon request," excepting records the user has directed it to delete. Section 3(g)(1)(F) forbids passing delegated authority to another entity's agent or AI system unless the user specifically authorises it and the recipient takes on the same duties.

And section 3(g)(3) closes the usual exit: these duties "may not be waived, limited, or modified by contract, by terms of service, or by any form of user consent." You cannot paper over this in a EULA.

H.R.10362 was introduced by Representative Josh Gottheimer, with Representative Mike Lawler, on 14 September 2026, and went to House Science, Space, and Technology plus Oversight and Government Reform. It has one cosponsor. Its official title is "To provide for certain artificial intelligence agent discovery and security standards."

It works through NIST rather than the FTC. Within a year of enactment, NIST would publish standards requiring deploying organisations to continuously discover and inventory the agents in their environment, verify agent identity cryptographically at the network and application layers, and — section 2(a)(4)(C) — "not rely solely on self-attested or single-provider assertions for establishing AI agent identity."

Section 2(a)(1)(H) is the record clause: organisations must "generate and retain tamper-evident, standardized logs of material AI agent actions, and ensure such logs are portable and accessible, as appropriate and consistent with law," to deploying organisations and authorised relying parties.

Then it grows teeth through procurement. Section 2(b) directs the Federal Acquisition Regulatory Council to write these standards into the FAR, with one required contract element worth reading twice: agent discovery and verification capabilities must be accessible to the contracting agency "without reliance on the contractor."

Why does an application-layer log fail both tests?

Because the entity being audited is the entity writing the audit.

This is not a diligence problem that better logging libraries solve. It is a placement problem. When an agent's own application code emits the record of what the agent did, four properties the statutes want are structurally unavailable.

Completeness cannot be demonstrated. A practitioner answering a Hacker News thread on adversarial audit of agent logs put it better than the bills do: "The real defensibility problem is completeness, not tamper-proofing." Proving nothing was omitted is harder than proving nothing was altered, and their fix was structural — an external watcher observing agent output independently, so the agent cannot selectively omit entries. Tamper-evidence, which H.R.10362 asks for by name, is a property of how a record is stored. Completeness is a property of where it is generated.

Per-user attribution is usually lost at the boundary. S.5051's duty is not to log actions; it is to log "actions taken on the user's behalf." A common pattern is to resolve a human user at the front door, then call outward under a service account or a shared API token. The outbound call — the action the statute cares about — arrives at the third party carrying the agent's identity, not the delegating user's. That is the same attribution gap SOC 2 auditors already flag on autonomous agent actions, now with a statutory duty attached.

Deletion has to be surgical. The section 3(g)(1)(E) carve-out for records a user has directed the agent to delete sets a user erasure right directly against an append-only log. Satisfying both needs record-level granularity and a split between what happened and the payload it carried. One immutable blob of request and response bodies cannot do it.

The delegation hop has to appear. Section 3(g)(1)(F) follows authority down the chain, and H.R.10362's monitoring clause covers agent interactions "with tools, data sources, information systems, and other AI agents." A record holding an agent's intent but not the hand-off to the next agent misses the event both bills aim at.

The per-user fine turns attribution into an exposure number

Under section 4(f)(1) a violation of S.5051 is treated as a violation of an FTC rule on unfair or deceptive acts. That much is conventional. Section 4(f)(2)(D) is not:

In assessing any fine for a violation of this Act, the Commission shall consider each individual user affected by a violation of this Act as an individual violation.

One defective code path multiplies by your delegating user count. That changes what the record is for. It is not just evidence that you complied; it is what bounds how large a failure was. If your logs cannot say which users an action was taken for, you cannot size your own exposure — or tell a regulator the number is smaller than they think.

This is why "we log everything" is not an answer to this clause. Volume is not attribution.

H.R.10362 describes a chokepoint without naming one

Read section 2(a)(1)(F) as a specification rather than as legislative prose. NIST standards must "enable continuous runtime monitoring and, where appropriate, inline detection and interception of AI agent interactions with tools, data sources, information systems, and other AI agents, including detection of prompt injection, data exfiltration, anomalous tool invocation, and behavioral drift from an AI agent's approved operational baseline."

Inline interception of tool interactions. Prompt-injection detection. Drift from an approved baseline. The bill defines organizational control in section 2(c)(7) as the ability to allow, deny or restrict which data an agent reaches, which actions it performs, and which tools, systems and agents it interacts with — and to revoke or change any of that at any time.

That is a description of a policy enforcement point sitting between agents and the things they call. The industry has reached for this shape before — API gateways, web application firewalls, identity-aware proxies — each time per-integration governance stopped scaling. The bill does not mandate that architecture. It mandates properties that are hard to get any other way, and the procurement clause pushes the control point out of the agent vendor's stack by design.

How Waxell handles this

Both duties land on tool calls and hand-offs, which is where the Waxell MCP Gateway sits. Agents point at one governed MCP endpoint per tenant instead of configuring each upstream separately. A tools/call that reaches the Gateway is evaluated against the tenant's policy rules before the upstream sees it, and the result is checked again on the way back; rule changes reach the fleet within seconds, without a restart.

The record is produced by the Gateway, not the agent. The audit log holds the resolved identity, the decision that applied and the rules that fired, exports to CSV, and stores no payloads — the split that lets a per-record deletion right coexist with a durable compliance artifact. Identity resolves to a real person rather than a service account, so the delegating user rides the outbound call and shows up in the upstream's own log. When someone leaves, deactivating their Waxell account unwinds that user's per-upstream OAuth grants in one transaction and writes the revocation event, actor and unwound upstreams into the same log — the counterpart to treating OAuth grants as indicators of compromise.

For the drift clause, the Gateway fingerprints the tools it discovers across connected upstreams against name, description and input schema. A newly discovered tool cannot be called until an admin approves it; a trusted tool whose description or schema changes returns to Drift Detected and resurfaces for admin review, and a deny_drift policy rule — recommended in Waxell's starter rule set, though not on by default — blocks the drifted tool from that point. Descriptions are scanned for embedded instructions at fingerprint time, before any agent calls them.

Hand-offs are the other half. Waxell Connect — which includes the MCP Gateway — keeps the versioned record of work moving between agents and people, the artifact section 3(g)(1)(F) and the agent-to-agent monitoring clause both point at.

One honest limit. A gateway governs the calls routed through it. Agents holding direct upstream credentials, locally registered MCP servers and unconfigured clients bypass it, so coverage is configured rather than given. If your compliance story rests on the record being complete, the inventory of what actually routes through the chokepoint matters as much as the chokepoint.

FAQ

Is the AI AGENT Act law?

No. S.5051 was introduced on 21 July 2026 and referred to Senate Commerce, Science, and Transportation, where it sits with no cosponsors. H.R.10362 was introduced on 14 September 2026 with one cosponsor. Both are at the introduction stage. The reason to read them now is not that either will pass; it is that two drafters working from opposite premises specified the same record.

Does S.5051 apply to internal enterprise agents?

Only obliquely. Its duties attach to a custodial user agent — one a user has authorised to act on their behalf against a large online platform, meaning a service with more than 50,000,000 US customers in a month. An internal agent calling your own systems sits outside that definition. H.R.10362 is the one aimed at deploying organisations generally, reaching internally built, vendor-acquired and externally operated agents alike.

What is the difference between tamper-evident and complete?

Tamper-evidence proves a record was not altered after it was written. Completeness proves nothing was left out. Hash chaining, signing and timestamping deliver the first and say nothing about the second. If the component being audited decides what to write, an omission leaves no trace — which is why both bills push the record toward a party other than the agent.

We already keep OpenTelemetry traces. Is that enough?

For debugging, often. For these clauses, traces are a strong input and an incomplete answer: they are emitted by the instrumented process — the same placement problem — and are usually keyed to sessions and spans rather than to the delegating user and the specific outbound action. The gap to close is attribution at the boundary, not trace volume.

What can we do before anything passes?

Three things are worth doing whichever way this goes: make outbound actions carry the identity of the person they were taken for; move record generation off the agent and onto whatever the action passes through; and separate the fact of an action from the payload it carried, so deletion rights and retention duties do not fight.

Sources

• US Congress, "S.5051 — AI AGENT Act of 2026, text as introduced", 119th Congress, introduced 21 July 2026

• US Congress, "S.5051 — all information (sponsor, actions, cosponsors, committees)", 119th Congress

• US Congress, "H.R.10362 — Stop Rogue AI Act, text as introduced", 119th Congress, introduced 14 September 2026

• Ellen P. Goodman, "Senator Warner Makes a First Foray into Agentic AI Regulation", Tech Policy Press, 13 July 2026

• Hacker News, "Ask HN: What makes AI agent runtime logs defensible under adversarial audit?"

Two drafters who agree on nothing else both decided an agent should not author its own audit trail. That is not a prediction about which bill passes. It is a hint about which part of your architecture is load-bearing.

Start free with the Waxell MCP Gateway — one governed upstream, 10,000 traced executions a month, and an audit log your agents do not write: https://waxell.dev/signup