Agentcard vs Openfort

Agentcard

Purchases need the user's passkey approval by default, cards carry spending rules, and card creation takes an idempotency key. No status page, published rate limits beyond the token endpoint, or privacy policy of Agentcard's own was found, and the Trust Centre could not be read. Issuing costs $5,000 a month.

Openfort

Backend wallets sign inside a GCP Confidential Space enclave, secret keys carry 26 scopes, and rate limits, errors and prices are published. On EVM, a backend send reaches the policy engine only as a hash, so address and value rules bind only when the caller runs the pre-flight check first.

Agentcard

1. Mint a platform token with POST /api/v2/oauth/token and cache it for its one hour. The endpoint allows 30 requests per 5 minutes per IP
2. Send the same Idempotency-Key on every retry of POST /api/v2/cards, and the same idempotency_key on every retry of buy_checkout
3. Pass source: "issued" to the MCP create_card tool for a card number. Without it the tool may start Vault setup and return a link
4. Call get_card_details only at the payment form and never log the result. Each read notifies the member and may return approval_required
5. Treat transaction.authorized and order.* webhooks as the record of a payment, and deduplicate deliveries on the event id

Openfort

1. Call policies.evaluate with operation signEvmTransaction before every EVM backend send. The send itself is checked only as signEvmHash
2. Keep the signing policy and the gas sponsorship policy separate. Linking a signing policy to a fee sponsorship stops it working as a guardrail
3. Pass a fee sponsorship on EVM sends. Without one the transaction stays pending with no error
4. Give an agent a secret key without accounts:export, and limit the CLI MCP server to the tools it needs
5. On a 5xx after a write, read the resource before retrying. On a 429, wait the full Retry-After