Proof Before Action: How We’re Designing Agent Authorization at Alquimia

Agents should be free to reason, but never free to reinterpret an approval. In Alquimia, consequential actions will execute only when the exact operation is bound to verifiable user intent.

01The gap between asking for permission and proving it

Human approval has become a common safety mechanism for AI agents. Before deleting a record, sending an external message, modifying permissions, or making a payment, the agent pauses and asks the user to confirm.

That is a meaningful control. But in most implementations, approval is still treated as conversational state.

The agent proposes an action. The user replies “yes.” The model interprets that response and continues. Somewhere in the application logs there may be enough context to reconstruct what happened.

The problem is that a conversational confirmation is not, by itself, an authorization artifact.

What exactly did the user approve? Was it the tool the agent eventually called, or only the action it described? Were the arguments changed between confirmation and execution? Was the approval intended for this system, this transaction, and this moment? Could it be replayed after the original request expired?

These questions matter because an AI agent is not a deterministic application screen. It can reinterpret context, retry an operation, reconstruct tool arguments, or be influenced by malicious input. Even a well-behaved agent can produce an execution that differs subtly from what the user believed they had approved.

For consequential actions, “the user said yes” is not enough. The system needs proof of what that “yes” meant.

02Authorization needs to describe the action, not just the actor

Identity and authorization solve different problems.

Identity tells us which user, agent, or service is participating. Authorization tells us what that participant may do under a specific set of conditions.

Traditional permissions are often broad: an agent may call a reservation API, access a customer database, or use an administrative tool. That establishes the outer boundary of what the agent can access, but it does not prove that the user approved one particular execution.

An agent may be authorized to call cancel_reservation, for example, while the user has only approved cancelling reservation RES-1042. The difference lives in the arguments, not the tool name.

The same applies to payments. Permission to use a checkout tool does not mean permission to purchase any item, from any merchant, for any amount.

We need an authorization model that can bind approval to the complete action:

• The tool being called.
• The exact arguments or a cryptographic hash of them.
• The user and agent involved.
• The system expected to execute it.
• The constraints under which it remains valid.
• Its expiration and single-use requirements.

The resulting evidence should be independently verifiable by the system executing the action. It should not need to trust the model’s memory or interpretation of the conversation.

03A general framework emerging from agent payments

The Agent Payments Protocol introduced mandates as a way to prove that an agent is authorized to complete a checkout or initiate a payment.

But the more important idea for Alquimia sits underneath those payment-specific flows.

The Agent Authorization Framework describes a more general model composed of two stages.

The first is mandate delegation. The action is presented to the user through a trusted, deterministic surface. Once the user approves it, the platform creates a signed mandate representing that authorization.

The second is action authorization. When a tool or external system requires proof, the agent presents the mandate. The receiving system verifies that the mandate is authentic, current, intended for that system, and applicable to the exact action being requested. After accepting or rejecting it, the verifier returns a signed receipt.

AP2 applies this model to payments through Checkout and Payment Mandates. But its authorization framework allows other mandate and constraint types to be defined for different use cases.

That distinction is important for us.

We do not see agent authorization as a payment feature that should be copied into every commerce integration. We see it as a platform capability that payments happen to need first.

04Authorization as a native Alquimia capability

Alquimia already controls the lifecycle through which an agent’s reasoning can become an action. It knows which agent is executing, which conversation is active, which tool has been requested, which arguments were proposed, and which channel should continue the interaction.

Authorization will become part of that same execution lifecycle.

Alquimia will define generic contracts for authorization requests, mandates, constraints, receipts, and their corresponding state transitions.

When a tool requires approval, Alquimia will pause execution and present the user with a deterministic description of the action. Once consent is obtained, it will create the authorization evidence and resume the operation with that evidence attached.

The model can propose an action, but deterministic platform code will control what is shown, what is signed, and what is executed. The signing key will never be available to the model or usable outside the approval flow.

Alquimia will provide the generic authorization lifecycle. Each tool or MCP will remain responsible for interpreting its domain rules, verifying the evidence it receives, and executing the corresponding operation.

This separation allows Alquimia to protect actions of any kind without incorporating payment, reservation, provider, or administrative business logic into the platform.

05Turning one approval into one verifiable action

The flow begins when an MCP tool determines that an operation requires explicit approval.

