Security and Trust Overview

flowscope builds AI agents that work over a customer's documents and operational data: ingesting source material, parsing it, reasoning over it with large language models, and surfacing the results through interfaces (chat, review queues, dashboards) tailored to the use case. This document describes the security posture of the underlying platform, which is shared across all flowscope products.

Product-specific controls (for example human-in-the-loop authorization in workflow automation, or query auditing in retrieval-augmented chat) are described in addenda attached to this document where applicable.

Hosting and network

The application layer runs on Azure Container Apps in US regions. Persistence is a managed PostgreSQL cluster on Azure Database for PostgreSQL Flexible Server, also in US regions. In the default hosted model each customer is isolated at the row level on the shared cluster, and the deployment models described below offer stronger isolation and customer-controlled hosting where a customer's requirements call for it.

Azure Front Door (Premium), with its managed web application firewall, is the sole public entry point for application traffic. Application origins and databases deny public network access and are reached over Azure Private Link. Inbound HTTPS terminates at the Azure Front Door edge with TLS 1.3 (TLS 1.2 minimum, weak ciphers disabled). Outbound traffic to subprocessors and to any customer-side system is encrypted in transit over TLS 1.2 or higher. flowscope applications do not expose any non-HTTPS port. Where a customer's ingestion path requires SFTP, the transfer runs over SSH with key-based authentication and per-customer chroot.

Deployment models

flowscope offers four deployment models so that a customer can select the isolation posture and the data location their confidentiality and regulatory obligations require. The controls described throughout the rest of this overview apply across every model; where a model changes who owns and operates the underlying infrastructure, the operational specifics such as backup cadence, monitoring, and the regions in which subprocessors run are configured against that environment and agreed in the contract.

Multi-tenant, the default, runs on flowscope's Azure environment with each customer isolated at the row level on a shared managed PostgreSQL cluster, scoped by organization on every query so that no customer can reach another's data. This is the model the sections below describe.
Single-tenant provisions a dedicated application and database instance for a single customer within flowscope's Azure environment, so that neither storage nor compute is shared with any other customer. It is available on request for customers with elevated confidentiality requirements and carries the same controls as the multi-tenant model.
Bring your own cloud deploys the platform into the customer's own cloud account, so that customer data remains entirely within infrastructure the customer owns, under their own network boundary and key-management policy, while flowscope operates the application inside it.
On-premises deploys the platform into the customer's own datacenter or private environment, for customers who cannot place data in public cloud at all, so that the platform runs entirely within customer-controlled infrastructure.

Model providers

flowscope's products reason over customer material with large language models, and that inference is the one processing step that, by default, reaches a model provider outside the deployment. In the default configuration flowscope routes those calls to its managed model provider under enterprise terms with zero data retention; that provider, and the data it processes, is listed under Subprocessors.

A customer can instead have flowscope send inference to a model endpoint they control: their own OpenAI account, an Azure OpenAI resource in their own tenant, or any OpenAI-compatible API. Under the bring-your-own-cloud and on-premises models this keeps inference within the same boundary as the rest of the deployment, including a self-hosted model where the environment cannot reach any external API, so the data-residency posture holds through the model layer and not only the application layer.

Encryption and key management

Data at rest is encrypted with AES-256: Postgres pages on Azure Database for PostgreSQL Flexible Server and any short-lived caches. Encryption keys are managed by the underlying platform (Microsoft Azure) and rotated by the platform on its own schedule; flowscope does not hold or escrow long-lived data-encryption keys.

On single-tenant deployments, customer-managed keys (BYOK) are available for the data-at-rest layer. The customer holds and controls the key in Azure Key Vault. The flowscope BYOK Configuration Guide is available on request.

Customer-facing secrets (API keys, OAuth refresh tokens, SFTP keys, and any credentials issued to flowscope by the customer) are held in a managed secrets store, encrypted and scoped to the relevant application, with access limited to the application runtime and to a named subset of @flowscope.com operators. They are rotated on customer request, on suspected compromise, and on operator offboarding.

Authentication and access

Customer users authenticate over OAuth against Google Workspace or Microsoft Entra ID, or through a one-time passcode sent to their email. SAML 2.0 is available for enterprise SSO alongside OAuth/OIDC. flowscope does not store customer passwords. Sessions are HttpOnly, Secure cookies (no JavaScript access, HTTPS-only transmission) with a 30-day maximum lifetime and idle expiry. Each user holds one live session at a time; a new sign-in revokes other sessions. Where a user signs in over OAuth, MFA enforcement is delegated to that provider, so if the customer mandates MFA on Workspace or Entra it applies to flowscope sessions by default; the email passcode is itself a single-use, time-limited factor.

Customer roles are scoped per use case and the role grant itself is logged.

flowscope-internal staff sign in with their @flowscope.com Google Workspace identities, with MFA enforced. For support purposes, an operator can impersonate a customer user inside the application; the impersonation is attributed to the operator, in that the session records the operator's identity and the impersonated user, and an in-session banner makes it visible while it is active. All flowscope-internal staff are bound by a signed confidentiality agreement covering customer data, with obligations surviving termination of any engagement with flowscope.

Subprocessors and data flow

Customer data may be processed by a defined set of third-party services, each contracted under enterprise terms with zero-retention configurations where available and each processing data in United States regions. The current authoritative list, with the data each subprocessor touches and the change-notification mechanism customers can subscribe to, is at Subprocessors. No other external service receives customer document content.

Data retention and deletion

For the duration of the customer's contract, the production database retains all ingested customer content and the records of how flowscope has processed it. After contract termination, this data is held for a default tail of 30 days and then deleted. The post-termination tail is configurable per contract; zero-day deletion on termination is supported on request.

Customers can request deletion of a specific document or record at any time through their flowscope point of contact. A deletion request is honored within the timeframe committed in the applicable agreement, by default within 7 calendar days. Deletion removes the row, any derived structures (parses, embeddings, indexed content), the underlying document blob, and the corresponding entries from backups within their next rotation cycle.

Backups and recovery

The production cluster on Azure Database for PostgreSQL Flexible Server is protected by two complementary mechanisms. Continuous point-in-time recovery covers the configured retention window and allows restore to any moment within that window. In addition, automated daily snapshots are taken and retained per the configured retention policy, providing per-day restore points. Recovery is initiated by flowscope operations on incident or on customer request. The recovery point objective target is under 5 minutes within the continuous window and up to 24 hours via daily snapshot; the recovery time objective target is 4 hours. These are default targets, configured per deployment.

Logging, monitoring, and incident response

Customer-facing audit records, such as role grants, impersonation sessions, and session history, are held in the application database. They are retained for the duration of the contract so customer admins can review past activity, and held for a 30-day tail after termination before deletion. Application HTTP requests and diagnostic logs are infrastructure telemetry, captured through the application platform, centralized logging, and the internal observability pipeline, and retained on a rolling window (90 days by default); on a single-tenant deployment, the log workspace is dedicated and its retention is configured to the agreement. Application errors and unusual behavior surface to flowscope operators through log-based alerting and the internal observability pipeline.

In the event of a confirmed security incident affecting customer data, flowscope notifies the affected customer's designated contact without undue delay, within the timeframe committed in the applicable agreement (72 hours by default). The notification includes a written description of scope, root cause, and remediation.

Vulnerability management

Application dependencies are scanned continuously, with security advisories triaged within 7 days for high-severity issues.

Reports of suspected vulnerabilities go to security@flowscope.com. Acknowledgement within 2 business days; remediation timeline depends on severity, with critical issues targeted within 7 days and high-severity within 30 days.