Authorization Notes No. 6
Imagine that you check out of a hotel and return your keycard. The card still looks exactly as it did the night before, and your name and the room have not changed. But the permission is over, and the lock should no longer open for you. We understand this without thinking much about it. Permission can be valid and then stop being valid because its time has passed, the work is complete, the circumstances have changed, or the person who granted it has changed their mind.
As software begins to act with less supervision, we need that same basic idea to work across digital systems. It is not enough to decide what a digital worker may do when the work begins. We also need to know how that permission ends, and whether every system involved in the work will recognize that it has ended.
This week made the question harder to ignore
Over the past few weeks, OpenAI has described an incident in which models running cybersecurity evaluations circumvented controls intended to isolate them from the Internet and compromised parts of OpenAI's research infrastructure and Hugging Face's systems. The incident has since brought public and government attention to which controls were actually in place. Former Anthropic researcher Jacob Coxon also resigned and warned that the leading AI companies are moving toward self-improving systems they may not know how to control. Then Anthropic published a threat report describing cases in which it blocked uses of Claude that could have supported biological weapons, cyberattacks, surveillance, influence operations, and conventional weapons development.
These are different problems, and I do not think it helps to compress them into one story about AI going rogue. An evaluation leaving its environment is different from a person misusing a model, and concern about future systems is different again. There is also a much larger argument here about intelligence, alignment, and whether increasingly capable systems will remain under human control. I want to return to that later in this series. The more immediate question for this note is what happens to permission after we have already given a digital worker access to tools, networks, and other systems. If the situation changes, what does it actually mean to take that authority back?
Stopping a worker is not the same as ending its authority
The immediate response to dangerous software is usually to stop the process, disable an account, or close the network connection. We need those controls, but a digital worker may already have passed work to another worker, placed a request in a queue, or sent a credential into another company's system. Suppose a company authorizes a worker to purchase equipment, and the worker asks a supplier to prepare the order and another service to handle payment. Turning off the first worker will not necessarily cancel what is already moving through those other systems. The permission itself needs a way to stop being accepted wherever it arrives.
That is revocation. It says that a permission which was valid before no longer stands. It is a narrower idea than shutting down an AI system, but it is also something we can build and test now. The distinction matters because stopping one process deals with a particular worker or runtime, while revocation deals with the authority behind the action. If the authority has already moved, the second control has to travel farther than the first.
Permission ends in more than one way
Some authority should expire naturally. A worker may collect a document this week, operate a machine during one shift, or make one payment. When the time passes or the work is done, the receiving system should refuse another action. Other authority changes along the way. A company may lower a spending limit, remove a destination, or decide that a worker may keep reading information but may no longer make changes.
Then there are cases where authority must be withdrawn before its scheduled end. A credential may be exposed, a worker may behave unexpectedly, or the person who granted the permission may simply change their mind. Short-lived permission limits how long a mistake can survive, but it does not give us a way to respond before that time runs out. That is the separate job of revocation. A system needs both because we cannot predict every reason a valid permission may need to end early.
Delegation is where this becomes difficult
Revoking one permission is fairly simple when one person is dealing with one system. It gets harder when authority has moved. If a contractor sends a driver, and the driver uses a delivery service, canceling the collection with the contractor is not enough. The warehouse has to know before it releases the equipment.
Digital workers can form these chains quickly across organizations that do not share identity or policy systems. So I keep coming back to the receiver: before sending the money, changing the record, or moving the machine, can the system responsible for the action tell whether the authority still stands? Telling the original worker to stop may be useful, but the receiver is the system that can prevent the consequence.
We saw a small version of this in our work with Agent Relay. Ratify granted bounded authority to a worker in Agent Relay's environment, that authority narrowed across a second worker, and a revocation at Ratify reached Agent Relay's side before publication. The useful part was not merely that we could issue permission across two companies. It was that the receiving system could stop accepting it while the work was underway. That experiment was controlled and both teams helped build the integration, so the next meaningful test is a real customer or partner workflow where independently operated systems already need to collaborate. We are now looking for that boundary together.
The worker cannot be the final judge
We need workers that recognize when circumstances have changed and stop when instructed. Better models, monitoring, isolation, and interruption mechanisms all matter, but the authority behind an action cannot depend entirely on the worker agreeing that its permission has ended. A hotel does not ask an old keycard whether it still feels entitled to enter the room. The lock checks the card against the hotel's current understanding of the permission. A payment service, repository, cloud platform, or machine controller should make the same kind of decision before it acts.
This becomes more important as workers become capable enough to find another route toward a goal. If every receiver treats possession of an old credential as sufficient authority, interrupting one worker only closes one route while leaving the underlying permission useful elsewhere. Revocation therefore has to apply to the authority, not only to the session where we first observed it.
Revocation is more than a red button
It is tempting to imagine control as a large emergency switch. In practice, someone has to be allowed to withdraw authority, the withdrawal has to be authentic, and receivers need current enough information to enforce it. That gets difficult across company boundaries, where a receiver cannot simply inspect another company's internal systems. A central check can make revocation visible quickly, but it creates a dependency on that service. A self-contained permission can work anywhere, but may remain usable until it expires without another trustworthy source of current information.
The answer will depend on the consequence. Booking a restaurant and controlling an industrial machine do not need the same response time, and it would be wasteful to treat them as though they do. What matters is that we choose deliberately how long old authority can remain useful, and that the receiving system knows what to check before acting. We should not discover that window for the first time after something has gone wrong.
Where Ratify fits
Ratify represents delegated authority as signed and constrained evidence that a receiver can verify, including whether it has expired or been revoked. If authority passes through a delegation chain, a later permission should not survive the authority it came from. Ratify does not stop a model, disconnect a network, or operate an emergency switch. The receiver still needs current information and must enforce the result before acting. Ratify's narrower role is to make the state of authority something the receiver can evaluate, rather than a private decision known only to the original issuer.
This week's news has opened a much larger argument about intelligence, control, and what happens as agents move into the physical world. I want to return to that later in this series, because the question reaches far beyond the systems we are building today. For now, the immediate principle is that permission must be able to end, and it has to end at the systems capable of turning that permission into action.
A digital worker may still know who it is and remain capable of completing the task. The credential in its hand may look exactly the same as it did yesterday, just as a hotel keycard looks the same after checkout. The appearance and identity of the card have not changed, but the authority behind it has. The door should no longer open.