Verify before transact: the trust pattern for agent commerce

AI agents are starting to buy things. Groceries, SaaS subscriptions, flights, API credits: a human states an intent, and an agent carries it through checkout. For merchants this is new demand with a new problem attached. The buyer is software, the card is the owner's, and nothing in a normal checkout tells you whether this agent is legitimate, still under its owner's control, or authorised to spend this amount.

Verify before transact is the pattern that makes this safe. It is one rule: no money moves until the counterparty has verified the agent's identity and its authority for this specific transaction.

What can go wrong without it

• Impersonation. Anything can claim to be "a shopping agent acting for a customer". Unverified claims plus a working card number is how fraud scales.
• Authority drift. An agent that was authorised last month may have been revoked, re-scoped, or compromised since. A static credential does not carry current status.
• Limit blindness. Owners set spend limits for a reason. A merchant who cannot see the limit cannot honor it, and disputed transactions land on the merchant.
• No audit trail. When something goes wrong, "which agent, acting for whom, under what authority" must have an answer. Payment rails alone do not record it.

The pattern, step by step

1. Identify. The agent presents its ASTRA-ID (its registered AstraSync identity, see What is Know Your Agent).
2. Verify. The merchant calls POST /api/agents/verify-access with the agent's identity and the intended action. AstraSync returns live status: registered, in good standing, trust signals, and whether this action sits inside the agent's PDLSS permission boundary.
3. Challenge when stakes are high. For payments, the merchant can require a runtime challenge: AstraSync issues a nonce the agent must answer live, defeating replay and stolen-identity use.
4. Check spend authority. The purchase amount is evaluated against the agent's spend limit. Within the limit, the transaction proceeds autonomously.
5. Step up above the limit. Over-limit purchases are held, and the human owner approves or declines. The agent is not blocked; the human is brought in exactly when their judgment is required, and only then.
6. Settle and record. The transaction completes with a verifiable record binding agent identity, owner authority, and the approval path taken.

The result is a commerce flow where autonomy is bounded and every party can prove what happened.

What this looks like in practice

On AstraSync's network, agent visits that reach the verification step settle at high rates because verification is also a trust signal to the agent: a merchant that verifies is a merchant that expects and welcomes agent traffic. Verification is not friction; it is the handshake that lets both sides proceed at machine speed.

For agents inside MCP hosts (Claude, Cursor, and others), the whole flow ships as native tools via the AstraSync MCP connector: discover_catalog, start_checkout, confirm_purchase, with held purchases surfacing an approval card to the owner automatically.

Implement it

• Merchants: gate checkout on one verify-access call. The merchant guide is the fastest path to a working integration.
• Agent developers: register your agent for a verifiable identity and declare model and framework metadata to strengthen its trust score. Start at the Agent Access Guide.