01
Encrypted connected credentials
ToastTi is designed so marketplace credentials and provider tokens are stored through encrypted connected-account paths and not exposed in browser UI, public pages, logs, or support copy.
02
App-level provider config vs seller credentials
Provider app configuration may live in environment configuration, while seller account credentials should come from connected accounts. Public pages should not display either secret value.
03
Least-privilege readiness
ToastTi workflows are built around scoped permissions, organization membership, role checks, provider capability checks, and action-specific readiness rather than blanket access.
04
Audit logs
Marketplace connects, exports, account deletion requests, authentication events, operator tasks, inventory changes, approvals, and provider write events use server-created audit entries with redacted metadata. Application users receive read-only access to authorized audit history; mutation is reserved for trusted server code.
05
Browser and session controls
Production responses use CSP, HSTS, frame blocking, referrer, permissions, and content-type controls. Signed-in pages and exports use private no-store caching. Sessions have role-aware idle and absolute lifetimes, and expired sessions return users to sign-in with a clear reauthentication message.
06
Requests, redirects, and OAuth
State-changing API requests enforce same-origin checks. Login and password reset paths are rate limited in the application in addition to provider controls. Redirect destinations are restricted to local application paths, authentication uses PKCE, and marketplace OAuth callbacks verify signed state before accepting a code.
07
Tenant, export, and file boundaries
Workspace access is resolved from the authenticated user and active organization membership. Exports require owner or administrator authorization plus a recent-session check. Current CSV imports enforce file extension, type, content, and 2 MB size limits; support file attachments are not enabled.
08
Kill switch
Live-write safety depends on a kill-switch model that can block provider actions when execution should stop globally or for a target workflow.
09
Unsupported writes disabled
Actions outside the supported provider/action matrix remain blocked, including eBay/TikTok writes, provider-impossible order mutations, irreversible permanent deletion, unproved consequential Alias order transitions, and broad public rollout.
10
Permanent delete disabled
Permanent destructive actions are treated separately from operational archive, deactivate, status, inventory, or rollback workflows and should stay disabled unless explicitly proven and approved.
11
Readback, rollback, and idempotency
Verified Automatic Actions require exact targets, before-state capture, duplicate blocking, idempotency keys, provider readback, and rollback, restore, or deactivate paths where safety depends on them.
12
No formal certification claim
ToastTi does not use this beta security page to claim a completed external security certification, audit report, or regulated-industry compliance status.
13
Security contact path
Security questions or suspected issues should start through the Contact page or signed-in support path. Reports should avoid including sensitive credentials, provider records, or customer-sensitive data.
14
Implementation detail boundary
This page explains security posture at a product level. It intentionally avoids exposing internal schemas, provider identifiers, credentials, runtime error details, or detailed defensive implementation internals.