Security at PipeKeel
PipeKeel moves and transforms business data, so we designed it to touch as little of that data as possible — and to protect what it must touch.
Where your data goes
- Sovereign pipelines run in your Google Cloud project, as a service account you create and control, limited to the datasets you choose. PipeKeel sends the SQL and reads job status and statistics; your rows don't pass through PipeKeel. Sources and targets outside BigQuery are moved by a Runner that runs in your project too.
- Express pipelines run in PipeKeel's infrastructure in your organization's home region — United States, Canada or India — in a worker started for that one task, with storage and datasets that belong to your organization alone.
- Relay (off by default) lets PipeKeel move data for a Sovereign pipeline without a Runner: rows pass through a worker in memory only, never stored. An admin must accept the Relay disclosure to turn it on, and every such run is labelled.
- Previews of sample rows are shown in your browser and never stored, and admins can turn them off.
Credentials
- Connection credentials are stored in Google Secret Manager. PipeKeel's API can store them but cannot read them back; only the component that runs a task reads the secrets that task needs.
- You can keep credentials in your own Secret Manager instead — PipeKeel stores only their names. For Google services, keyless access (service account impersonation) needs no stored key at all.
- Credentials are never logged, never shown again after you save them, and never sent to your browser.
Isolation
- Every record belongs to one organization, and every database query is scoped to it; automated tests try every endpoint with another organization's ids.
- Each organization gets its own Google service accounts, storage bucket and datasets; workers act only through short-lived, per-organization credentials.
- Workers receive signed, single-use task instructions and refuse anything else. Outbound connections are checked so they can't reach internal or cloud-metadata addresses.
Accounts and access
- Passwords hashed with Argon2id and checked against known breaches; sign-in throttling and lockout.
- Two-factor authentication with recovery codes, which an organization can require for everyone; an email when your account signs in from a new device.
- Re-authentication for sensitive actions such as changing permissions, adding credentials, approvals and billing.
- Roles, teams and per-project, per-environment and per-pipeline permissions; IP allow-lists and session time-outs set by your admins.
- An append-only, hash-chained audit log of every change, which admins can verify in the app.
Infrastructure
- Encryption in transit (TLS) everywhere, and at rest.
- Cloudflare's network in front of the application, with strict security headers and rate limits in the application as well.
- Nightly encrypted database backups in a separate location, kept for 35 days, with tested restores.
- Retention by plan: old versions and run logs are deleted automatically.
How we build it
- Automated security scanning of our code and dependencies, tests for isolation and permissions on every route, and a review of every new kind of block that runs code or makes network calls.
- Container images are signed; customers' Runners are pinned to a signed image by its digest.
- An independent penetration test before general availability.
Privacy and compliance
For the data your pipelines process, PipeKeel is your processor under our Data Processing Agreement, which lists our sub-processors and security measures. How we handle account information is in our Privacy Policy. Both are written for India's DPDP Act, Canada's PIPEDA and US state privacy laws.
Report a vulnerability
Please write to [email protected] with “Security” in the subject. We'll reply quickly, keep you informed, and won't take action against good-faith research that avoids other customers' data and service disruption.