Meet even the strictest compliance standards and scale securely with Prefect’s enterprise-grade access features and security model

Access Control

  • Personalize every user’s permissions with granular role and object-based access control
  • Manage groups of users with teams
  • Provision users with your preferred auth provider via SCIM


Secure Infrastructure

Loved by platform teams:

  • Configure and restrict infrastructure with workers and work pools
  • Dynamically define where each of your flows and tasks are executed
  • Separation of orchestration and execution means Prefect never sees your code or data


Get our SOC 2 Type II report

We send watermarked SOC 2 reports, just get in touch and we can send you a copy.

Customer Data + Environment

Prefect uses proprietary metadata to coordinate workflows and collects logs specific to the execution. Prefect requires a minimum amount of customer data (name and email address) for user login and admin management.

At the customer's instruction, Prefect may retain additional subsets of data (e.g., confidential information, login credentials, etc.) in connection with:

Secrets (Cloud 1 only)

Prefect provides the ability to store secrets in our Cloud that can be recalled in the workflow steps, using the Prefect native task library. Secrets are stored in a Google Cloud Project separate from our core processing platform with enhanced access limitations.


Customer data can be included in the workflow logging. Logs may be disabled by customer.

Flow and Task Parameters

The customer can assign Flow and Task parameter names, which are stored in the database. Flow parameter values are stored by Prefect in the database. Task parameter values are not stored by Prefect in the database.

Blocks (Cloud 2 only)

Blocks provide the storage of configuration and interfaces to external systems. Each Block document is encrypted by keys unique to each Workspace. Prefect encrypts the data before storing it in the database. Keys are stored in Cloud KMS and each Workspace has a different encryption key for Block document data.

Workflow Execution and Infrastructure Access

There are three ways that Prefect Cloud can orchestrate workflows on behalf of the user. Each method has different levels of access to customer infrastructure and different security concerns.

Hybrid Execution

With hybrid execution, Prefect Cloud orchestrates workflows by communicating with a service inside the customer infrastructure. Prefect Cloud does not require ingress access to the customer environment. Instead, a service deployed by the customer polls Prefect Cloud’s API.

For static deployments, customers can use the flow’s .serve method to poll Prefect Cloud. When it’s time for the workflow to start, the flow’s process initiates the run in a child process on the customer machine. For dynamic or on-demand infrastructure (Cloud Run jobs, Kubernetes Jobs, and the like) customers can install a Prefect Worker into their infrastructure that creates a job for each new workflow instance (known as a flow run). Workers do not give Prefect Cloud access to customer source code.

In short, hybrid execution does not require Prefect Cloud to access customer source code or infrastructure directly and the customer is responsible for maintaining the worker or flow webserver responsible for starting workflows.

Push Execution

With push execution, Prefect Cloud is responsible for provisioning on-demand infrastructure for workflows in the customer environment. Customers do not need to grant Prefect Cloud permission to customer data or source code to utilize push execution. For example, Prefect Cloud supports push execution with Google Cloud Run. Customers must provide a GCP service account key to Prefect Cloud. The service account must have permission to create Cloud Run Jobs. However, the service account provided to Prefect Cloud does not need permission to access the image with customer source code as long as the Cloud Run Job has access.

Managed Execution

With managed execution, Prefect Cloud executes workflows on its infrastructure on behalf of the customer. Customers must provide the workflow source code to Prefect Cloud to enable managed execution. If the workflow needs to access customer data or infrastructure, customers must provide Prefect Cloud with appropriate credentials.

Prefect Infrastructure

Storage + Encryption

All storage systems are encrypted with industry best practice algorithms. Data is encrypted at all times in transit and at rest with a minimum of TLS 1.2 enforced on all of our endpoints.

Server + Data Residency

Prefect does not maintain any physical data centers or servers. Our infrastructure is hosted in Google Cloud Platform (GCP). Prefect has a Data Processing Agreement with GCP and more details can be found here.

Prefect runs on GCP in the us-east1 region, with a high availability configuration across at least two availability zones.

Prefect is responsible for ensuring our infrastructure is up-to-date, with the most current security patches. Prefect continuously monitors for known vulnerabilities.

Prefect engages with a third party to conduct annual penetration tests and internally conducts annual disaster recovery simulations.


Enterprise customers can set up a SAML 2.0 connection. All other customers can use Google/Github oauth or username and password. Prefect has further protections within a tenant where only members of your organization can log into your tenant based on domain.

Company Policies

Access to Systems

Prefect grants least privilege access to all systems and conducts (i) quarterly audits on critical systems and (ii) annual audits on non critical systems. Access to Prefect systems is governed by an access request system and any changes to our system follow a change control process.

Where possible, access to Prefect systems is enforced with SSO. In all cases, platform and data systems have minimum password policies and enforce the use of multi-factor authentication.

Prefect Employee Laptop Encryption

All Prefect employee laptops are encrypted and enforced using MDM.