Proof Before Action: How Alquimia Enforces Agent Authorization with Zero Trust and MCP

Giving an AI agent permission should mean more than capturing a “yes” in a conversation. In Alquimia, consequential tool calls are paused before execution, reviewed against current domain terms, and resumed only through deterministic authorization code.

The model may propose an action. Alquimia decides whether execution must stop. The MCP defines and verifies the terms the user sees. Only the exact pending action can continue.

##Approval is an execution control, not a conversational convention

Human approval is now a familiar pattern in AI systems. Before making a payment, modifying production data, sending an external message, or changing access, an agent pauses and asks the user to confirm.

The weak version of that pattern is entirely conversational. The model describes an action, the user says “yes,” and the model decides what to do next.

That creates an ambiguity exactly where the system needs precision. The action described in natural language may not be the action eventually sent to the tool. Arguments can be reconstructed, stale values can be reused, retries can create a second operation, and a response intended for one request can be interpreted in another context.

We wanted a stronger property:

One approval should release one already-pending tool execution, under the same terms the user reviewed.

That property cannot depend on the model remembering the conversation correctly. It has to be enforced by the platform and the system that owns the operation.

This is the authorization boundary now implemented in Alquimia.

01A deliberate split between platform and domain

The most important design decision is where the approval logic lives.

Alquimia owns the generic execution lifecycle. It knows which agent is running, which channel and conversation are active, which tool call is pending, and whether policy allows that action to execute automatically.

The MCP owns the domain meaning of the action. It knows which fields are authoritative, how to retrieve the latest state, what must be shown to the user, which responses count as approval or rejection, and whether the operation is still eligible to run.

For a court reservation, Alquimia does not need code for courts, schedules, prices, checkout states, or payment providers. The MCP does not need to reproduce the agent lifecycle, channel routing, or the Zero Trust policy engine.

The contract between them stays intentionally narrow:

• Alquimia can pause a tool call and request approval from its MCP.
• The MCP returns an opaque approval token and a deterministic message.
• Alquimia delivers that message through the original channel.
• The user’s answer is sent back to the MCP without a new model inference.
• The MCP approves, rejects, keeps the request pending, or replaces it with updated terms.
• Alquimia resumes the suspended call only after an approved result.

The platform controls execution. The MCP controls business semantics.

02Signed identity reaches the MCP without passing through the model

Approval is useful only if the verifier knows who is approving and which conversation the decision belongs to.

When Alquimia calls an MCP that enables trusted context, it creates a short-lived signed credential in the X-Alquimia-Context header. The credential binds the request to the active user, agent, channel, conversation, task, and MCP connection. It also carries an opaque notification token that can later resolve the original channel without exposing personal routing data.

This context is generated after the inbound channel has been verified. It is not an argument that the model can invent, edit, or replay into another MCP connection.

The MCP validates the signature, issuer, audience, expiration, and connection identity before accepting the actor. A valid service credential is not enough by itself: the request must also carry the trusted channel context expected for that tool execution.

This follows the same principle described in our Zero Trust implementation: identity establishes who is participating, while authorization still decides whether this specific action should run.

03The policy gate pauses the exact tool call

Every tool invocation passes through Alquimia’s authorization policy before execution.

The result is one of three decisions:

• ALLOW: execute normally.
• DENY: do not execute.
• REQUIRE_APPROVAL: suspend the call and create a pending approval.

In the checkout implementation, complete_checkout requires approval. Read-only discovery, availability, and checkout inspection remain normal tool operations. Creating the initial hold can also proceed without a second conversational confirmation; the consequential boundary is completing the checkout and producing the payment handoff.

When policy returns REQUIRE_APPROVAL, Alquimia does not ask the model to recreate the tool call later. It stores the pending execution under its control identifier and emits a generic human-approval event.

For MCP connections that enable the approval extension, Alquimia forwards that event to the MCP’s approval endpoint. The payload contains the pending tool name and arguments, but the MCP must obtain the authoritative review state itself.

This distinction prevents approval from drifting away from execution. The system is not authorizing a prose description of a future action. It is holding one concrete call that already exists.

04The MCP defines what the user is actually approving

The MCP starts the approval by reloading the current domain object.

For checkout, it calls get_checkout and verifies that the checkout is still ready_for_complete. It then constructs the user-facing message from canonical data: the checkout identifier, reservation details, currency, total, and expiration.

The message comes from the MCP, not from a generic template inside Alquimia and not from the model. That keeps presentation next to the domain rules that make it accurate.

The MCP also creates a short-lived signed approval token. The token is bound to:

• The verified channel actor.
• The agent, session, channel, and task.
• The pending control identifier.
• The checkout being approved.
• A cryptographic hash of the canonical terms.
• An issuance time and expiration.

Alquimia treats that token as opaque. It stores it only while the action is pending and delivers the MCP’s message through the original channel.

The user might see:

Confirm the reservation for Court 2 at 18:00, for ARS 20,000. This checkout expires at 18:10. Reply “Yes” to approve or “No” to reject.

The model is no longer responsible for deciding what that question means.

05The answer bypasses inference and returns to the verifier

When the user replies, Alquimia checks for a pending approval before starting another inference.

If one exists, the answer is sent directly to the MCP with the opaque approval token and a newly signed trusted context. The model does not classify “yes,” rebuild arguments, or choose the next tool.

The MCP then reloads the checkout again and recomputes the hash of its current terms.

Four outcomes are possible:

• If the answer is not a recognized decision, the approval remains pending and the MCP returns the deterministic message again.
• If the user rejects, the pending execution is denied.
• If the terms changed, the original approval becomes unusable. The MCP issues a replacement token and presents the new terms.
• If the user approves and the terms are unchanged, the MCP returns approved.

Only the last result releases the suspended call.

