Authorization Notes No. 4
Imagine that your doctor sends a prescription to a pharmacy. The pharmacist can confirm which doctor issued it, which patient it is for, which medicine was prescribed, and whether the prescription is still valid.
Now imagine that the pharmacy performs all of those checks, displays a green result on a screen, and then dispenses the medicine through a separate system that never looks at the result. The prescription may be legitimate and the verification may be correct, but if the dispensing system releases the medicine either way, the check has not protected anything.
This is an easy failure to miss in software. A team can build identity, authorization, policy, and audit systems that all work as designed while the action that matters sits just outside them. The system can know that a request should be refused and still carry it out. Permission therefore has to be verified on the path to the action.
A valid proof can still be ignored
In the first three Authorization Notes, I wrote about the difference between identity and authorization, the danger of treating outside information as an instruction, and the boundaries that give permission its shape. All of those ideas assume something important happens next: the system responsible for the action must actually honor the permission.
Suppose a digital worker asks a payment service to send money. A separate authorization service checks the worker’s delegated authority and finds that the amount exceeds the approved limit. It records a refusal in a log. The payment service, however, is connected directly to the worker and never receives that decision, so the payment still goes through. Nothing was wrong with the authorization decision. It was simply not part of the action path.
The same failure can appear when a digital worker writes to a repository, changes a cloud environment, sends a document, places an order, or directs a machine. A proof may exist, a verifier may produce the correct answer, and an audit system may record it. None of those facts matter at the moment of consequence unless the system performing the action is required to stop when verification fails. A permission that travels but is not checked at that point is only paperwork.
The last responsible system has to enforce it
There may be many systems involved in a digital worker’s task. One interprets the person’s request, another plans the work, another carries a message, another verifies the authority, and another performs the action. These systems do not all have the same responsibility.
A messaging service can deliver a request without deciding whether the requested action should occur. An authorization system can evaluate authority without controlling a database, payment rail, or machine. The system that owns the consequential action is the one that must connect the verification result to enforcement.
This does not mean every application has to invent its own authorization protocol. It means the final decision cannot remain advisory. The repository must refuse the write. The payment service must refuse the transfer. The cloud platform must refuse the deployment. The machine controller must refuse the command.
I think of this as the last responsible system. It is the point after which the intended action becomes real. Before that point, software is still proposing, planning, carrying, or checking. At that point, something changes in the world.
Good authorization architecture makes that boundary explicit. It identifies the consequential action, places verification immediately before it, and fails closed when the authority is missing, expired, revoked, or outside its limits.
We learned this by getting it wrong
This month, we completed a live cross-company engagement with Agent Relay. We were testing whether one organization could give bounded authority to a digital worker operating in another organization’s environment, have that authority narrow across a handoff, and revoke it while the work was underway.
The chain mechanics worked. Authority narrowed as it moved from one worker to the next, and revocation propagated across the company boundary. But during the work, we found that Agent Relay’s publishing path was not initially connected to the protocol verifier. The publisher would have committed the change whether the delegation was valid, refused, or already revoked. We had working proofs and a working verifier, but the consequential write did not depend on either of them. What we had proven at that point was that a GitHub account could open a pull request, not that the write was controlled by delegated authority.
We fixed the integration so the write was mediated by the verification result before anything became observable. The more useful outcome, however, was the lesson. Producing proof, verifying proof, and enforcing the result are three separate jobs. A system is only protected when the three meet on the action path.
That finding is now part of the published technical note because leaving it out would make the successful run less useful. These seams are exactly where authorization systems fail in practice. Each component can pass its own test while the complete system still permits the action it was supposed to stop.
The receiver still decides
There is another consequence of putting enforcement at the action boundary: the sender cannot make the final decision for the receiver.
A company can authorize its digital worker to submit a purchase order. That authority gives the supplier evidence about who approved the request and which limits apply. It does not require the supplier to accept the order. The supplier still applies its own rules about inventory, fraud, payment, regulation, and risk.
The prescription works the same way. A valid prescription does not command a pharmacy to dispense medicine. It gives the pharmacy verifiable evidence of what the doctor authorized. The pharmacy checks that evidence, applies its own policy, and remains responsible for the decision.
Portable authority is therefore not a portable command. It gives the receiving system an input it can verify for itself. Local policy still decides whether the action may proceed, and local enforcement makes that decision real.
This is why cross-company boundaries are such an important test. Inside one application, it is easy to assume that an approval record, a policy decision, and an action belong to one trusted system. Across organizations, those assumptions fall away. The receiver needs evidence it can verify without joining the sender’s internal systems, but it also needs to remain in control of its own boundary.
Where Ratify fits
Ratify Protocol carries signed, scoped, and revocable delegated authority across that boundary. A receiving system can verify who granted the authority, which worker received it, what it may do, which resource and constraints apply, and whether the authority still stands without calling or trusting Ratify infrastructure.
Ratify does not perform the consequential action. It cannot enforce a repository boundary from inside a signature, move money, or stop a machine. The receiving system must place verification in front of the capability it controls and refuse the action when the authority does not hold.
The Agent Relay engagement demonstrated that arrangement across two company-operated deployments, but it also exposed the next bar. Both ends ran the same Ratify-integrated Agent Relay implementation. The stronger proof will come when an independently operated enforcement point, built and controlled by another party, receives a Ratify proof and honors it before a real action.
That is the boundary I am most interested in now. A contractor’s digital worker writing to someone else’s repository is one example. A payment initiated by a worker acting for another organization is another. In both cases, there is a clear chokepoint where a request becomes a consequential action and where the receiving side already has a reason to make its own decision.
Digital workers will create more of these boundaries as they take on real work. Giving them well-formed permission, carrying evidence across systems, and verifying that evidence are all necessary. None of it controls the outcome, however, until the system capable of acting is also capable of saying no.