Security at STET
Last updated: February 24, 2026
The Core Principle
Your documents never move. STET reconciles files by processing metadata and cryptographic hashes — not content. Your actual deal documents stay exactly where they already live: in Box, Dropbox, or on your local disk.
STET does not ingest, copy, store, or transmit document contents to any STET-controlled server. What we store is limited to: file names, sizes, hashes, reconciliation results, and your account data.
What Goes Where
A precise map of every category of data STET handles and where it lives.
PDF, Excel, Word files, and all other VDR documents are accessed via Box or Dropbox APIs using your OAuth credentials, or read directly from your local disk by the desktop app. STET reads metadata and computes hashes locally. Raw file bytes are never uploaded to STET servers.
SHA-256 hashes, file names, file sizes, and modification timestamps are stored as part of your audit record in our Supabase database. These are one-way hashes — they cannot be used to reconstruct document contents.
Match/discrepancy summaries, confidence scores, and audit logs are stored in your account. These results describe the relationship between files — not their contents. You own this data and can export or delete it at any time.
Your email address, name, organization name, team member list, and billing information. Email and auth managed by Supabase Auth. Billing processed by Stripe — STET never sees or stores raw card data.
Box and Dropbox OAuth access tokens are stored encrypted in our Supabase database (AES-256 at rest). They are used exclusively to fetch file listings and metadata on your behalf. You can revoke them at any time from your Box/Dropbox settings.
Semantic matching uses the all-MiniLM-L6-v2 model. In the web app, the model runs entirely in your browser via WebAssembly — no data leaves your machine for inference. In the desktop app, inference runs natively via the Rust engine. No document text is sent to any external AI API.
Infrastructure & Certifications
STET is built on infrastructure that maintains its own SOC 2 Type II certifications. We inherit their security posture for the layers they control.
Supabase
Database, Auth, Storage
All data at rest encrypted with AES-256. In transit via TLS 1.3.
Vercel
Web Application Hosting
Edge network with automatic HTTPS. No long-lived server processes.
Box
VDR Storage (customer's own account)
STET accesses Box only via OAuth with scopes you authorize. Documents stay in your Box account.
Dropbox Business
VDR Storage (customer's own account)
Same model as Box. OAuth-only access. Files never copied to STET.
Stripe
Payment Processing
STET never handles raw card data. Stripe manages all payment credentials.
Resend
Transactional Email
Used only for invite and notification emails. No document data transmitted.
Security Controls
Encryption in Transit
All connections use TLS 1.2+. The desktop app enforces HTTPS for all API calls. Local file operations (desktop only) stay on-device with no network transmission.
Encryption at Rest
Database encrypted with AES-256 via Supabase. OAuth tokens additionally encrypted at the application layer before storage.
Row-Level Security
All database tables enforce Supabase Row-Level Security (RLS). Users can only access data belonging to their own organization.
Rate Limiting
All API endpoints are rate-limited by IP and user. Authentication endpoints use stricter limits to prevent brute-force attacks.
No Model Training
Your data is never used to train, fine-tune, or evaluate any machine learning model — by STET or any third party. The semantic model is pre-trained and frozen.
Desktop App Isolation
The Tauri desktop app runs in a sandboxed WebView with a strict Content Security Policy. File system access is limited to directories you explicitly select via the system file picker.
Dependency Management
Dependencies are pinned and reviewed. The Rust backend has no network access beyond explicitly declared Tauri capabilities.
Access & Authentication
Authentication
- ·Email/password with bcrypt hashing (Supabase Auth)
- ·SSO / SAML 2.0 for enterprise plans
- ·JWT session tokens with short expiry
- ·PKCE flow for all OAuth connections
- ·Secure password reset via one-time tokens
Authorization
- ·Organization-scoped data isolation
- ·Role-based access: Admin, Member
- ·Invite-only team membership
- ·VDR credentials scoped to connecting user
- ·All actions server-validated — no client-side auth bypasses
Responsible Disclosure
If you discover a security vulnerability in STET, please report it to us privately before public disclosure. We commit to responding within 48 hours, keeping you informed, and crediting researchers who follow responsible disclosure.
Please encrypt sensitive reports using our PGP key, available on request.
Shared Responsibility Model
A detailed breakdown of what STET is responsible for versus what your organization is responsible for — and what your cloud storage providers handle.
Security questions or concerns?
security@trystet.com·STET, Inc. · Wilmington, Delaware