Security

Last updated: September 5, 2026

Security by architecture

The biggest security decision in DataEgress is architectural, not a control bolted on afterward: we never connect to your database. You expose a fetchPage HTTP endpoint — the same access model as any other webhook — and DataEgress calls it to retrieve exactly the rows you choose to return. Query logic, filtering, and tenant isolation all stay on your side of that boundary, under your control.

The same principle carries through to delivery: destinations are typically storage you or your end customer own (an S3 or R2 bucket you configure), not infrastructure we hold your data in long-term.

Tenant isolation

Every dataset, destination, schedule, run, and API key belongs to exactly one organization, and every read or write is scoped to the authenticated caller's organization ID — resolved server-side from the session or API key, never trusted from anything in the request itself. One customer's configuration and run history is not visible to another's.

Credentials

Destination credentials (for example, S3/R2 access keys you give us) are encrypted at rest and are never returned by any API response after they're saved — reading a destination back always shows the credential masked.
API keys are shown to you exactly once, at creation. From that point on, only a one-way hash of the key is stored — we cannot retrieve or display the original value again, and neither can anyone with access to our database.
Revoking a key or updating a destination's credentials takes effect immediately.

Data handling

Rows returned by your fetchPage endpoint pass through the Service transiently, to be assembled into a CSV or Parquet file — they are not persisted in our application database. The generated file itself is delivered to your configured destination; for signed-URL destinations, or as a short-lived mirror alongside an S3/R2 delivery, it may briefly live in DataEgress-controlled object storage as part of that delivery.

Every completed export produces a manifest — row count, a checksum computed from the bytes actually written (not merely asserted), and a schema version — so what was delivered is verifiable rather than something you have to take on faith.

Network and outbound requests

Because the Service calls a URL you configure (your fetchPage endpoint), outbound requests are validated to prevent server-side request forgery: the address a hostname resolves to is checked before we connect to it, and that same validated address is what the connection actually uses — not looked up once and trusted after. Redirects are followed manually, with each hop re-validated the same way, rather than handed to a generic HTTP client that would trust wherever a redirect points.

Reliability as a security-adjacent property

A delivery you can't trust is its own kind of risk. Retries reuse deterministic destination keys, so re-running a failed export overwrites the same file rather than creating a duplicate — a retry is safe to trigger without double-delivering data. Every run's manifest is checksummed against the bytes actually written, so success or failure is verifiable rather than assumed.

Billing and webhooks

Stripe webhook events are cryptographically verified against their signature before we act on them, and we re-fetch current subscription state directly from Stripe rather than trusting whatever a webhook payload claims — so a forged or replayed webhook can't be used to grant access it shouldn't.

What we do not claim

In the interest of being straightforwardly useful to a security reviewer, rather than vague: we do not hold a SOC 2 report, an ISO 27001 certification, or any other formal third-party security certification today. We have not commissioned a formal third-party penetration test. We do not offer a contractual uptime SLA unless one is separately negotiated. None of this is a gap we're hiding — it's the honest current state of an early-stage company, and we'd rather you know it going in than find out later. If a specific certification, audit, or contractual commitment is a hard requirement for your evaluation, contact us so we can talk through what's actually needed.

Reporting a security issue

If you believe you've found a security issue in DataEgress, please contact us directly rather than filing it publicly. We'll respond as quickly as we can.