orcaqubits/ap2-risk-signals

AP2 Risk Signals Framework

Before writing code

Fetch live docs:

1. Fetch https://ap2-protocol.org/specification/ for risk payload specification
2. Fetch https://ap2-protocol.org/topics/privacy-and-security/ for risk considerations
3. Web-search ap2 protocol risk signals fraud agentic payments for risk framework details
4. Web-search site:github.com google-agentic-commerce AP2 risk for implementation references

Conceptual Architecture

Why Risk Signals Matter

Agentic commerce introduces novel risk dimensions that traditional payment systems weren't designed for. AP2's risk signals framework provides a common language for all ecosystem participants to assess transaction risk.

Novel Agentic Risk Factors (from the official AP2 risk factor table)

| Risk Factor | Description | |------------|-------------| | User asynchronicity | User may not be present during the entire transaction journey | | Delegated trust | Agents initiate transactions on behalf of users | | Mandate-merchant matching | Verifying the purchase matches the authorized intent | | Temporal gaps | Time between token generation and payment execution | | Indirect trust establishment | CP and Merchant may not have a direct trust relationship | | Agent identity verification | Verifying the agent is who it claims to be |

Additional AI-Specific Risks (not from the official AP2 risk factor table)

The following are additional AI-specific risk considerations relevant to agentic commerce implementations, but they are not part of the official AP2 specification's novel risk factor table:

| Risk Factor | Description | |------------|-------------| | Agent hallucination | AI agent may misinterpret user intent | | Prompt injection | Malicious inputs that manipulate agent behavior |

Risk Payload

The risk payload is an open-ended field structure in V0.1:

• Intentionally flexible for industry-specific risk signals
• Allows Credentials Providers, Merchants, and Networks to pass custom risk data
• Each actor contributes their own risk assessment signals
• The payload travels with the mandate through the transaction flow

Risk Assessment by Role

Shopping Agent

• Quality of intent capture (how clearly the user expressed their intent)
• Session authentication strength
• User behavioral signals

Credentials Provider

• Payment method risk level
• User account history
• Device trust score
• Previous transaction patterns

Merchant

• Order anomaly detection
• Intent-to-cart matching confidence
• Fulfillment risk assessment

Network/Issuer

• Card risk signals (fraud patterns, velocity checks)
• 3DS challenge decisions
• Authorization risk scoring
• AI involvement context (from Payment Mandate)

Trust Establishment

AP2 defines trust establishment phases:

Short-term (V0.1):

• Manually curated allowlists per entity
• Known partner relationships
• Pre-configured trust

Long-term (future):

• Real-time trust via HTTPS certificate validation
• DNS ownership verification
• mTLS (mutual TLS) for strong identity
• API key exchange
• Identity assertions in A2A/MCP protocols
• Agent reputation systems

Dispute Risk Assessment

For dispute resolution, risk signals help determine accountability:

• Strong user authentication → lower risk of ATO (account takeover)
• Clear Intent Mandate → lower risk of agent mispick
• Valid merchant signature → merchant committed to terms
• Matching mandate vs delivery → no fulfillment fraud

Best Practices

• Include as many risk signals as available — more data helps better assessment
• Don't rely solely on LLM output for risk signals — use deterministic checks
• Validate agent identity cryptographically, not just by self-declaration
• Monitor for prompt injection in shopping intent
• Track temporal gaps between intent capture and payment
• Build risk scoring models specific to agentic transactions
• Log all risk signals for post-transaction analysis
• Implement anomaly detection for unusual agent behavior patterns
• Update risk models as agentic commerce patterns emerge

Fetch the specification for exact risk payload structure, supported signal types, and risk assessment requirements before implementing.