Alquimia claims the decision atomically so repeated channel messages cannot resolve the same pending control concurrently. The resumed tool call keeps its original control identity, while the MCP and domain backend apply idempotency to the operation itself.

This gives the flow two complementary protections: approval correlation in Alquimia and execution idempotency behind the MCP.

06What UCP contributes to the checkout

The MCP exposes its commerce surface using the Universal Commerce Protocol. Its public /.well-known/ucp profile advertises the shopping service, the checkout capability, the MCP transport, and an Alquimia authorization extension for operations that need explicit approval.

UCP gives the checkout a stable vocabulary independent of the internal reservation system:

• A held checkout becomes ready_for_complete.
• A payment handoff becomes requires_escalation.
• The hosted payment URL is returned as continue_url.
• Completed, canceled, processing, and refunded states map to consistent checkout outcomes.
• Amounts, line items, currency, totals, and expiration have predictable representations.

UCP does not make the authorization decision inside Alquimia today. The local Zero Trust policy remains the source of that decision and explicitly marks complete_checkout as requiring approval. This is deliberate: a remote profile may describe a capability, but it cannot weaken the platform’s local authorization ceiling.

The UCP profile and the local policy therefore describe complementary parts of the same boundary. UCP makes the merchant checkout interoperable. Zero Trust controls whether Alquimia may execute the consequential tool call.

07Hosted payment keeps the provider behind the merchant boundary

After approval, Alquimia resumes complete_checkout exactly once. The MCP verifies the trusted actor again, calls the domain backend with an idempotency key, and receives the current hosted-payment handoff.

The checkout response comes back as requires_escalation with a literal continue_url. Alquimia delivers that URL to the user without reconstructing it and without handling payment credentials.

The provider may be Mercado Pago, Stripe, or another hosted checkout service. That choice remains behind the MCP and merchant boundary. Alquimia sees the same control flow:

1. A UCP checkout is ready to complete.
2. Zero Trust requires approval.
3. The MCP validates the approved terms.
4. The provider returns a hosted payment URL.
5. The user completes payment outside the conversation.

Provider independence comes from keeping payment integration out of the platform, not from pretending every provider behaves identically.

08The browser return does not confirm the outcome

Opening or returning from a hosted checkout is not proof that payment succeeded.

The payment provider sends a signed webhook to the merchant system. That system validates the signature, payment identifier, status, amount, currency, and external reference before changing checkout state. Reservation confirmation and any compensating refund are idempotent domain operations.

Once the outcome is final, an outbox sends a signed notification to Alquimia. The notification contains an event identifier, the opaque routing token created for the original conversation, and the final text to deliver.

Alquimia validates the signature and timestamp, deduplicates the event, resolves the original channel, and delivers the message without another inference.

That last property matters. The model does not inspect a payment status and decide whether to say the reservation succeeded. The system that finalized the transaction supplies the result, and Alquimia transports it to the correct channel.

The same path can report success or compensation:

• “Payment approved. Your reservation is confirmed.”
• “The reservation could not be finalized and the payment was refunded.”

The outcome remains authoritative even when the original inference has long since finished.

09A generic approval mechanism without generic business logic

Checkout is the first complete implementation, but the transport is not limited to commerce.

Any MCP can opt into the same approval extension and expose endpoints that start and resolve an approval. The MCP may protect a deployment, a permission change, an external message, a data deletion, or another consequential action.

Alquimia does not need to understand those domains. Its reusable responsibilities are:

• Apply local tool-authorization policy.
• Suspend the exact tool execution.
• Preserve trusted channel identity.
• Deliver the MCP’s deterministic message.
• Route the answer without model interpretation.
• Resume or cancel the pending call.
• Deliver signed asynchronous outcomes to the original channel.

The MCP remains responsible for:

• Determining whether the domain object is eligible for approval.
• Selecting the authoritative fields shown to the user.
• Binding approval to current terms.
• Interpreting domain-specific responses.
• Rejecting stale, expired, or mismatched context.
• Executing the operation idempotently.

This is how we keep Alquimia generic without reducing approval to a generic “Are you sure?” prompt.

10What the implementation guarantees — and what it does not

The current design gives us concrete guarantees:

• The model cannot create trusted channel identity.
• A consequential tool call is checked before execution.
• The MCP, not the model, defines the approval terms.
• Changed terms require a new approval.
• The user’s answer bypasses inference.
• The originally suspended action is the one that resumes.
• Duplicate decisions, tool retries, webhooks, and notifications are handled idempotently at their respective boundaries.
• Payment success is confirmed by the provider webhook, not by browser navigation.
• The final message returns to the original channel without a new model response.

It is also intentionally scoped.

The approval token is an internal contract between Alquimia and the MCP, not a portable authorization credential for unrelated platforms. UCP discovery is published by the MCP, while Alquimia’s authorization decision remains locally configured. The first implementation covers short-lived, in-channel approval for one pending operation rather than broad delegated autonomy.

Those limits are useful. They keep the security claim aligned with what the system actually enforces today.

11Reasoning remains flexible; execution becomes deterministic

Agents need freedom to understand intent, gather context, compare options, and propose actions. That flexibility is what makes them useful.

But flexibility at the reasoning layer should not become ambiguity at the execution boundary.

The implementation now running in Alquimia separates those concerns:

• The agent proposes the tool call.
• Zero Trust decides whether it must pause.
• The MCP defines the exact terms.
• The user approves through the existing channel.
• Deterministic code verifies that nothing changed.
• Alquimia resumes the pending action.
• The domain system reports the real outcome asynchronously.

The conversation remains the interface. It is no longer the authorization mechanism.

That is the boundary we want for production agents: open-ended reasoning before the action, precise controls at the moment of execution, and an auditable path from user intent to system effect.