Security & Privacy

This page states the current production behavior and the current trust assumptions. It intentionally avoids future-tense claims unless a feature exists today.

Seller API Key Storage

Seller provider API keys are encrypted before they are stored. The ciphertext lives in a private S3 bucket; offer metadata lives in DynamoDB.

Current implementation:

  • Algorithm: AES-256-GCM under AWS KMS envelope encryption.
  • For each secret the server asks KMS for a fresh 256-bit data key (GenerateDataKey, AES_256), encrypts the plaintext with it, and stores the ciphertext together with the KMS-encrypted data key and a random 12-byte IV as a single envelope object in S3.
  • The plaintext data key exists only in memory during encrypt/decrypt and is never persisted; only its KMS-encrypted form is stored alongside the ciphertext.
  • The server decrypts a seller key only when it needs to call that seller's provider endpoint, run seller discovery/test-connection, or reset/check offer health.

Important trust assumption: decrypting a seller key requires both the S3 ciphertext object and KMS Decrypt permission on the customer master key (CMK). Anyone who holds both could decrypt seller keys; today this is an operator/IAM trust boundary. Sellers should use provider-side scoped keys, spend caps, and revocation wherever their provider supports them.

Offer Deletion and Seller Key Erasure

DELETE /v1/seller/offers/{id} currently soft-deletes an offer by setting active = false and removing it from the in-memory order book. The encrypted provider API key remains in storage for that offer record.

There is not yet a self-serve GDPR-style hard-delete endpoint that physically purges the encrypted key. Until hard deletion ships, the safest way for a seller to invalidate a key is to revoke or delete it at the upstream provider. If you need manual deletion of stored seller-key material, contact the operator and revoke the upstream provider key immediately.

Seller Spend Caps and Compromise Protection

Marketplace seller offers support a cap_daily_usd spend cap, which the router checks before selecting an offer. (Weekly and monthly caps exist only on the separate x402 resource-offer surface, not on marketplace inference offers.)

Current limitations:

  • There is no separate marketplace-side per-hour USD ceiling today.
  • Public seller management endpoints have request-rate limits, but those are API-abuse controls, not a guarantee against a compromised server/operator environment.
  • If the marketplace server and its secrets are compromised, provider-side restrictions are the strongest protection against rapid quota drain.

Recommended seller practice: create a dedicated provider API key for SI, set provider-side spend/rate limits if available, restrict models if the provider supports scopes, and revoke the key at the provider if you disable an SI offer.

Prompt and Response Logging

For synchronous text/chat inference, SI stores usage and settlement metadata, not full prompt/response content.

Stored as usage and settlement records for normal inference:

  • buyer wallet, seller wallet, offer id, model
  • token counts and cost fields
  • settlement status, settlement error snippet, transaction hash
  • timestamps and media/unit metadata where applicable

Not intentionally stored for normal chat/completions:

  • full messages arrays
  • full model responses
  • tool call arguments/results beyond what the upstream provider receives for the active request

Caveats:

  • Upstream providers receive the request payload and may have their own logging/retention policies.
  • Provider error messages are stored in health logs after truncation/sanitization; they are intended for operational debugging, not prompt logging.
  • Async media jobs (video/music) currently store request_json and provider job/result metadata so jobs can be submitted, retried, polled, and deduplicated. Treat media prompts as retained operational data until a retention/purge policy is published.

There is no per-request prompt/response retention opt-out toggle today because normal chat prompt/response bodies are not stored by SI. For commercial/private workloads, also review the upstream seller/provider's policy because SI routes your request to that provider.

Seller Quality and Model Authenticity

Today SI verifies that a seller endpoint is reachable, authenticates, and returns valid responses. It tracks operational health through failures, status codes, backoff, and successful recovery.

What exists today:

  • provider domain allowlist for sellers
  • health/backoff on provider errors and bad keys
  • model-name normalization to provider-specific model ids
  • trusted_provider classification for known provider domains
  • public market stats such as seller count, request volume, and price

What does not exist today:

  • cryptographic proof that a seller served the exact claimed model
  • semantic challenge-based model identity scoring
  • public seller reputation/quality scoring beyond health/liquidity stats
  • automatic detection that a seller is proxying to a cheaper hidden model
Trusted-only routing is the default. New accounts route exclusively to providers on the trusted-domain list; untrusted providers are eligible only when the buyer opts in via the Routing preferences card on /buy (or per-API-key in Key Management). Quality/reputation scoring beyond trust + health is planned but should not be treated as live.

Settlement Admin and Timelock Status

The live SettlementV2 contract is a UUPS proxy with role-based access control:

  • OPERATOR_ROLE can call settle().
  • ADMIN_ROLE can call setFeeMultiplier, setFlatFee, and setFeeRecipient.
  • UPGRADER_ROLE can upgrade the implementation.
  • DEFAULT_ADMIN_ROLE can grant/revoke roles.

Current on-chain economics:

  • feeMultiplier = 10000 (1.0x; no percentage markup)
  • minimum feeMultiplier enforced by the contract is 10000

Current limitation: the contract does not enforce a timelock on fee changes or upgrades. If an address with ADMIN_ROLE changes the fee, that change can take effect in a single transaction. This should be treated as an operator/admin trust assumption until roles are moved behind a multisig and timelock.

Buyers can cap their own exposure by approving a limited USDC allowance and revoking approval at any time.

Settlement Failure and Retry Economics

For API-key marketplace requests, SI checks buyer balance/allowance before routing, then settles after the provider response because final cost depends on actual usage. If that post-response settlement fails, the request is queued in pending_settlements and retried by cron with exponential backoff for up to 5 attempts. If all retries fail, the usage row is marked permanently_failed.

Current limitation: there is no automatic insurance pool, automatic seller reimbursement, or automatic hard guarantee that the seller is paid after a permanently failed API-key settlement. Manual reconciliation may be required.

For x402/MPP payment flows, the buyer payment is verified/captured through the operator payment path first, then SI pays the selected seller from the operator wallet using an operator-mediated USDC transfer. If that operator-to-seller transfer fails after the buyer payment succeeds, the operator has the reconciliation obligation; the seller payout is still only final once the seller transfer succeeds.

See Settlement for the full settlement flow.