Docs/Understanding P402/Security Model

>_ DOCS / UNDERSTANDING P402

SECURITY
MODEL.

How P402 protects your funds, API keys, and agent spending at every layer — from cryptographic signatures to real-time anomaly detection.

Payment Security (EIP-3009)

P402 uses EIP-3009 TransferWithAuthorization for on-chain settlement. This removes the standard ERC-20 two-step (approve → transferFrom) and replaces it with a single off-chain signature that the P402 Facilitator submits on-chain.

Replay protection

Every authorization contains a 32-byte nonce. P402 records used nonces in both PostgreSQL and Redis. Any attempt to resubmit the same nonce returns REPLAY_DETECTED immediately — before any on-chain call is made.

Time-bounded authorization

validBefore and validAfter timestamps bound the authorization to a 1-hour window by default. After validBefore passes, the authorization is rejected even if it was never used.

Amount enforcement

The value field in the authorization must match paymentRequirements.maxAmountRequired exactly. Any discrepancy returns AMOUNT_MISMATCH before on-chain execution.

EIP-712 typed data signing

Signatures are bound to the USDC contract address on Base (domain separator). A signature valid on Base cannot be replayed on any other chain or contract.

Gas price safety

The Facilitator checks Base gas price before every settlement. If gas exceeds 50 gwei (configurable), the settlement is rejected with GAS_PRICE_TOO_HIGH. This prevents economic attacks during gas spikes.

API Key Security

SHA-256 hashing

Raw API keys (p402_live_...) are shown once at creation and immediately discarded. Only the SHA-256 hash is stored in the database. Even if the database were compromised, raw keys cannot be recovered.

Constant-time comparison

Key verification uses a constant-time comparison (timingSafeEqual) to prevent timing attacks. A slow comparison loop would leak information about how many characters match.

Prefix for quick identification

Keys are prefixed p402_live_ (production) or p402_test_ (test mode). This lets you grep logs for accidental key exposure without the key being usable.

Immediate revocation

Revoked keys are rejected in < 2ms. The revocation propagates to all API gateway nodes via Redis pub/sub — no propagation delay.

Billing Guard

Six independent layers protect against runaway spend. All layers fail closed — when a layer trips, the request is rejected rather than allowed through.

Layer
Protection
1
Rate limitPrevents request floods. Sliding window per API key.
2
Daily circuit breakerHard daily spend cap. Resets 00:00 UTC.
3
Concurrency capLimits simultaneous in-flight requests per tenant.
4
Anomaly detectionGemini Sentinel pauses traffic on 10× spend spike.
5
Per-request capRejects single requests above a cost ceiling.
6
Atomic budget reservationBudget reserved before LLM call. Never overspend a session.

Threat Model

Threat
Mitigation
Stolen API key used by attacker
Immediate revocation via dashboard. Daily spend cap limits blast radius. Anomaly detection alerts on unusual patterns.
Prompt-injection attack causes agent to make excessive LLM calls
Session budget cap, daily circuit breaker, and Sentinel anomaly detection provide layered defence.
Replay attack: resubmit a signed EIP-3009 authorization
Nonces are stored and checked before on-chain execution. REPLAY_DETECTED returned immediately.
Compromised facilitator wallet private key
Facilitator wallet holds no funds — it only signs USDC transfers from user wallets. No funds at risk from key compromise alone.
Gas price spike drains facilitator budget
50 gwei hard ceiling on settlement. Requests rejected above threshold with GAS_PRICE_TOO_HIGH.
Database breach exposes API keys
Only SHA-256 hashes stored. Raw keys cannot be recovered from hashes.
Man-in-the-middle attack on API traffic
TLS 1.3 enforced on all endpoints. HSTS preloaded. EIP-712 signatures are bound to specific contract addresses, making replay impossible even if intercepted.
Concurrent requests race to exhaust session budget
Atomic budget reservation using database transactions. Budget never goes negative under concurrent load.

Security disclosures

If you discover a security vulnerability in P402, please report it to security@p402.io. We acknowledge all reports within 24 hours and aim to patch critical vulnerabilities within 72 hours. We do not pursue legal action against good-faith researchers.