Current security posture
AgentPay is not yet production-ready. The Lean V1 application has been verified locally, while AWS runtime deployment and deployed release verification remain incomplete. Current payment support is limited to mock and x402 testnet operation.
The controls below describe the implemented local product boundary and deployed infrastructure foundations. They are not a certification, warranty, penetration-test result, or substitute for an external application and infrastructure security review.
Transaction integrity
Purchase intents are immutable after creation. AgentPay freezes the seller quote, treats the buyer maximum as a ceiling, and checks the exact amount, asset, network, destination, request, and resource before fulfillment.
- Unique payment identifiers and conditional writes protect against proof replay.
- Only finalized payments can enter the exactly-once seller-forwarding claim.
- A model recommendation never authorizes a purchase or bypasses domain validation.
- Browser and software-agent purchases share the same authoritative commerce rules.
Funds, wallets, and secrets
AgentPay does not custody buyer funds or seller revenue. Sellers prove control of a public payment destination, while AgentPay never requests or stores wallet private keys or seed phrases.
Raw payment proofs, ownership signatures, authorization headers, cookies, confirmation grants, execution capabilities, and seller secrets are excluded from evidence and logs. Where verification requires persistence, AgentPay stores bounded hashes, references, and allowlisted metadata instead.
Seller and coding-agent access
Seller-hosted code and repository content start untrusted. Project credentials are seller-scoped bootstrap credentials for the required local connector; ordinary cloud MCP requests use short-lived, scoped capabilities and recheck credential and entitlement state.
Commercial MCP mutations require a separate one-time confirmation grant created through the authenticated seller boundary and bound to the exact tool, target, arguments, resource version, credential, seller, and expiry. A coding agent cannot confirm its own proposal.
Seller endpoint protection
Seller endpoints and webhook destinations are restricted to public HTTPS targets. The service is designed to reject private, loopback, link-local, metadata, redirect, IPv6, and DNS-rebinding SSRF paths and to enforce request, response, and timeout limits.
Production seller fulfillment uses a short-lived cloud-signed execution capability bound to one finalized transaction, seller, route, method, path, and request-body hash. Seller middleware verifies the capability and uses the transaction identifier as its fulfillment idempotency key.
Evidence and auditability
Transaction evidence is append-only, hash-chained, and signed. Evidence payloads contain allowlisted facts and hashes rather than raw payment credentials or unrestricted seller responses.
The Mumbai development infrastructure includes a versioned, encrypted Object Lock evidence bucket and non-exportable asymmetric signing keys. Production backup, restore, retention, deletion, and disaster-recovery procedures still require completion and review.
Required before real funds
Real-money processing must remain disabled until the production runtime and release gates pass and the unresolved security obligations are completed.
- External application and infrastructure security review, including tenant-isolation testing.
- Incident-response, key-compromise, backup, restore, and disaster-recovery exercises.
- Dependency, container, and infrastructure-as-code scanning in continuous integration.
- A documented x402 facilitator service level and failure model.
- External legal review covering payment role, refunds, sanctions, privacy, and retention.
Security reporting
A dedicated security reporting address and coordinated disclosure process have not yet been published. Do not include credentials, wallet material, payment proofs, or personal data in an unsolicited report.
The production service must publish an authenticated reporting channel and response process before handling real funds. Until then, review the public technical documentation for the current architecture and limitations.