The Firepipe security model

This is a straight account of how Firepipe handles security, including what it does not claim. File transfer is a trust decision, so we’d rather be precise than reassuring.

The shape of it: a passthrough gateway in front of your bucket

Firepipe is a managed SFTP gateway. Your files live at rest in a cloud bucket you own (Amazon S3, Azure Blob, Google Cloud Storage, or S3-compatible). When a transfer happens, the bytes stream through the gateway to or from your bucket; Firepipe keeps no lasting copy of your file contents. That’s the core: your storage, your durability, no second copy retained on our side, nothing to migrate.

Being a passthrough also means an honest limit, stated plainly below.

How Firepipe accesses your storage (least privilege)

Amazon S3: you grant a scoped, cross-account IAM role limited to one bucket (and optionally a prefix). We don’t hold long-lived AWS keys for you; the gateway assumes the role to perform transfers, and you can revoke the role at any time.
Azure Blob, GCS, and S3-compatible: these don’t offer cross-account roles, so you provide a scoped access key. It’s stored encrypted (an AES-256-GCM envelope under a KMS-managed key, decryptable only by the gateway), bound to your account, and revocable at any time.

Either way, access is least-privilege and reversible: Firepipe can only touch the bucket you scoped it to, and you can cut that access whenever you want.

How users authenticate and are contained

Per-user credentials: each partner or system gets its own SSH key or password, never a shared login.
Path jails: every user is scoped to a prefix and can’t list or read outside it. This is on by construction, not an option you can forget to set. See chroot directories explained.
Source-IP pinning: a credential can be restricted to specific source IPs, so a leaked key is useless from elsewhere.
Instant revoke: revoking a credential cuts access immediately and tears down any live session, rather than waiting for a config reload.

Audit

Every login, upload, download, and delete is recorded with the user, source IP, timestamp, and path, and the trail is exportable. Because each partner has their own credential, the log attributes actions to a specific partner, not to one shared account. See SFTP audit logging.

Tenant isolation

Workspaces are isolated at the data layer (row-level security on the control plane), and gateway usernames are scoped per connection so one tenant’s logins can’t collide with or reach another’s.

What Firepipe does NOT claim

This is the honest part. Because Firepipe is a passthrough proxy, bytes pass through the gateway process in transit, and the gateway holds the access it uses to reach your bucket. So:

We do not claim to be zero-knowledge or end-to-end encrypted, and we don’t claim “we can’t see your data.” A passthrough gateway could read what transits it; honest security posture means saying so.
The defensible, real value is operational: your files live at rest in your own bucket with no retained copy, access is least-privilege and revocable, and there’s no lock-in or migration. We sell control and reversibility, not a promise that we can’t look.
Firepipe is not SOC 2 or HIPAA certified. If your requirement is a formal attestation, factor that in.
Certain data is excluded by the Terms of Service, not just uncertified. You must not transfer through Firepipe any special category personal data (UK GDPR Article 9), health or medical records, or payment-card data; the Service is not HIPAA or PCI DSS compliant. If you need to move regulated health or card data, Firepipe is the wrong tool, and that’s a deliberate scope decision rather than an oversight.

The residual risk to weigh: a compromise of the gateway could expose data in transit or decrypt stored backend keys. Least-privilege scoping and instant revoke limit the blast radius, but we’d rather you know the boundary than assume one that isn’t there.

In short

Least-privilege, revocable access to a bucket you own; encrypted credentials; per-user path-jailed logins; instant revoke with session teardown; an exportable audit trail; and an honest statement of what a passthrough gateway can and can’t promise. See SFTP security best practices for the general checklist, or SFTP to S3 to try it on your own bucket.