Built so we can't betray your trust
portshift moves sensitive data — call recordings, transcripts, API credentials. We designed the system so that even if our infrastructure were fully compromised, the blast radius for your data would be near zero.
Credential handling
You provide two credentials to run a portshift job: your Chorus API token and your cloud storage credentials (Azure SAS token, AWS access key pair, or GCS service account key). Here is exactly what we do with them.
Credentials travel from your browser to our API over TLS 1.2+. They are never sent over unencrypted channels.
Credentials are loaded into the worker process memory when a job starts and are never written to disk, logs, or any database table.
When a job finishes — successfully or not — the worker process exits. No credential material persists beyond the lifetime of the job.
We only require read access to Chorus and write access to your storage bucket. We request no broader permissions and document exactly what is needed.
Zero-retention architecture
portshift does not store your call recordings, transcripts, or any content downloaded from Chorus. Data streams directly from the Chorus API to your cloud storage. Our infrastructure is a conduit, not a destination.
- Job metadata: start time, status, file count, byte count
- Export progress: which recording IDs have been processed
- SHA-256 hash of your IP address for rate limiting
- Your name, email, company (from the early access form)
- Chorus API tokens or session credentials
- Cloud storage credentials (SAS tokens, access keys, service accounts)
- Call recordings, audio files, or video
- Transcripts, call notes, or deal metadata from Chorus
- Participant names, phone numbers, or email addresses from call data
Encryption in transit and at rest
All communication between portshift and external services uses TLS 1.2 or higher. This covers:
- Browser → portshift API
- Worker → Chorus API (recording download)
- Worker → Azure Blob / S3 / GCS (upload)
- Worker → portshift database (job state)
Certificate validation is enforced. We do not permit self-signed certificates in any production path.
Your exported data lives in your cloud storage. Encryption at rest is handled by your cloud provider under your account's policies:
- Azure Blob: Storage Service Encryption (SSE) with Microsoft-managed or customer-managed keys
- Amazon S3: SSE-S3 or SSE-KMS with your KMS key
- Google Cloud Storage: Default Google-managed encryption or CMEK
portshift's own database (Neon Postgres) is encrypted at rest by the cloud provider.
Infrastructure and isolation
Each portshift export job runs in an isolated, ephemeral compute environment. There is no shared worker pool where one customer's job could observe another's memory or file state.
Workers spin up for a job and terminate when done. No persistent disk state. No carry-over between runs.
No shared filesystem or memory between concurrent jobs. Each job operates in its own process boundary.
All portshift compute and database infrastructure is located in the United States. Data is never routed through non-US regions.
Audit trail and verification
Every portshift export produces a tamper-evident manifest file written directly to your storage bucket. This manifest is your independent verification record — it does not rely on portshift's servers to be useful.
- SHA-256 hash of every exported file
- Chorus recording ID and metadata for each file
- Export timestamp and job ID
- Total file count and byte size
After a job completes, you can independently verify export integrity with any standard tool:
sha256sum -c portshift-manifest.txt No portshift tooling required. The manifest format is plain text, documented, and stable.
What we're working on
Annual third-party penetration testing of the API surface, credential handling pipeline, and storage integration layer.
Documented IR runbooks, 24-hour breach notification SLA to affected customers, and a public security advisory page.
Bring-your-own-key encryption for the job metadata stored in portshift's database, for customers who require full key ownership.
Responsible disclosure
If you discover a security issue in portshift's platform, please report it to security@portshift.app. We will acknowledge receipt within 24 hours, keep you informed as we investigate, and credit researchers in our advisory if the report leads to a fix. We do not pursue legal action against researchers acting in good faith.