Authorization Notes No. 3
Imagine that you hire a contractor to repair a leak in your kitchen. You give them a key and permission to enter on Tuesday, turn off the water, and replace one pipe.
The key gives the contractor access to your house. It does not give them permission to open every drawer, read your mail, or return whenever they want. The permission has a shape. It applies to a particular person, a particular job, a particular place, and a particular time.
If the contractor walks into a bedroom and starts looking through a closet, the fact that you gave them a key does not make that action acceptable. They have access to the house, but they are outside the permission you gave them.
That distinction is easy to understand when another person is standing in your home. It becomes less obvious when the actor is software, especially software that can choose its own steps while trying to complete a task.
Access is only the beginning
A digital worker may have access to your inbox, calendar, files, or payment account. That access is necessary for the work, but it does not describe the whole permission.
If you ask the worker to find a flight under a certain price, you have not necessarily given it permission to buy any flight. If you ask it to summarize your inbox, you have not given it permission to forward every message it reads. If you ask it to update one customer record, you have not given it permission to change every record in the system.
The software may have the technical ability to perform those actions. The question is whether the action is within the authority you granted.
This is one of the places where our usual language can mislead us. We say that an application has permission to access email or that a service has permission to call an API. Those statements are useful, but they are incomplete. They describe which doors the software can open. They do not always explain why it is opening a particular door, which room it should enter, or how long the key should work.
What a permission needs to answer
A useful permission should answer a few simple questions:
| Question | What it clarifies |
|---|---|
| Who granted the permission? | The source of the authority |
| Who received it? | The worker, service, or machine allowed to act |
| What action is allowed? | The work that may be performed |
| Which resource does it apply to? | The account, file, record, machine, or service in scope |
| What limits apply? | Amount, destination, time, quantity, or other conditions |
| When does it end? | Expiration, cancellation, or revocation |
These questions are not unique to software. A building manager may give a cleaning company access to an office on Saturday morning, but not to the server room. A hospital may authorize a device to send readings from one patient, but not from every patient in the building. A factory may allow one machine to stop a production line, but not to change its safety settings.
In each case, access is only one part of the arrangement. The purpose and the limits matter just as much.
Why broad permission is tempting
Broad access is convenient. It means fewer permissions to configure and fewer decisions to make before work can begin. That convenience is often why an application receives a role that covers far more than its immediate task.
The shortcut can be hard to notice when the software behaves as expected. A digital worker may read the right messages, update the right record, and finish the task without anyone seeing the extra authority it carried along the way. The problem only becomes visible when the worker encounters an unusual request or makes a choice that the person who started the task never intended.
Digital workers make this tradeoff more visible because they choose steps while working toward an outcome. They may discover a new tool, encounter a new piece of information, or decide that a different action would be useful. If their permission is broad enough, each new step can look technically valid even when it has moved away from the work the person intended.
The problem is not solved by making the worker less capable. A capable worker still needs clear boundaries. Otherwise, the system is asking the worker to turn a general instruction into an unlimited permission slip.
When the task changes
Suppose you ask a digital worker to arrange a hotel for a business trip. You give it a budget, a city, and the dates of the trip. While searching, it finds a website offering a more expensive room with a useful-sounding upgrade. The worker may be able to book it, and the payment service may accept the request.
But the ability to complete the purchase does not answer whether the purchase was authorized. The worker has moved from finding an option within the task to making a different choice with someone else’s money.
The same thing can happen when one system asks another system to help. A service may be allowed to prepare a report, but that does not automatically allow it to send the underlying data to every tool it discovers. A machine may be allowed to move a package through a warehouse, but that does not mean it can open any container it encounters on the way.
The more systems become connected, the more important this distinction becomes. An action can be technically possible and still be outside the permission that gave the work its purpose.
The receiving system has a responsibility
The system receiving an action should not have to guess what the permission means. It should be able to check whether the requested action fits within the authority behind it.
That check may still be combined with local policy, risk controls, and human confirmation. A valid permission does not make an action wise or safe by itself. It answers a narrower question: was this actor allowed to do this particular thing under these conditions?
This matters beyond digital workers. A bank receiving a payment instruction, a cloud service receiving a deployment request, and a machine receiving a command all face the same basic problem. They need to know more than which system sent the request. They need to know what authority stands behind it.
The larger authorization problem
We are beginning with digital workers because they make the problem visible. They can read information, choose actions, use tools, and ask other systems to help. But the underlying issue is much older and much larger than agentic software.
People have always needed ways to act on one another’s behalf. Organizations give employees authority. Governments give agencies authority. Services act for customers. Machines operate other machines. As more of these relationships become software-mediated, the systems involved will need a common way to understand the boundaries of authority.
That is the direction we are exploring with Ratify Protocol. The goal is to make the authority behind a request clear and verifiable as work moves between systems. The same idea should apply whether the actor is a digital worker, another service, a company, or a machine operating somewhere we cannot directly observe.
Permission is not just a key. It is a key that opens one door, for one purpose, under stated conditions, for a limited time.
That shape is what allows other people and systems to trust the action without having to treat every connection as unlimited authority.