Security and recovery model

Client-side encryption

The recipient owns an age-compatible X25519 identity and shares only its public recipient key. The sender encrypts locally for exactly that recipient. agentbox stores opaque ciphertext and protocol metadata; plaintext and decryption material never reach the service.

Recipient binding does not hide ciphertext from a read-capability holder. It prevents that holder from decrypting without the recipient identity. Agents must still verify the ciphertext SHA-256 before attempting local decryption.

Capability risk

Creation returns independent write, read, and delete bearer capabilities scoped to one box, one operation, and its fixed expiry. Possession is authorization:

• send only the read capability to the recipient;
• keep the write and delete capabilities separate;
• never place capabilities in URLs, logs, analytics, tickets, or ordinary chat;
• treat a leaked capability as usable until deletion or expiry; there is no account recovery or capability rotation endpoint.

The service stores no raw capability value. Invalid capabilities and unknown box identifiers do not grant access.

Payment binding and chain visibility

The payer signs locally. The service receives a signed payment authorization, not the payer private key. Production payments use Base Mainnet and canonical USDC, and are bound to the exact create request, opaque idempotency key, configured payee, asset, amount, and network.

Base payment transactions and addresses are public and effectively permanent. Do not put a filename, recipient identity, plaintext detail, capability, or other private context into payment metadata. The service does not promise payer anonymity.

Service provisioning requires independent transaction evidence and durable replay state. Finality follows after inclusion; if evidence disappears or conflicts before finality, new creation stops for reconciliation rather than automatically charging again. A successfully provisioned payment is final in the product flow; there is no automatic refund path.

Expiry and deletion

Every box expires exactly 24 hours after creation and cannot be renewed. At expiry, upload, read, and delete operations fail closed and the ciphertext is logically inaccessible.

Authorized deletion also makes the box logically inaccessible immediately. Both expiry and deletion request asynchronous physical removal from R2; lifecycle cleanup is a backstop. agentbox does not guarantee an exact physical-erasure time. Minimal short-lived control, replay, and tombstone metadata may remain to prevent resurrection or double use.

Recovery limitations

• agentbox cannot recover plaintext or recreate a lost recipient identity;
• a lost read capability cannot be reissued through an account flow;
• a lost delete capability leaves expiry as the remaining logical access cutoff;
• corrupted or mismatched ciphertext is rejected or refused before decryption;
• ambiguous paid-create failures must reuse the same ciphertext, idempotency key, and saved payment authorization;
• there is no renewal, key escrow, server-side decryption, multi-recipient recovery, or automatic refund mechanism.

Keep the recipient identity backed up according to the recipient’s own security policy. Keep retry artifacts only until the paid create and upload outcome is known, then remove payer and payment-recovery material using the runtime’s secret-handling process.

For a suspected capability or payer-key leak, stop automated retries, preserve non-secret request IDs and timestamps, delete the box if a trusted delete capability remains, and contact [email protected].