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. The website remains a trust and onboarding surface; production execution happens in the desktop app. 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 InsForge 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 plan status. Email and auth managed by InsForge Auth. Enterprise billing is handled via MSA — STET does not process payment card data.
Box and Dropbox OAuth access tokens are stored encrypted in our InsForge 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. Production inference runs on-device inside the desktop app via the native engine. The public website does not act as a production analyst runtime, and 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.
InsForge
Database, Auth, Storage
All data at rest encrypted with AES-256. In transit via TLS 1.3.
Website Hosting
Marketing Site Hosting
Hosts the public website, docs, and download surfaces. Production analyst work does not execute here.
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.
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 InsForge. OAuth tokens additionally encrypted at the application layer before storage.
Row-Level Security
All database tables enforce InsForge 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 (InsForge 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?
sritej@trystet.com·STET, Inc. · Wilmington, Delaware