Security

Credentials

• A seller's credential is encrypted at rest with AES-256-GCM before it touches the database.
• It is decrypted in memory, for the duration of one job, and is not written back out in plaintext.
• It is never rendered in the interface, never returned by an API, and never logged — not to a buyer, not to an operator, not to a support view.
• A credential that a provider rejects is marked and taken out of rotation rather than retried into a lockout.
• Revoking access at the provider, or disconnecting the seat here, ends its use immediately.

Request handling

• The content of routed requests and responses is not persisted. A job row keeps a label, token counts, model and cost.
• Response headers describing the serving account are stripped before the response reaches a buyer, so a seller's rate-limit state cannot leak to the other side.
• Neither side of a trade learns the identity of the other, by construction rather than by policy.
• Agent jobs run in isolated cloud workspaces with their own filesystem, so one buyer's work cannot reach another's.

Accounts and access

• API tokens are shown once, stored hashed, scoped to one account, and individually revocable.
• Administrative routes are enforced on the server by role, not hidden in the interface.
• Money movement is recorded in a balancing ledger, and every operator action — a price change, a ban, a payout review, even viewing a payout destination — is journalled to an audit log the database itself refuses to update or delete, with who, when, from where and before/after values.
• Sign-ins (including failed attempts), password changes and credential lifecycle events are journalled; a ledger-vs-wallet reconciliation runs hourly and alerts operators on any drift.
• Earnings are held before payout, which is the window in which a mis-metered or fraudulent job can still be reversed.

Reporting a vulnerability

Write to security@shaidle.com. Include enough detail to reproduce, and please give us a reasonable window before disclosing publicly. We will acknowledge quickly, tell you what we found, tell you when it is fixed, and credit you if you want to be credited.

• In scope: this site, the exchange API, the CLI, the workspace runtime, and anything that could expose a credential, a balance, or another user's data.
• Out of scope: findings in a provider's own service, social engineering of our staff or users, denial of service, and automated scanner output with no demonstrated impact.
• Please do not access, modify or delete data belonging to anyone else while testing. If you reach real user data, stop and tell us.
• We will not pursue legal action against anyone acting in good faith under this policy.

What is not built yet

• In build
  Execution inside the seller's own workspaceMoves the credential out of central custody entirely.
• Planned
  Independent penetration test, summary publishedFindings and fixes, not a badge.
• Planned
  Public uptime and incident historyTracked on the status page.

Related: Privacy Policy · Compliance position · Status