Introduction

What are Policies?

Formal’s policy system uses Open Policy Agent (OPA), an open-source policy engine that enables you to express access control rules as code. Policies are evaluated in real-time as users connect to resources and execute queries. Your policies can:

Block connections to resources or specific tables/schemas
Redact query results automatically
Encrypt and decrypt HTTP secrets (for example OAuth tokens) with encrypt / decrypt
Rewrite queries before they reach the database
Filter and limit result sets
Enforce MFA for sensitive operations

How Policies Work

Policies are written in Rego, OPA’s purpose-built language for access control. They are evaluated at three stages:

Session - When a connection is established
Request - Before a query reaches the resource
Response - When data returns from the resource

Each stage has specific actions available based on when the policy is evaluated. See Enforcement for details on available actions.

Policy Structure

Every policy consists of these essential components:

Name

A unique identifier for the policy. No two policies can share the same name.

Description

A clear explanation of the policy’s purpose and scope. This helps other admins understand what the policy does.

Owners

The administrators responsible for maintaining and enforcing the policy. Owners receive notifications when policies are triggered (if configured).

Code

The policy logic, written in Rego, OPA’s purpose-built language for access control.

Policy Status

Policies can be in one of three states:

Status	Description	Use Case
Draft	Under development, not enforced	Writing and testing new policies
Dry-run	Logs violations without enforcing	Testing policies with real traffic before enforcement
Active	Fully enforced and monitoring	Production enforcement

Use dry-run mode to test policies against real traffic without impacting users. Review the logs to ensure the policy works as intended before activating it.

Notifications

Configure notifications for policy triggers:

None: No notifications sent
Consumer: Notify the user who triggered the policy
Owners: Notify policy owners
All: Notify both user and owners

Notifications can be sent via:

Email
Slack (requires integration setup)

End-User Identity Propagation

Formal can extract end-user identity from applications like Looker, Metabase, or Retool, enabling policies that work for both direct connections and application-mediated access:

Direct connection: Alice uses psql to query a resource → user and end-user are both Alice
Application connection: Katie uses Metabase → user is the machine user, end-user is Katie

This allows you to write policies that consider the actual person behind the query, even when they’re using a BI tool.

Quick Example

Block all connections by default, but allow admins using a specific machine user:

package formal.v2

import future.keywords.if
import future.keywords.in

default session := {
  "action": "block",
  "type": "block_with_formal_message"
}

session := {
  "action": "allow",
  "reason": "Admin access via authorized app"
} if {
  "admin" in input.end_user.groups
  input.user.username == "idp:formal:machine:backoffice"
  not input.end_user.email == "john.doe@joinformal.com"
}

Managing Policies

Web Console
Terraform

Navigate to Policies
Click Create Policy
Fill in name, description, and owners
Write Rego code in the editor
Set status (Draft, Dry-run, or Active)
Configure notifications
Click Create Policy to save

resource "formal_policy" "block_deletes" {
  name        = "block-production-deletes"
  description = "Prevent DELETE statements in production"
  status      = "active"

  code = <<-EOT
    package formal.v2

    import future.keywords.if

    request := {
      "action": "block",
      "type": "block_with_formal_message",
      "reason": "DELETE not allowed in production"
    } if {
      input.resource.environment == "production"
      input.query.statement_type == "DELETE"
    }
  EOT

  owners = ["admin@example.com"]

  notifications = "owners"
}

Best Practices

Start with Dry-Run

Always test new policies in dry-run mode first. Review logs to ensure they work as expected before activating.

Use Groups for User Policies

Instead of writing policies for individual users, use groups. This makes policies scalable and easier to maintain.

Document Your Policies

Write clear descriptions and use meaningful reason fields. Future you (and your team) will thank you during audits.

Leverage External Data

Use Policy Data Loaders to fetch dynamic approval lists, compliance data, or business logic from external systems.

Learn More

Policy Evaluation

Input data, evaluation stages, and available context

Enforcement

Actions including encrypt, decrypt, block, mask, and rewrite

Encrypt MCP OAuth Tokens

Seal Notion MCP OAuth tokens on the Endpoint or Connector

Examples

Real-world policy examples and common use cases

Getting Started

Configuring Formal

Leveraging Formal

Integrations

Configuration

Client Apps

Example Use Cases

What are Policies?

How Policies Work

Policy Structure

Policy Status

Notifications

End-User Identity Propagation

Quick Example

Managing Policies

Best Practices

Learn More

Policy Evaluation

Enforcement

Encrypt MCP OAuth Tokens

Examples

​What are Policies?

​How Policies Work

​Policy Structure

​Policy Status

​Notifications

​End-User Identity Propagation

​Quick Example

​Managing Policies

​Best Practices

​Learn More

Policy Evaluation

Enforcement

Encrypt MCP OAuth Tokens

Examples

What are Policies?

How Policies Work

Policy Structure

Policy Status

Notifications

End-User Identity Propagation

Quick Example

Managing Policies

Best Practices

Learn More