Security¶

Audience: Security reviewers, enterprise buyers, procurement · Tags: security, enterprise

This page describes how SnapLink protects your data and credentials. We state our actual posture — we do not claim certifications we don't hold.

Security overview¶

SnapLink runs your automations on a managed platform with a few firm rules: - Backend owns execution truth. Flows run server-side; the UI only requests. - Secrets are encrypted and never exposed. No credential is shown, logged, or returned by the API. - Workspaces are isolated. You can only see resources in workspaces you belong to; cross-workspace access returns not found, by design. - Every action is observable. Each run is recorded; every failure is explainable.

Data handling¶

What we store: your flows, connections (encrypted credentials), and run metadata (status, steps, timing, events).
What we don't store: webhook request bodies, connector request/response bodies, or any secret values. Runs keep sanitized results only.
Deletion: deleting a connection/workspace cascades and destroys its stored secret values.

Credential storage¶

Connector credentials are held behind an opaque reference and resolved only at the moment of a call. With the encrypted secret provider enabled, values are encrypted at rest with AES-256-GCM (key from a configured encryption key); managed-vault storage is supported as a deployment option. Credentials are never logged, displayed, or returned. OAuth tokens are stored the same way and refreshed automatically.

Encryption¶

In transit: HTTPS/TLS to the platform; https/amqps/rediss between managed services in production deployments.
At rest: encrypted secret storage (above); the primary datastore supports encryption at rest per deployment.

Network safety (SSRF)¶

Outbound calls (e.g. the REST connector) are guarded against server-side request forgery: requests to private, loopback, link-local, and cloud-metadata addresses are blocked, and redirects are re-validated. Use public https destinations; a blocked target returns the blocked error.

Tenant isolation¶

Each workspace is an isolated tenant. Membership is enforced on every request; one workspace's flows, connections, and runs are never visible to another. This is verified by automated tests as part of every release.

Audit logging¶

Connector and execution events are recorded append-only (who/what/when, with identifiers — never secrets), supporting audit and incident review. Customer-facing audit-log access and export are being expanded (see Administration).

Compliance¶

SnapLink is in Early Access. We make no formal compliance certification claims (e.g. SOC 2, ISO 27001, HIPAA) at this time — we won't say we hold a certification we don't. Our security practices (encryption, isolation, least privilege, no-secret-logging, SSRF protection) are designed to support a future attestation. If you have specific procurement requirements, contact us and we'll share current status honestly.

Responsible disclosure¶

Found a vulnerability? Please report it privately to the SnapLink security contact (see your account/support channel) with steps to reproduce. Don't access other tenants' data or run disruptive tests. We'll acknowledge, investigate, and keep you updated. We appreciate good-faith research and will credit reporters who wish it.

Was this helpful? 👍 👎