A permission slip, not a password
Most agents run on their user's full credentials. A bill introduced this week describes what they should have instead in four words, and the four words make a decent engineering spec.
Try this scenario on whoever owns the agent platform at your company. You tell an agent “find me a shirt for under $30, but don’t buy it.” It buys the shirt. Now: who can prove what you asked for?
In most of the agent systems I’ve reviewed, nobody can. The agent logged in as you. It used your session, your card on file, your API key. From the merchant’s side the purchase is indistinguishable from you clicking the button yourself. The log, if there is one, says “user bought shirt.”
That’s the default architecture right now. The agent doesn’t get a permission slip. It gets your password.
Some of this is starting to get fixed at the protocol level. Google’s Agent Payments Protocol (AP2) has the user sign an intent mandate when they give the instruction and a cart mandate when they approve a specific purchase, so there’s a signed record of what was asked and what was agreed. NIST put out a concept paper in February on how an agent proves its authority and ties it back to a person. And on Tuesday, Senator Warner introduced the AI AGENT Act, which defines a “custodial user agent” as one authorized to act for a user “in a transparent, documented, limited and revocable manner.”
I don’t know whether that bill passes. I do think those four words are a better engineering spec than most of what I’ve seen written by engineers. So here they are, one at a time, the way I’d apply them to an agent shipping this quarter.
Transparent
The other side should be able to tell it’s dealing with an agent, and on whose behalf. Google’s calling agent opens every call by saying it’s an automated system from Google acting for a user. Do the equivalent in software: give the agent its own identity instead of a borrowed one. A separate API key, a separate service account, a user-agent string that says what it is. If the agent is indistinguishable from the human in your logs, you’ve already lost the first argument you’ll have about what happened.
Documented
Every action gets a record that points back to the instruction that caused it. Something better than “user bought shirt”: agent run 8f3a, acting on the instruction “find a shirt under $30, don’t buy,” called place_order with these arguments at 14:02:11. Store the instruction verbatim, hash it, reference the hash from every downstream call. It’s the same trace I asked for in the architecture checklist, with one addition: the trace has to include what the human actually said.
Limited
This is the one that gets skipped. The agent’s credentials should be scoped to the task, not to the user. A spend cap. A time window. A list of allowed operations. “Read inventory and reserve a slot” is a scope. “Everything my account can do” is not. Most OAuth setups make this harder than it should be, so in practice I end up with a small broker service that knows the task and mints a short-lived token with the narrowest scope that’ll get it done. It’s about a day of work, and it removes an entire category of “why did it do that” meetings.
Revocable
If the human can’t stop it mid-flight, the agent isn’t acting for them. Every long-running task needs a cancel that works within seconds, and the credential should die with the task, whether the task finished, failed, or got killed. “Who can turn it off?” was the last question on my checklist for a reason.
None of this needs a law, a foundation, or a new protocol. It needs a broker for scoped credentials, a log format with the instruction in it, and a cancel button that does something. If the regulation shows up, you’ll already be there. If it doesn’t, you’ll still be able to answer the question the shirt scenario asks, which is the one your users will ask the first time something goes wrong.