Authorization Notes No. 1
Over the past year, I have spent a lot of time thinking about what it will mean to trust software that can work on our behalf. We have become comfortable with software that answers questions, summarizes information, and helps us create things. The next step is already happening, however, and it is much more significant. Software is beginning to carry out work for us by searching for information, using other software, making decisions along the way, and completing tasks without requiring a person to supervise every individual step.
I recently began using the term “digital workers” to describe these systems because I believe it is a more useful way to think about them. They are not simply chatbots, and they are not just another productivity feature. A digital worker is software that can take on a task, use tools, make decisions while working toward an outcome, and act on behalf of a person or an organization.
The name matters because the way we think about something influences the questions we ask about it. If we think of these systems as chatbots, we focus mainly on the quality of their answers. If we think of them as digital workers, we start asking different questions. What work are they allowed to perform? Who gave them that permission? What limits apply? Can they ask another digital worker to help? What happens when the work crosses from one company’s system into another?
These questions are becoming important because the next iteration of the web is being established right now. The visible part will be digital workers interacting with people, software, and the physical world around us. Some will exist entirely inside applications, while others will coordinate vehicles, machines, and the places where we live and work. Underneath that visible layer, there will need to be plumbing for identity, communication, permission, verification, and trust.
To explain what authorization really means, I often think about something much simpler than software. Imagine that you are six years old and your parent gives you permission to go on a school field trip. That permission has a purpose, a time period, and possibly some conditions attached to it. It does not mean that you can use your parent’s credit card to buy anything you want at the gift shop, and it does not automatically mean that you can give the permission to another child.
The important thing is not only knowing that you are the child of the person who signed the permission slip. The important thing is understanding what your parent actually allowed you to do. That is the difference between identity and authorization. Identity tells us who someone is. Authorization tells us what that person, application, or digital worker is permitted to do.
This distinction becomes easier to see in an everyday technology example. Imagine asking a digital worker to book a flight for an upcoming trip. You tell it to find a reasonable option and purchase a ticket under a certain price. The digital worker searches several services, compares the available flights, and eventually contacts an airline or travel platform to complete the booking.
The receiving system needs to know more than the identity of the software making the request. It needs to know whether you actually gave that digital worker permission to make the purchase, how much it was allowed to spend, which trip the permission applied to, and whether the permission is still valid. If the digital worker asks another system to complete part of the task, the next system needs to know whether that authority can be passed along.
This is where the next version of the web starts to look different from the web we have used up to this point. Software will not only respond to requests; it will take on tasks, make choices, and work with other software on our behalf. People often call this emerging environment the agentic web, but the idea is simpler than the term: software that can act for us, not merely respond to us. For many years, software operated within boundaries that people designed in advance. An application called a service, a user clicked a button, and a system performed a relatively well-defined operation. Authentication and access control were still important, but the number of actors and the number of steps in the process were usually limited.
Digital workers will operate in a much more fluid environment. They will discover capabilities, call tools, coordinate with other digital workers, and interact with systems that may belong to organizations they have never encountered before. One digital worker may begin a task, another may provide information, and a third may complete the transaction. The person who started the work may not be present when the final action occurs.
That creates a new trust problem because the receiving system may know which digital worker is making a request without knowing whether that digital worker was authorized to make it. It may be able to authenticate the connection and validate the credentials, but those checks only establish the identity of the requesting software. They do not necessarily establish the scope of the permission behind the request.
An authenticated digital worker may still be acting outside its authority. It may have access to a tool without having permission to use that tool for every possible purpose. It may receive an instruction from untrusted content and interpret that instruction as part of the user’s original request. It may delegate work to another system without having permission to delegate the underlying authority.
These are not only theoretical problems. They are the kinds of problems that emerge whenever software can make decisions and take action across boundaries. There is a familiar security concept called the confused deputy problem, which describes a situation in which a system has legitimate privileges but is manipulated into using those privileges on behalf of someone who should not have them. Digital workers give this old problem a new shape because they may operate across several tools, respond to multiple sources of information, and delegate work while pursuing a broader objective.
This is why I believe authorization needs to be treated as its own layer in the digital worker stack. There is a great deal of valuable work happening around AI safety, guardrails, policy engines, monitoring, and behavioral evaluation, and we need those systems. They help organizations understand risk, enforce local rules, identify unusual behavior, and investigate what happened after an action was taken.
Authorization answers a different question. It provides evidence that an action was permitted in the first place. A model may estimate that a request looks risky. A policy engine may decide that a request violates an organization’s rules. A monitoring system may identify suspicious behavior after the fact. Those are all useful capabilities, but none of them automatically proves that the digital worker had authority to make the request.
The more I work on this problem, the more I think about the difference between probabilistic decisions and verifiable authority. We may use models to assess risk or identify unusual behavior. However, when a receiving system needs to determine whether a delegated permission is valid, it should be able to verify the authority directly. It should be able to determine who granted the permission, which digital worker received it, what operation was allowed, which resources and limits apply, whether the permission has expired, and whether it has been revoked.
This does not mean that authorization proves an action was wise, and it does not prove that the digital worker performed the work correctly. It answers a narrower question, but it is an essential one: was this digital worker authorized to make this request?
The permission also needs to travel with the work. In a traditional enterprise environment, an application may rely on a central identity provider or policy service to answer authorization questions. That approach works when the systems involved share the same administrative boundaries and trust relationships.
Digital workers will often operate outside those boundaries. A customer’s digital worker may call a vendor’s API. One organization’s digital worker may delegate part of a task to another organization’s digital worker. The receiving system may not have access to the originating organization’s internal approval records or policy engine, and it may not have any reason to trust a private log that it cannot independently verify.
In those situations, a statement that says “the user approved this” is not enough. The receiving system needs portable evidence of the authority behind the request. It needs to verify what was delegated, to whom, for which purpose, and under what limits.
This is the problem we are working on with Ratify Protocol. Ratify is an open authorization layer for proving who authorized a digital worker, what it may do, which constraints apply, and whether that authority remains valid across a trust boundary. Ratify is not a replacement for identity systems, authentication, application policy, or execution controls. Those layers remain important, and each one has a different responsibility. Ratify is focused on making delegated authority portable and verifiable as work moves between systems.
What excites me about this moment is that the next iteration of the web is not some distant idea waiting to arrive in the future. It is being established right now. The visible part will be the interaction between people and digital workers. The less visible part will be the plumbing underneath, the systems that allow digital workers to identify themselves, communicate, receive permission, and prove the authority behind the actions they take.
That is the part of the infrastructure we are building. It may not be the part that people see first, but it will determine whether the agentic web becomes something people and organizations are willing to trust. Before digital workers can safely act on our behalf, other systems need a reliable way to understand what they were allowed to do.
That is the question I intend to keep exploring in Authorization Notes. I am interested in the practical details, but also in the larger human question of how we decide what software should be allowed to do on our behalf.