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. To keep credentials you paste into a prompt out of that provider's request logs, see Secret Masking below.

Secret Masking (Beta)

Secret masking is an optional extra layer for prompts that may contain credentials. With it on, SI replaces the API keys, private keys, seed phrases, passwords and tokens in a request with placeholders such as SI_SECRET_APIKEY_K7M2Q9XA before the request is routed, so the seller's provider never receives the values, and puts every value back in the reply before it reaches you - everywhere but the model's reasoning. The values are never stored or logged.

It is off by default for every account and every key. Turn it on for one request with the X-SI-Mask-Secrets: on header, for a key with its Mask secrets switch, or for the whole account with Secret masking on Buy › Routing. It covers the text endpoints; embeddings and media are sent as they are, marked x-si-secret-masking: not_applied.

Putting every value back trusts the seller's model with where a value goes:

• a command or tool call that sends a placeholder to the seller's own server gets the real value if your agent runs it;
• a link or image carrying a placeholder sends the real value to its host when your client renders or previews it;
• a password repeated on a later turn without the context that identified it goes to the seller unmasked.

Read the secret masking guide for how it works, how to turn each switch on and off, what is detected and what comes back, the response headers, every refusal code and the known limits.

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.

Charge Failure and Retry Economics

For API-key requests, SI checks your balance before routing, then charges after the provider response because the final cost depends on actual usage. If that post-response charge fails it is queued and retried 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 or hard guarantee that the seller is paid after a permanently failed charge. Manual reconciliation may be required.

For x402, the buyer payment is verified and captured up front, then SI pays the selected seller. If that operator-to-seller transfer fails after the buyer payment succeeded, the operator carries the reconciliation obligation - the seller payout is only final once the seller transfer succeeds.