Vendor security overview
Last updated: June 2026
Security at a glance
- Contact security@atlaswork.ai for DPA or custom questionnaires.
- Legal: ESIGN Act and UETA (US). SES under eIDAS (EU). QES only via QTSP partner when enabled.
- Audit trail: Signed PDF plus separate Signing Record with IP, timestamps, SHA-256 hash, signing order.
- Retention: Signed envelopes kept at least 7 years unless you request earlier deletion where law allows.
- Subprocessors: Supabase, Vercel, Resend, Stripe, Anthropic (optional extract), Extend (field detection).
- Encryption: TLS 1.2+ in transit. AES-256 at rest via cloud provider.
- Webhooks: HMAC-SHA256 in
X-Atlas-Signatureusing your API key on the raw body. - Access: Org admins see all teams. Members see assigned teams only. Connected accounts are isolated.
- AI: Inference only. We do not train models on customer documents.
- Abuse controls: Turnstile at signup, send credits, rate limits, dispatch monitoring.
- Hosting: United States (Supabase and Vercel US regions).
- Contact: security@atlaswork.ai · atlaswork.ai/security
---
Summary for legal, procurement, and security reviewers evaluating Atlas as an e-signature subprocessor.
Electronic signature legal framework
United States
Atlas supports workflows intended to comply with:
- ESIGN Act (15 U.S.C. § 7001 et seq.)
- UETA, adopted in all 50 states
Signers receive a consumer disclosure before signing. Consent, identity (email + name), intent, and record retention are captured in the audit trail.
European Union
Atlas provides Simple Electronic Signatures (SES) under eIDAS by default. Qualified Electronic Signatures (QES) are available only through a QTSP partner integration (legal_framework: eidas_qes), which must be enabled for your organization. If your matter requires QES and you do not have QES enabled, Atlas SES may not suffice.
Cross-border recognition of SES depends on your jurisdiction and document type. Your counsel should confirm SES is sufficient for your use case.
Audit certificate and tamper evidence
When an envelope completes, Atlas stores:
- The executed PDF with field values embedded
- A separate Atlas Signing Record PDF (
GET /api/envelope/{id}/audit-cert)
The signing record includes signer identity, IP address, user agent, UTC timestamps, SHA-256 document hash, and signing order. If the PDF is altered after signing, the hash will not match.
Data retention
- Signed envelopes: retained at least 7 years from completion unless you request earlier deletion and applicable law permits it
- Draft envelopes: retained until voided or deleted by the account holder
- Audit logs (org workspace): org admin audit log entries retained with the workspace
Contact us for a data processing agreement that specifies retention and deletion SLAs for your contract.
Subprocessors
Atlas uses the following subprocessors to deliver the service:
| Subprocessor | Purpose | Data processed |
|---|---|---|
| Supabase | Database, auth, object storage | Account data, envelope metadata, PDFs |
| Vercel | Application hosting | Request metadata, application logs |
| Resend | Transactional email | Recipient addresses, email content |
| Stripe | Billing (credit packs) | Billing contact, payment metadata |
| Anthropic | Optional contract extraction post-sign | Signed PDF content when extraction runs |
| Extend | Field detection on upload | PDF/DOCX content during detection |
We do not sell signer data. Signer emails and signatures are used only to complete the signing workflow you initiate.
Webhook security
Outbound webhooks include an HMAC-SHA256 signature in X-Atlas-Signature:
X-Atlas-Signature: sha256=<hex digest>
Compute the digest over the exact JSON body Atlas sends, using your Atlas API key as the HMAC secret:
const crypto = require('crypto');
function verifyWebhook(payloadObject, signatureHeader, apiKey) {
const body = JSON.stringify(payloadObject);
const expected = 'sha256=' + crypto.createHmac('sha256', apiKey).update(body).digest('hex');
return signatureHeader === expected;
}
Reject requests that fail verification. Rotate API keys if a key is exposed.
Encryption
- In transit: TLS 1.2+ on all connections
- At rest: AES-256 on stored documents and database volumes (via cloud provider)
- Signing links: per-party tokens on multi-signer envelopes; tokens are required to resolve field visibility
Access control
- Workspace org admins see all teams and resources in the org
- Members see only resources on teams they belong to
- Platform connected accounts are isolated workspaces; platform operators provision them via API
- Service-role database access is restricted to Atlas application servers
SIG-lite FAQ
Questions we hear on security reviews:
Do you support SSO/SAML?
Yes, for dashboard users on paid workspaces. Orgs can enable SAML with an IdP metadata URL and email domain routing. Password sign-in remains available outside configured SSO domains. Signers do not use SSO.
Can signers authenticate with MFA?
Signers use email link + token. No separate Atlas account is required for signers.
Where is data hosted?
United States (Supabase and Vercel US regions). Contact us if you need EU data residency discussion.
Do you train AI models on customer documents?
No. Detection and extraction calls are inference-only. We do not use your contracts to train models.
Can we get penetration test results?
Available under NDA on request.
What happens if a signer declines?
The envelope moves to declined status. Partial signatures are not promoted to fully signed.
How do you handle abuse?
Turnstile at signup, per-account send credits, rate limits on sensitive endpoints, and internal monitoring on dispatch failures.
Contact
- Security questions: security@atlaswork.ai
- DPA requests: security@atlaswork.ai
- Product security page: https://atlaswork.ai/security