Security and data protection

Little Harbor Labs owns and operates Nextract. Protecting Customer Content and Account Data is core to how we build the product: tenant isolation, encrypted secrets, least-privilege access in the studio, and cautious outbound networking.

This page describes technical and organizational measures for hosted Service. It is not a certification (we do not claim SOC 2, ISO 27001, HIPAA, or PCI DSS unless a separate written attestation says so). Customers remain responsible for classifying their data and configuring pipelines accordingly.

Application data is scoped by organization (project). Studio users access only organizations they belong to, subject to roles (for example owner versus member). Platform operators using administrative impersonation are audited.

API keys, SFTP accounts, and SSO can be enabled or rotated by organization administrators. You should use unique credentials per environment (development, QA, staging, production).

Hosted deployments are intended to serve the studio and APIs over TLS.

Credentials stored by the Service — including SFTP and database passwords, API client secrets, connector OAuth secrets, vault connection secrets, and locally held signing private keys — are encrypted at rest with AES-256-GCM using an application credential-vault key that the operator must protect. Encrypted values are not displayed in full in the studio after save.

Sign-in passwords are stored as one-way hashes. SFTP login passwords are stored as scrypt hashes for authentication; an encrypted copy may also be kept so organization administrators can recover the credential in the studio.

Application-layer AES-256-GCM is used for those secrets. It is not a claim that every file byte or every PostgreSQL column is encrypted by the application. Disk, volume, or object-storage encryption, if any, depends on the host or cloud you use.

You may optionally connect an external secrets vault (for example cloud KMS or HashiCorp Vault) for certificate material so private keys never rest in our database.

Organization files (inbound, outbound, archive, staging, quarantine) are stored either on local disk under a per-organization path or in an S3-compatible bucket you configure. Object storage credentials are yours or your host’s; we recommend bucket policies that restrict public access.

Quarantine holds files that fail validation or scanning so they are not processed as normal inbound. Optional ClamAV scanning can inspect inbound files when enabled on the deployment.

Workers parse and map Customer Content in order to produce outputs you configured. Preview samples and run step samples may be stored so you can debug mappings. You should avoid placing secrets in sample files.

Outbound HTTP includes SSRF-oriented guards that block private, loopback, link-local, and cloud-metadata destinations in normal operation. You must still treat destination URLs as trusted configuration.

The studio records an audit trail of significant organization actions. Run records capture operational metadata and limited output samples. Run retention can be configured so history is not kept indefinitely.

We aim not to write raw passwords or full API keys to application logs. You should not paste secrets into support tickets.

If we become aware of a security incident affecting hosted Customer Content or Account Data, we will investigate, contain, and notify affected customers without undue delay — and, where a DPA or GDPR requires it, no later than 72 hours after we become aware.

Report suspected vulnerabilities or incidents to [email protected] or [email protected]. We do not offer a public bug-bounty program unless we publish one separately.

You are responsible for:

Hosted customers that need a GDPR Article 28 data processing addendum, a subprocessor list, or additional security questionnaires can request them at [email protected].

Self-hosted customers control their own security program; we can provide product documentation to support your reviews.