Security at Flowpath: how we protect your data

Automation platforms occupy an unusual position in the enterprise security landscape. Unlike a SaaS tool that stores your data in a single database, an automation platform sits between all of your other tools — it touches your CRM, your communication platform, your billing system, your HR software. This means that if an automation platform has a security problem, the blast radius is potentially enormous.

We think about this every day. This post is our attempt to be as transparent as possible about how we've architected Flowpath's security, what certifications we hold, and what our practices look like in practice rather than in marketing language.

Encryption and data storage

All data in transit between your systems and Flowpath is encrypted using TLS 1.3 — the current industry standard, which eliminates the vulnerabilities present in older TLS versions. All data at rest is encrypted using AES-256, including run logs, workflow configurations, field mappings and any data that passes through your agents during execution.

We operate on AWS infrastructure with separate deployment environments for US and EU customers. You choose your data residency at signup — US East, US West or EU West — and your data never leaves that region without your explicit written consent. This is relevant for GDPR compliance (EU data stays in the EU) and for enterprise customers with data sovereignty requirements.

Credential storage and the secrets vault

This is the part of our security architecture we're most proud of. When you connect an integration — Slack, HubSpot, Stripe, anything — your OAuth access token is stored in an isolated secrets vault that is architecturally separate from the workflow execution engine.

The execution engine doesn't store or access your tokens directly. Instead, it holds a tokenized reference — a UUID that maps to the actual credential in the vault. When a workflow step needs to make an API call, the execution engine sends the tokenized reference to the vault, the vault returns a short-lived temporary credential for that specific call, and the execution engine uses that credential to make the API call. The credential is never logged, never stored in run logs, never included in error messages and never accessible to Flowpath employees.

This architecture means that even in the event of a breach of the execution engine, an attacker would not obtain usable credentials for your connected integrations.

SOC 2 Type II

SOC 2 Type II certification means an independent third-party auditor has examined our security controls and verified that they operate effectively and consistently over a 12-month period. The distinction between Type I (point-in-time snapshot) and Type II (sustained over time) matters — Type II is significantly harder to obtain and more meaningful as a signal of genuine security maturity.

Our most recent SOC 2 Type II audit covered five trust service criteria: security (logical and physical access controls), availability (system uptime and performance), processing integrity (complete and accurate processing), confidentiality (protection of confidential information) and privacy (collection and use of personal information).

The full audit report is available to Enterprise customers under NDA. We've deliberately chosen not to summarize or excerpt it here — a summary written by the company being audited isn't useful due diligence material.

HIPAA compliance

For healthcare customers, we offer HIPAA compliance on Enterprise plans. This includes: a Business Associate Agreement (BAA), a dedicated infrastructure tier with enhanced audit logging, automatic PHI (Protected Health Information) detection that flags and quarantines any run that processes what appears to be PHI without explicit configuration, role-based access controls that meet HIPAA technical safeguard requirements, and a minimum retention period override that ensures audit logs are retained for the HIPAA-required six-year minimum.

HIPAA compliance is an add-on to the Enterprise plan, not a default feature. Contact our sales team to discuss requirements and pricing.

Our incident response commitment

We commit to notifying affected customers within 24 hours of confirming a security incident that affects their data. Our incident response process includes: automated anomaly detection that alerts our security team to unusual access patterns, a dedicated incident response team that is on-call 24/7, a communication protocol that prioritizes customer notification over PR management, and a public post-mortem for any incident that affects more than 100 customers.

We've had two security incidents in our history — one in 2024 involving unauthorized access to a small number of run log metadata records (no payload data, no credentials), and one false positive in early 2025 that triggered our notification protocol before we confirmed it was not a genuine breach. Both were communicated to affected customers within the 24-hour window.