APASS: Identify the Agent, Its Runtime and the Responsible Organization

A merchant receives two requests carrying the same agent brand. One comes from an approved deployment; the other may come from a modified instance using the same name. A logo or user-agent string cannot explain the difference. APASS proposes a layered identity model for this kind of agent-commerce interaction.

Review scope: official public architecture reviewed November 1, 2026. We did not access a private APASS console, issue credentials or run an adversarial verification test. Product security statements are attributed to their publisher, not presented as our measured results.

Three identities answer different questions

The APASS page separates static agent identity, runtime identity and the entity responsible for the agent. It also describes ongoing checks and a credential flow from issuer to agent to verifier. This is a richer model than a single reusable “verified agent” badge.

For the merchant, the practical questions are distinct: which software is represented, which running instance is making this request, and which organization is accountable? A deployment update can change one answer without changing the others. Record those distinctions rather than allowing an old organization-level approval to stand in for every new runtime.

Conceptual interpretation of the public APASS model. The merchant-policy step represents an integration responsibility, not a claim about a particular deployed API.

A credential is evidence for a decision

Consider an agent allowed to inspect product availability but not place orders. A valid identity credential can establish who is asking; the merchant still needs to decide whether the requested operation is within scope. A signed statement does not automatically enforce an amount limit inside a separate payment system.

Our recommended integration keeps identity checks, business authorization and payment checks as separate recorded decisions. Where a credential includes an authorization claim, the relying application must map it to the operation it is actually about to perform. Broad labels such as “commerce agent” are not specific enough to justify changing account details or initiating a payment.

Continuous checks need explicit failure behavior

APASS’s positioning includes continuing verification and risk handling. For an operator, the difficult case is what happens when a previously accepted instance changes, a credential expires or a verification dependency is temporarily unavailable.

Define the response before rollout. A read-only product query may tolerate different evidence freshness from a payout instruction. High-impact actions should not become silently available because a verifier timed out. Conversely, a temporary verification failure should not erase already completed orders or mislabel legitimate users as fraudulent.

Decision boundary	Evidence to request during evaluation
Agent registration	What is bound to the agent identity and who can update it?
Runtime change	Which changes invalidate or require renewed evidence?
Credential presentation	How are recipient, freshness and replay risks handled?
Revocation	How quickly does a relying application learn and enforce it?
Audit trail	Can the decision be reconstructed without excessive personal data?

These are procurement and engineering questions, not claims that the public overview answers every one. Ask for the applicable technical documentation and access conditions before relying on a control in production.

Keep evidence useful without collecting everything

A merchant’s audit record should show the evidence version, relevant claims, policy decision and resulting operation. Copying entire identity documents or sensitive runtime data into general application logs may create unnecessary exposure. Decide what the support team needs to explain a refusal and what must remain in a more restricted system.

This is especially important when several parties participate. An issuer’s statement, a verifier’s result and a merchant’s business decision should remain attributable to their respective sources. A single “trusted” flag hides who made which judgment.

APASS is not ACT or a payment rail

ACT is the broader open agent-commerce framework; APASS is an identity and trust infrastructure offering in this ecosystem. Alipay Agent Pay concerns an authorized payment experience. Identity, framework and payment product belong in separate directory entries because they solve different parts of the system.

Use APASS when assessing how an agent interaction can carry accountable identity and runtime evidence. Use the APASS reference for official access points, and require an operation-level enforcement design before interpreting identity verification as permission to spend.