Authorization Notes No. 2
Imagine that you are staying at a hotel and ask the concierge to arrange a car to the airport the following morning. You tell the concierge when you need to leave and give permission for the cost to be charged to your room. Later that evening, someone else approaches the desk, says they are traveling with you, and asks the concierge to arrange another car and charge it to the same room.
The concierge is a real employee. They are allowed to use the hotel’s booking system, and they have legitimate access to your room account. If they arrange the second car, none of those facts will change. The problem is not that an intruder broke into the system or pretended to be the concierge. The problem is that someone with legitimate access was persuaded to use it for a person who never had your permission.
This is an old problem, but it is taking on a new shape as digital workers begin doing more of our work. A digital worker may start with an instruction from you, then read emails, visit websites, open documents, call tools, and communicate with other systems while completing the task. Every one of those places can provide useful information. They can also contain instructions that did not come from you.
That creates a question we will need to ask more often: whose instructions is the digital worker actually following?
When information starts behaving like an instruction
Suppose you ask a digital worker to review your inbox and prepare a summary of the messages that need your attention. One email includes a sentence telling the digital worker to forward certain messages to another address. You would recognize that sentence as part of the email, not as a new instruction from you. A digital worker may not always preserve that distinction.
The same problem can appear on a webpage, inside a document, in a calendar invitation, or in the result returned by a tool. Some instructions may be obvious. Others may be hidden in text a person would never notice. The digital worker reads the material because that is part of the work you asked it to do, but the material itself can attempt to redirect the work.
This is commonly called prompt injection. When the instruction is placed in outside content that the digital worker later encounters, it is often called indirect prompt injection. NIST also uses the term agent hijacking, which describes the result more plainly: an attacker places instructions in data the digital worker is expected to process and tries to steer it toward an action the user never requested.
The difficult part is that the digital worker does not need to lose its identity for this to happen. Its credentials may still be valid. It may be using an approved tool through an approved connection. To the system receiving its request, everything may look normal. The digital worker still has the technical ability to act. What has changed is the purpose behind the action.
The confused deputy is back
Security researchers have a name for the broader pattern: the confused deputy problem. A deputy is given legitimate power to do something for one party, then becomes confused about whose interests it is serving and uses that power for someone else.
The hotel concierge is the deputy in the opening example. The concierge has access because the hotel trusts them to perform certain duties. The stranger does not have that access, but tries to get the concierge to use it on their behalf. The concierge does not need to be malicious. They only need to misunderstand who authorized the request.
Digital workers can become confused deputies in much the same way, although the number of possible instructions is much larger. A request from the user, a system rule, an email, a webpage, a tool response, and a message from another digital worker may all arrive as language. The digital worker must continuously decide which information is relevant, which directions have priority, and which actions are appropriate.
This is one reason the problem cannot be reduced to whether we trust the model. A capable digital worker may be better at recognizing suspicious instructions, but it will still work with content created by people and systems it does not control. Anthropic, for example, describes prompt injection as one of the most significant security challenges for browser-based agents and says plainly that the problem is not solved.
We need better model training, detection, isolation, tool restrictions, and human confirmation for consequential actions. Those defenses reduce the chance that a digital worker will be redirected and limit the damage if it is.
But they do not answer another important question. If a digital worker asks a receiving system to transfer money, send a document, change a reservation, or update a production system, what evidence shows that the action falls within the authority the person actually gave it?
Access is not the same as purpose
Most software permissions describe access in fairly broad terms. An application may be allowed to read email, write files, create calendar events, or call a payment service. Those permissions tell us which doors the application can open. They do not always tell us why it is opening a particular door at a particular moment.
Giving a digital worker access to email so it can prepare a summary does not mean every instruction found inside an email should be allowed to use that access. Giving it access to a payment tool so it can book one approved trip does not mean a website can instruct it to make a different purchase. The tool access is real, but the purpose may have changed somewhere along the way.
The receiving system often cannot see that change. An email service sees software with valid credentials. A payment system sees an account that is allowed to make a purchase. A file service sees an authenticated digital worker asking to read or write a document. If the only question is whether the caller has access, the request may pass every check.
Knowing which digital worker made a request is not enough. We also need to know whether the action is supported by the authority that digital worker received. Identity tells the receiver who is at the door. Delegated authority should explain what that digital worker was permitted to do there.
Authority should not come from the content being read
There is a simple principle underneath all of this: the material a digital worker encounters while doing a task should not be able to grant itself authority.
An email can provide a delivery date. A website can provide a price. A document can contain facts needed to complete a report. A tool can return the result of a search. Those sources may influence how the digital worker completes the task, but they should not be able to enlarge the permission behind the task simply by including a new instruction.
The authority needs to come from somewhere separate. It should come from the person or organization entitled to grant it, and it should remain limited to what that principal allowed. If the work changes enough to require a new permission, the system should obtain one rather than treating the digital worker’s evolving context as an unlimited source of approval.
This does not mean every small decision needs a person clicking an approval button. That would defeat much of the reason for using digital workers. It means the boundaries of the work should be established in a form that the systems involved can evaluate. Within those boundaries, the digital worker can still make choices. Outside them, the action should require additional authority or be refused.
Where Ratify fits
This is one of the reasons we are building Ratify Protocol. Ratify gives a receiving system a way to verify the delegated authority behind a digital worker’s request: who granted it, which digital worker received it, what it was allowed to do, which limits apply, and whether that authority is still valid.
Ratify does not detect every malicious instruction, and it does not decide whether a digital worker has interpreted a task wisely. It does not replace prompt-injection defenses, model safeguards, gateways, sandboxes, or local policy. Those systems answer different questions and remain necessary.
What portable authorization can do is prevent the content a digital worker encounters from becoming authority merely because the digital worker acted on it. A malicious email may still try to persuade a digital worker to send a file somewhere else, but the receiving service should be able to ask whether the digital worker was actually authorized to send that file to that destination. If the action falls outside the delegated authority, valid credentials should not be enough to make it valid.
As digital workers become more useful, they will read more of the world around us and take more actions within it. We should continue improving their ability to distinguish trustworthy instructions from manipulation. We should also build systems that do not depend entirely on them getting that distinction right every time.
The digital worker may know who it is. The receiving system should still be able to verify whose authority it is acting under.