Security & Infrastructure

Last updated: September 3, 2026

Where this runs

Intentflow runs entirely on Amazon Web Services, in the us-east-1 (N. Virginia) region, on a private virtual network (VPC). We don't operate our own data centers - AWS's own physical and infrastructure security controls apply to the underlying hardware.

Tenant isolation

Every tenant - free, paid, or an MSP's client - gets its own Kubernetes namespace and its own NetBox application deployment. There's no shared NetBox process and no shared application database schema between tenants at any tier:

Tier	Database	Cache/queue	File storage
Free	Dedicated PostgreSQL pod, per tenant	Shared Redis (task queue only, no customer data)	Dedicated single-node volume, per tenant
Business	Dedicated database and role on a shared RDS instance	Dedicated Redis, per tenant, password-protected and network-isolated	Dedicated single-node volume, per tenant
Enterprise	Dedicated, multi-AZ RDS instance, per tenant	Dedicated ElastiCache Redis, per tenant	Multi-AZ managed file storage (Amazon EFS), scoped per tenant

Enterprise tenants also run on a separate, dedicated Kubernetes node pool - not shared with other tiers. Enterprise's file storage moved from a single-node volume to multi-AZ EFS specifically so it doesn't become a single point of failure for a tier that otherwise runs multiple, independently-schedulable instance replicas.

Encryption

In transit: every instance is served over HTTPS with a certificate issued via Let's Encrypt; there's no unencrypted path to your instance.
At rest - database: storage encryption is enabled on every RDS instance (Business and Enterprise), and on Free's dedicated database volume too.
At rest and in transit - cache: Enterprise's dedicated ElastiCache Redis has both at-rest and in-transit encryption enabled. Business's dedicated Redis runs as a password-protected, network-isolated pod rather than a managed ElastiCache instance - its underlying volume is encrypted, and traffic to it is TLS-encrypted as well.
At rest - backups: the S3 bucket that backups are stored in uses AES-256 server-side encryption, with all public access blocked at the bucket level.
At rest - file storage: Enterprise's multi-AZ file storage (Amazon EFS) is encrypted. Free and Business's per-tenant volumes (EBS) are encrypted by default.

Backups

Business instances are backed up daily with 7-day retention; Enterprise instances are backed up daily with 14-day retention. Free tier currently has no automated backup - if that matters for your use case, Business is the right starting point. Backup storage is private and not directly accessible outside the backup process itself.

Network configurations you upload

Verify and Reconcile both work from device configuration you upload - running-configs, and the command output around them. We treat that as the most sensitive thing you hand us, because for most networks it is. Here is exactly what happens to it.

Where it goes: a private S3 bucket in our own AWS account, in the same region as the rest of the service. All public access is blocked at the bucket level, and it is encrypted at rest with AES-256 server-side encryption.
It never leaves our infrastructure. Analysis runs on our own Batfish service inside our Kubernetes cluster, reachable only from within that cluster and not exposed to the internet at all. Your configuration is not sent to any third-party service - and specifically, it is never sent to any AI or large language model. Every check Verify runs is deterministic analysis of the configuration itself. The product has no AI dependency of any kind.
The analysis copy is destroyed with the run. Batfish holds a working copy only while the run executes; it is deleted when the run finishes, whether the run succeeded or failed.
The raw upload is deleted after 7 days, automatically, by an S3 lifecycle rule on the storage itself - not by a scheduled job that could silently stop running. This is deliberately much shorter than the report it produces: the configuration is read once during the run and never needed again except to re-run it, so it should not outlive that use. (Re-running a Verify run past 7 days therefore isn't possible - you would upload again.)
The report outlives the configuration, never the other way round. A Verify subscription report is kept for 30 days and a one-time Verify report for 7 days; Reconcile's reconciliation data is kept for 30 days. Because the raw configuration is on a 7-day clock, it is always deleted before or at the same time as the report derived from it - your configuration never sits in storage after the thing you actually wanted is gone.
Who can read it: the web application and the background worker, each under its own narrowly-scoped IAM role limited to those specific storage prefixes. Neither role is permitted to list the bucket, so neither can enumerate what is stored - only fetch a specific object by a key derived from your own account and run. No customer can reach another customer's uploads. Account-level access is limited to the operator, as described under Access control below.

One current exception, stated plainly rather than glossed: configuration uploaded through Reconcile is kept for 30 days rather than 7, because unlike Verify it stays in use for the life of the batch - re-parsing, running Verify against it, and downloading the original are all features that read it back. If a shorter window matters for your environment, tell us and we will talk about it.

Access control

Every internal component (the web application, the background provisioning worker, the backup job) runs under its own narrowly-scoped AWS IAM role, limited to only what that specific component needs - not one broad role shared across everything.
Tenant credentials (database passwords, NetBox secret keys, admin passwords) are generated per tenant and stored in AWS Secrets Manager, never committed to source control or left in plaintext configuration.
Account authentication runs on AWS Cognito.
Access to the underlying AWS account and Kubernetes cluster is limited to the operator (see our Terms of Service for who that is).

What we don't have yet

In the interest of not overstating our posture: we don't currently hold a third-party security certification (like SOC 2 or ISO 27001), don't publish a formal uptime SLA, and don't run a public bug bounty program. Given the size of the operation today, this page will be updated as that changes.

Reporting a security issue

If you find a security problem, please email support@intentflow.co with details - we'll respond and prioritize genuine reports.