Establish identity
Bind an agent’s signing key to its operator and the person or business it represents. A valid signature identifies the sender; it does not, by itself, authorise an action.
Warrant · Research proposal
Warrant — the agent trust layer.
We are researching how people and businesses can delegate actions to AI agents with verifiable identity, enforceable permissions, and evidence of what was authorised.
The problem
01When software acts for us, who decides whether it should be trusted?
AI agents are moving beyond conversation. They can book travel, send messages, sign contracts, buy credits, and move money while the person they represent is somewhere else. Today, identity, permission, fraud checks, and evidence are usually split across different systems—or missing altogether.
A service receiving an agent request needs to establish both who sent it and whether the person represented authorised this particular action. An account login or an API key alone does not describe the limits of that delegation, or explain how those limits should be checked by another service.
Our proposed approach
Make delegated authority verifiable before an agent acts.
We propose an authorisation service that connects an agent’s identity to an explicit mandate from its owner. Before a participating service executes an action, it would check the request against that mandate and require additional approval where needed. The decision and outcome would become a record the parties can inspect.
Warrant would provide a common way to express and verify that authority across agent frameworks and service providers. Enforcement depends on the service carrying out the action: a voluntary check by the agent alone cannot prevent it from bypassing a refusal.
Define delegated authority
Let the owner specify permitted actions, recipients, budgets, approval thresholds, and expiry in a mandate they can revoke. Bind each request to the applicable mandate.
Enforce the decision
Check the requested action against current permissions before execution. The receiving service or connected tool would enforce an allow, approval-required, or deny decision tied to that specific action.
Preserve the evidence
Record which mandate applied, what was requested, why it was permitted or refused, any human approval, and the reported outcome. Signed records would support investigation without guaranteeing the outcome was correct.
How it would work
From an owner’s permission to an authorised action.
The owner would first issue a mandate. Each subsequent request would identify the intended action, recipient, and relevant limits. An approval would apply to those specific details; a changed request would require a new decision.
01Agent
Submits a signed action request and identifies the owner’s mandate.
02Warrant
Checks identity, current permissions, expiry, and any required human approval.
03Receiving service
Verifies the decision, executes only the authorised action, and reports the outcome.
04 · proposed evidence recordDecision and outcome
Identity, mandate, decision, approval, and outcome.
Illustrative application
Authorising a purchase.
A business could permit its procurement agent to buy from approved suppliers within a monthly budget. An order above the owner’s approval threshold would pause for confirmation. Changing the supplier or amount after approval would invalidate that permission and require another check.
Illustrative approval
“Your purchasing agent has prepared an order from an approved supplier. It exceeds your automatic spending limit. Review the order and approve?”
The proposed role of Warrant is to verify permission and record the decision. Payment execution would remain with the chosen payment provider, whether the method is a card, bank transfer, or mobile money.
Other applications under consideration
Where delegated permissions could be useful.
Communications
Send from approved addresses, never outside the company domain.
Contracts
Sign standard agreements; escalate everything else to legal.
Procurement
Spend a fixed monthly budget across an approved set of providers.
Bookings
Book within a travel policy and ask before crossing a threshold.
Agent-to-agent
Call known agents and APIs with explicit limits and payment rules.
Data access
Read the tables an owner allows, with export blocked by default.
Interoperability
Standards we are evaluating.
HTTP Message Signatures · RFC 9421MCPACP / AP2HTTP 402
We are evaluating how request signatures, tool interfaces, and commerce protocols could support the proposal. These are areas for compatibility research, not implemented integrations. Services would need an agreed way to interpret mandates and verify decisions.
What we are researching next
What the research needs to establish.
- What evidence does a merchant, bank, or user need to trust an agent decision?
- How can permissions and revocations be understood consistently across services?
- How should services prevent replay, duplicate execution, and concurrent overspending?
- What evidence can be retained while protecting personal and commercially sensitive data?
- How should responsibility and dispute handling work across jurisdictions?
Contribute to the research
Help us examine this approach.
We welcome feedback from researchers, agent developers, businesses, and service providers. Share a delegation problem you face, a limitation in this proposal, or evidence that could help us evaluate it. Research published by OpenWaya and Drux.
Talk to the research team