Syntharil is built to the practices behind SOC 2 and industry security standards, following Salesforce’s own recommended integration model. Your Salesforce data is encrypted, isolated per job, and confined to boundaries you control — and you can revoke access at any time.
Syntharil connects through a Salesforce Connected App using the `api` scope — not `full`. You grant access explicitly, it operates within your org’s permission and field-level-security model, and you can revoke it at any time from Salesforce.
We follow Salesforce’s own recommended integration-security model: OAuth 2.0 with no stored passwords, least-privilege scopes, and stable egress addresses you can add to your Login IP Ranges and Network Access allowlist.
OAuth tokens are encrypted at rest with AES-256-GCM, decrypted only in memory for the duration of a job, and never written to logs or shown in the UI.
Every job runs in its own ephemeral container that is destroyed when the job finishes. Workers have no access to the application database or shared state — a job sees only what it needs.
Each job’s network access is restricted to an allowlist computed for that specific run: your Salesforce org and the storage destination you configured, and nothing else. A job cannot reach arbitrary hosts on the internet.
All traffic is TLS-encrypted in transit, and job telemetry is authenticated with HMAC signatures so the control plane only accepts messages from the job it launched.
Archived records are encrypted with a per-tenant data key, itself wrapped by a master key — so one tenant’s archives can never be read with another tenant’s key.
You authorize Syntharil through a Salesforce Connected App with least-privilege `api` scope. No password is ever stored; the connection is revocable from Salesforce at any time.
Each job launches in its own ephemeral container with no database or shared-state access, and is destroyed on completion.
The job’s egress is restricted to a per-run allowlist — your Salesforce org and your configured storage destination — so data cannot be sent anywhere else.
Data is TLS-encrypted in transit and, where stored, encrypted at rest: OAuth tokens with AES-256-GCM and archives with per-tenant keys.
You can revoke Syntharil’s access from Salesforce whenever you choose, immediately cutting off further access.
For the legal detail, see our Privacy Policy → and Terms →. For how access and encryption work in practice, see the documentation →.
Syntharil connects through a Salesforce Connected App using the `api` OAuth scope — not `full`. It acts within the permissions and field-level security of the connecting user, following Salesforce’s recommended integration-security model.
Only where a job requires it. Jobs run in isolated containers whose network access is restricted to a per-run allowlist — your org and the storage destination you configured. A job cannot send data to arbitrary hosts.
Yes. All traffic is TLS-encrypted in transit. At rest, OAuth tokens are encrypted with AES-256-GCM and archived records are encrypted with per-tenant keys.
Yes, at any time, directly from Salesforce — revoking the Connected App connection immediately cuts off further access. No password is ever stored.
Syntharil uses passwordless sign-in: a magic link by email, or sign in with Google — which can use your organization’s passkeys and 2FA on your Google account.
Syntharil is built to the practices behind SOC 2 and industry security standards — least-privilege access, encryption in transit and at rest, per-job isolation, and bounded egress — and we are committed to formalizing that posture as we grow. A detailed technical whitepaper is available on request under NDA.
Syntharil stores only what a feature you use requires — your encrypted connection credentials and any archives you explicitly create — and you control deletion of that data. Job data flows through isolated, ephemeral containers that are destroyed on completion.
We provide a detailed technical security whitepaper on request, available under NDA. Request the whitepaper →