A Focused Research Organization for delegable authority
One set of deliverables, built in the open and then handed over. A specification for authority that can be delegated and narrowed across organizational boundaries. A reference implementation. A conformance suite. And the revocation semantics nobody has built yet.
What agents can't do yet
Look at what agents can and cannot do with money right now. x402 gives an agent a clean way to pay for a single API request over HTTP. It works. It does not carry the authority to buy a service and resell it, or to hand a sub-agent a narrower slice of what it holds. Several groups are bolting those pieces on separately, each in a different shape.
The same thing happens away from payments. An account starts an agent to analyze transaction history, and the agent arrives able to issue transactions. One grant was all there was to give.
This is the ordinary condition of agent deployments running today.
What an answer has to do
These are properties any candidate has to deliver. They describe the problem, and they apply to the technology we prefer as much as to anyone else's.
-
Fine-grained authority that attenuates.
A holder must be able to narrow what it holds and pass the narrower version on, without going back to the issuer. Read the design docs, not the whole Workspace. Run the analysis, do not sign the transaction.
-
Delegation that survives a trust boundary.
A grant has to keep working when it crosses into an organization that shares no administrator, no directory, and no legal jurisdiction with the granter. This is what makes brokerage possible.
-
Revocation with organizational semantics.
Cutting a grant must sometimes cascade through everything delegated beneath it and must sometimes leave legitimate long-lived arrangements standing. Which one applies is a property of the grant, decided when it is made.
-
Accountability without identity lookup.
You should be able to establish what an agent was permitted to do from the structure of its authority, with no registry in the way. The liability apparatus sits alongside the mechanism and stays out of it.
How existing approaches score
| Attenuates | Crosses boundaries | Organizational revocation | Accountability without lookup | |
|---|---|---|---|---|
| OAuth scoped tokens | no | partial | no | no |
| Cloud IAM, agent identity | partial | no | no | no |
| Sandboxes, agent runtimes | no | no | no | no |
| Macaroons | yes | partial | no | no |
| UCAN, Biscuit | yes | yes | no | partial |
| AP2 payment mandates | partial | yes | no | yes |
| Object capabilities | yes | yes | no | partial |
Scopes in OAuth are set by the issuing service, so a holder cannot mint a weaker token for a sub-agent. Sharing the token is the only way to pass access along. IAM partitions authority by identity inside one administrative domain. Sandboxes confine where code runs and say nothing about what authority flows into it.
Macaroons make attenuation a first-class operation, though shared-secret verification makes every verifier a potential forger. UCAN and Biscuit do delegation chains properly and remain narrowly adopted. Google's AP2 mandates are portable and revocable by design, and they cover payments only.
One column has nothing in it. No shipped system handles revocation the way organizations work. That is the bottleneck this FRO exists to clear.
The unsolved part
Nobody has solved organizational delegation. Authority sometimes has to outlive the role of the person who granted it. A machine can hold authority from two sources at once.
We think the problem is solvable. We know where it breaks, and we can show which parts of an answer already work in production.
What the FRO delivers
- A specification for delegable, attenuable authority that crosses organizational boundaries
- A reference implementation
- A conformance suite
- Revocation semantics that handle both cascading cuts and legitimate long-lived grants
Public, unowned, and finished.
Why this is FRO-shaped
No single firm captures enough of the upside to pay for this work, and a firm that did build it would have every reason to sit in the middle afterward and charge rent. A disinterested party has to do it and publish the result. The work also ends, which makes it a poor fit for a standing institute.
Object capabilities are where we start because that is where our evidence is. Any architecture that meets the four requirements at production rigor has a place in what we fund and steward.
Built to finish
A Focused Research Organization takes on one bounded problem and stops when it is solved. Ours is done when the specification, the reference implementation and the conformance suite are public and adopted widely enough to survive without us.
Nothing we produce under the FRO will be owned by DCF or by anyone else.