Instead of executing immediately, the MCP returns a structured authorization request. That request describes the canonical action, the intended verifier, the mandate type, the relevant constraints, and the information that must be shown to the user.

Alquimia then pauses the tool call.

The user sees a deterministic representation of the action through the same channel they are already using. For a court reservation, that could include the venue, date, time, duration, total amount, and payment destination. For an administrative tool, it could include the affected resource and the exact operation.

Once the user approves, Alquimia creates a closed mandate bound to that action. The mandate may contain the canonical arguments or a cryptographic hash of them, along with an audience, expiration, unique identifier, and single-use restriction.

Alquimia then presents the mandate to the MCP alongside the tool call.

The MCP verifies the signature and checks that the action matches the approved content. If an argument changed, the mandate expired, the audience is wrong, or the evidence has already been consumed, the operation fails.

After execution, the MCP returns a signed receipt referencing the mandate and the outcome. Together, the request, mandate, and receipt provide a traceable chain from user intent to system effect.

The conversation remains useful context. It simply stops being the only evidence we have.

06Starting with closed mandates before delegating autonomy

The framework distinguishes between closed and open mandates.

A closed mandate authorizes one concrete action for a particular verifier. It is appropriate when the user is present and can review the final terms: cancel this reservation, send this message, create this checkout, or delete this record.

An open mandate authorizes future actions within a set of constraints. A user might allow an agent to reserve courts under a spending limit for the next thirty days, or reorder an approved product when inventory drops below a threshold.

Open mandates make more autonomous experiences possible, but they also introduce a larger authorization surface. The platform must evaluate constraints, bind the mandate to the agent using cryptographic keys, account for prior usage, and ensure that every derived action remains within the original delegation.

Our first implementation will focus on closed, short-lived, single-use mandates.

That gives us a clear security property: one informed approval authorizes one precisely defined tool execution.

Open mandates can come later, once constraint evaluation, revocation, key binding, and consumption accounting are mature enough to support them safely.

07Payments become a profile, not the architecture

Payments are a natural first use case because the cost of ambiguous authorization is obvious.

Consider an agent that helps a user reserve a court. The MCP owns availability, pricing, reservation state, checkout construction, and integration with the selected payment provider. Alquimia owns the conversation, inference, pending action, and user approval lifecycle.

The merchant MCP can use UCP to publish its commerce capabilities and construct the checkout. When payment authorization is needed, it requests the relevant AP2 mandate.

Alquimia does not need to know whether the eventual payment uses Mercado Pago, Stripe, a hosted checkout page, or a tokenized payment instrument. Its responsibility is to ensure that the user approved the exact checkout presented by the merchant and to produce verifiable evidence of that approval.

The MCP verifies the mandate before creating or completing the payment. The payment provider remains an implementation detail behind the merchant boundary.

This separation gives us provider independence without weakening authorization:

• UCP describes the merchant’s commerce capabilities.
• AP2 defines payment-specific mandate types.
• The Agent Authorization Framework governs how approval is obtained and proven.
• MCP remains the transport and domain execution boundary.
• Alquimia provides the generic authorization lifecycle.

Payments are therefore one profile running on top of agent authorization, rather than the reason agent authorization exists.

08What this unlocks beyond commerce

Once authorization is native to Alquimia, the same model can protect any tool with meaningful side effects.

An agent could require a mandate before deleting customer data, changing access permissions, publishing content, sending a message outside the organization, approving a contract, starting an infrastructure deployment, or modifying a production configuration.

Each domain can define its own mandate type and constraints. Alquimia does not need to understand the business semantics of every tool. It needs a stable way to pause execution, obtain informed consent, bind that consent to canonical action data, and present the resulting evidence to the verifier.

That changes human-in-the-loop approval from a conversational convention into a platform guarantee.

It also improves auditability. Instead of reconstructing intent from model output and chat history, operators can inspect a signed chain showing what was proposed, what was approved, what was executed, and what the receiving system reported.

This architecture is still evolving. The Agent Authorization Framework itself currently lives within AP2 rather than as a fully independent standard, and its broader ecosystem will continue to develop.

But the underlying principle is already useful: autonomous reasoning and execution authority should not be the same thing.

Agents can decide what action to propose. Users decide what action to authorize. Deterministic systems ensure that the authorized action is the one that actually runs.

That is the boundary we are building into Alquimia.