# Security and Privacy Considerations

## Security Considerations

Agentic commerce introduces numerous potential security risks. Given the current
state of agent security, AP2 assumes that preventing prompt injection attacks
is infeasible. Therefore, all LLMs and Agents MUST be considered potential
attackers and are explicitly included in the threat model.

### Manipulated Checkout

**Threat:**

- An attacker steals a signed and authorized Payment Mandate to use it with an
  unrelated Checkout.

**Mitigation**

- The Payment Mandate MUST contain a reference to its associated Checkout.
- This is via `transaction_id` for closed Payment Mandates and the 
 `mandate.payment.reference` constraint for open ones.

**Threat:**

- An attacker reuses an open Payment Mandate with a different closed Payment
  Mandate.
- An attacker reuses an open Payment Mandate to approve a different closed
  Checkout Mandate.

**Mitigation**

- Closed Mandates MUST contain the `sd_hash` claim to bind them to the
  presented open Mandate.
- Open Mandates MUST contain the Agent's key (via a `cnf` claim) so that
  only the agent could create a Closed Mandate with a valid signature.

**Threat:**

- An attacker mismatches a closed Mandate with a different open Mandate.

**Mitigation**

- Closed Mandates MUST contain the `sd_hash` claim to bind them to the
  presented open Mandate.

**Threat:**

- An attacker uses a closed Checkout Mandate with a different checkout session.

**Mittigation**

- Merchant MUST verify that `checkout_hash` matches the hash of the
  latest `checkout_jwt`.

### Manipulated Payment

**Threat:**

- A Shopping or Credential Provider Agent manipulates the Payment in transit,
  or requests payment without (or differing from) the User's approved Mandate.
  This causes the Credential Provider to execute a Payment not approved by the
  Trusted Surface.

**Mitigation:**

- The Merchant Payment Processor and Credential Provider MUST verify the User's
  signature on the Payment Mandate to ensure its integrity.
- The `checkout_hash` embedded in the `transaction_id` securely links the
  payment to the associated Checkout Mandate.
- Constraint evaluation ensures the payment amounts and payees comply with the
  authorized limits.

### Payment Credential Theft

**Threat:**

- An attacker steals the User's Payment Credential or Token after its release
  to perform a payment in an unauthorized context.

**Mitigation:**

- The Payment Credential/Token MUST ONLY be released to the Merchant upon the
  receipt and verification of a final Payment Mandate. This binds the token to
  the specific transaction.

### Manipulated Discovery

**Threat:**

- Prompt injection causes the Shopping Agent to select malicious products or
  make poor purchase decisions.

**Mitigation:**

- The Merchant signature ensures the integrity of the offering.
- Even if the LLM fails to make the optimal choice, constraint enforcement
  during closed Mandate verification ensures that the worst-case financial and
  logical impacts are strictly bounded.

### Double Spend

**Threat:**

- A prompt injected, or otherwise malicious Shopping Agent attempts to approve
  multiple valid Checkouts using the same open Mandate.

**Mitigation:**

- The non-deterministic portion of the Shopping Agent MUST avoid signing
  multiple, overlapping closed Mandates for the same open Mandate without
  receiving Receipts rejecting the previously released Mandates.
  - These Receipts MUST be integrity protected from the Shopping Agent's LLM.
- Credential Provider, Networks or MPPs MAY reject multiple overlapping
 Mandates, or invalidate previously issued payment tokens.

## Privacy Considerations

### Open Checkout and Payment Mandate Constraints

Open Checkout and Payment Mandate Constraints MAY contain information that is
not applicable to the particular Checkout that would leak unnecessary user
intent. Selective Disclosure MUST be used to preserve user privacy.

To enhance user privacy the Trusted Surface MAY insert decoy digests as
 described in RFC9901 Section 4.2.5.

### Checkout and Payment Data Minimization

To preserve user privacy and the principle of data minimization, Selective
Disclosure is used to allow the Checkout Mandate and Payment Mandate to be
shared with the relevant parties for securing the Checkout and Payment
respectively. The `checkout_hash` links these Mandates allowing them to be
joined in the case of a Dispute.

> Note: The information contained within the Mandates, or the Mandates
> themselves could be shared with other parties if appropriate agreements or
> channels exist, but that is outside the scope of AP2.

### Rainbow Table Attacks

Digests in SD-JWTs (for Payment and Checkout Mandates as well as Constraints)
MUST include a salt with sufficient entropy to prevent guessing the plaintext.
See RFC9901 Section 9.1. For more details.

The `checkout_hash` makes use of the entropy already included in the JWT
signature to prevent guessing the Checkout contents. If a signing algorithm
(e.g. deterministic signature scheme such as `Ed25519`) is used that does not
include this then a salt of sufficient entropy MUST be present in the Checkout.
