You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(types): integrate risk_payload into mandates and add CREDENTIAL_CHECK condition
Incorporates two contributions from @ayushozha's work on PR google-agentic-commerce#187 and
their analysis on Issue google-agentic-commerce#163:
1. Wire risk_payload as an optional field into IntentMandate, CartMandate,
and PaymentMandateContents, so risk signals travel with the mandate chain
rather than as a separate DataPart. This closes the spec-implementation
gap identified in Section 7.4 (lines 298-299, 321-322).
2. Add CREDENTIAL_CHECK as a new TripConditionType for static identity
verification (e.g., on-chain wallet attestations, KYB credentials).
This addresses the Section 7.4 gap between behavioral risk (what the
agent does) and identity risk (what the agent is).
Includes Python tests, Go type updates, and documentation for both changes.
Refs: google-agentic-commerce#163, google-agentic-commerce#187
Co-Authored-By: ayushozha <7945279+ayushozha@users.noreply.github.com>
AP2 Section 7.4 identifies two complementary dimensions of risk in agent transactions:
106
+
107
+
### Behavioral Risk (Runtime)
108
+
109
+
Most trip conditions (`VALUE_THRESHOLD`, `VELOCITY`, `ANOMALY`, etc.) evaluate **what the agent does** — its runtime behavior against predefined thresholds. These are dynamic checks that may change with every transaction.
110
+
111
+
### Identity Risk (Static)
112
+
113
+
The `CREDENTIAL_CHECK` trip condition evaluates **what the agent is** — its identity, credentials, and trust signals. This addresses the spec's call-out that "the Shopping Agent's ID becomes synonymous with a bot's identity, which requires new methods of verification and trust."
114
+
115
+
Examples of credential checks:
116
+
117
+
- Agent wallet holds governance tokens from a recognized DAO
118
+
- Agent has a KYB (Know Your Business) attestation via [EAS](https://attest.org/) on Base
119
+
- Agent presents a W3C Verifiable Credential from a trusted issuer
120
+
- Agent identity is registered in a trust registry
121
+
122
+
Credential check results use the standard `TripConditionResult` structure. The `message` field carries human-readable verification details, while implementation-specific data (attestation UIDs, chain references, credential schemas) should flow through `RiskPayload.custom_signals` to keep the core types ecosystem-agnostic.
123
+
124
+
!!! note
125
+
126
+
Future versions may separate identity evaluation into its own dimension within `RiskPayload` (e.g., `identity_evaluation`) to provide richer type support for credential data shapes that differ from behavioral thresholds.
- Confidence that agents operate within guardrails
280
306
- Human oversight for exceptional cases
281
307
308
+
## Risk Payload in Mandates
309
+
310
+
As of v0.1-alpha, `RiskPayload` can be included directly on `IntentMandate`, `CartMandate`, and `PaymentMandateContents` via the optional `risk_payload` field. This allows risk signals to travel with the mandate chain, giving networks and issuers structured visibility into the agent's governance state at mandate-signing time.
311
+
312
+
The `risk_payload` field is fully optional — mandates without it remain valid, ensuring backward compatibility.
0 commit comments