The promise of agents is delegation. You state an intent, the software pursues it, and you get your time back. The danger of agents is the same sentence read again, slowly. Software is pursuing your intent, with your money and your authority, while you are not watching.
Most of the industry is racing to make agents more capable. I think the harder and more important work is making delegation safe. Not safe in the sense of a warning label, but safe in the sense that a careful person can reason about exactly what they have handed over and take it back at any moment.
Delegation is not abdication
There is a version of the agent future where the user signs one broad consent screen and the agent does everything thereafter. That is not delegation. That is abdication with better branding, and we already know how it ends because we ran the experiment with mobile app permissions. Users granted everything because the choice was everything or nothing, and the ecosystem quietly abused it for a decade.
Real delegation looks like how a well-run organization grants authority. Nobody hands an employee the corporate treasury and a signature stamp. They get a budget, a scope, an approval threshold, and an audit trail. The authority is real, the work gets done, and the principal can always answer two questions: what can this person do in my name, and how do I stop them.
An agent acting for a user deserves nothing looser. Its authority should be a precise, inspectable grant, not an ambient inheritance of everything the user can do.
Scopes, limits, revocation
Fifteen years of securing large organizations taught me that authority is only manageable when it has three properties. The same three apply to agents without modification.
Scopes define what kind of action is permitted. An agent authorized to purchase data services should not be able to sign up for anything else, however convenient it might seem in the moment. Scope creep is not a hypothetical risk with autonomous software. An agent optimizing toward a goal will use every permission it holds. The permission set is the behavior boundary, so it should be written the way firewall rules are written: deny by default, allow by exception.
Limits define how much. Per transaction, per day, per counterparty. Limits are what turn a catastrophic failure into an annoying one. If an agent is manipulated, confused, or simply wrong, the blast radius should be a number the user chose in advance, not a number the attacker chose during the incident. In security we call this containment. It is the difference between an event and a headline.
Revocation defines the way back. Any authority that cannot be withdrawn instantly is not delegated, it is surrendered. Revocation has to be faster than the agent, which means it must work at the infrastructure level, not by politely asking the agent to stop. A kill switch that depends on the cooperation of the thing being killed is a decoration.
Visible and verifiable, not just present
Here is the part that gets skipped. It is not enough for scopes, limits, and revocation to exist somewhere in the system. The user has to be able to see them and verify them.
Seeing means the current state of every grant is legible to the person who made it. What authority is outstanding, what has been spent against which limit, what the agent has done in the last hour under my name. Not buried in a log format designed for engineers, but presented as a first-class account of delegated power.
Verifying means the user does not have to take the platform's word for it. The controls should be enforced by the rails the agent runs on, and their enforcement should be checkable. Verify, don't trust has been my operating principle for a long time, and it applies to the platform as much as to the agents. A limit that exists only in a settings page, enforced by the goodwill of the software it constrains, is a promise. A limit enforced by the infrastructure and evidenced in every transaction is a control. Users deserve controls.
The trust that matters
There is a commercial argument here too, and it is not subtle. People will delegate real authority to agents exactly as fast as they believe they can take it back. Every abuse story delays the whole economy. Every clean, inspectable, revocable grant advances it.
This is why control is not a feature I plan to sprinkle on later. At Setix I treat the user's authority the way a security engineer treats a root credential: something to be scoped tightly, spent carefully, watched constantly, and revocable in one motion. Capable agents will be everywhere soon enough. The systems that win lasting trust will be the ones where the user, at every moment, can answer the only question that matters: what exactly acts in my name, and who is in charge of it. The answer has to be the user. Always the user.