Evaluation - Formal Documentation

Policies are evaluated at three stages: session (connection time), request (before query execution), and response (after data retrieval). Each stage provides different input data for making policy decisions.

For available enforcement actions at each stage, see Enforcement. If you have existing policies using pre_request / post_request, see Legacy Stage Names.

Policy Scope

By default, policies apply universally to all users, resources, and data locations. You can narrow the scope within each policy using conditions.

User Context Quick Reference

Access user information via input.user and input.end_user:

Field	Type	Description
`username`	String	Unique username
`email`	String	Email address (human users only)
`groups`	[]String	Group names the user belongs to
`group_ids`	[]String	Formal group IDs the user belongs to
`type`	String	`human` or `machine`
`idp.attributes`	Object	Custom SSO attributes sent by the identity provider
`idp.group_ids`	[]String	Raw IdP group IDs (e.g. Okta group IDs)

Resource Context Quick Reference

Filter by resource via input.resource:

Field	Type	Description
`id`	String	Resource ID
`name`	String	Resource name
`technology`	String	`postgres`, `mongodb`, `snowflake`, etc.
`hostname`	String	Resource hostname
`environment`	String	Environment tag

Policy stages

Session stage

Available inputs

Name	Type	Description
policy_id	STRING	ID of the policy evaluated.
session	Session Object	Formal session identity. Use `input.session.id` for the session ID.
application	Application Object	Client application. Use `input.application.name` for the application name.
client_network	Client Network Object	Client IP address and whether the client connection is encrypted.
db_name	STRING	Name of the database.
native_user	STRING	Selected Native User label, or upstream username for legacy Native Users.
native_user_assignment	STRING	How the user was selected. Current values: `cel`, `user-requested`. Legacy values: `user-requested`, `user`, `group`, `resource-hostname`, `default`.
native_user_selection	OBJECT	Requested Native User and assigned default. Each contains `id`, `label`, and `user_type`. Omitted for legacy and direct native sessions.
user	User Object	The user making a connection to the database. User object includes name, email and groups.
end_user	User Object	If the user is a machine user, the end user is the user behind the application, otherwise the end user has the same value as the user.
device	Device Object	Device information.
agent	Agent Object	AI agent context. Populated when the connection originates from an AI coding agent via the Formal Endpoint.
resource	Resource Object	The Resource being queried.
connector	Connector Object	The current Connector.
http	HTTP Object	HTTP request details when the technology exposes transport context at session policy.
clickhouse	ClickHouse Object	ClickHouse named-session context. At this stage, `session_id` is the ClickHouse-specific field available.
aws	AWS Object	AWS resources for SSH and Kubernetes.
kubernetes	Kubernetes Object	Kubernetes resource context for Kubernetes.
snowflake	Snowflake Object	Snowflake specific information.
space	Space Object	Space specific information.

Available actions

For this policy stage, these actions are possible:

Action	Supported on	Effect
`allow`	All technologies	Lets the connection proceed
`block`	All technologies	Refuses the connection
`mfa`	Users running the Formal Endpoint	Asks the user for device-owner verification first
`quarantine`	SSH, Kubernetes `exec`	Ends the user’s sessions and blocks the user until an admin unblocks them
`suspend`	SSH, Kubernetes `exec`	Ends the current session
`impersonate`	Kubernetes	Forwards requests with Kubernetes impersonation headers

For SSH and Kubernetes exec sessions, Formal re-evaluates session rules while the session runs, for example when a session monitor triggers. See Enforcement for each action’s parameters.

Request stage

Request rules are evaluated by the proxy when it intercepts a request (query) just before sending it to the resource. This evaluation stage is especially useful in blocking write requests.

Available inputs

Name	Type	Description
policy_id	STRING	ID of the policy evaluated.
session	Session Object	Formal session identity. Use `input.session.id` for the session ID.
request	Request Object	Formal request identity. Use `input.request.id` for the request ID.
application	Application Object	Client application. Use `input.application.name` for the application name.
client_network	Client Network Object	Client IP address and whether the client connection is encrypted.
sql_query	SQL Query Object	SQL query.
query	SQL Query Object	Deprecated alias for `sql_query`.
db_name	STRING	Name of the database.
user_type	ENUM	Underlying type used by the user to connect to the database, can be `formal` or `native`.
schema_paths	[]STRING	List of the schema paths that are accessed by a query.
table_paths	[]STRING	List of the table paths that are accessed by a query.
user	User Object	The user making a connection to the database. User object includes name, email and groups.
end_user	User Object	If the user is a machine user, the end user is the user behind the application, otherwise the end user has the same value as the user.
device	Device Object	Device information.
agent	Agent Object	AI agent context. Populated when the connection originates from an AI coding agent via the Formal Endpoint.
space	Space Object	Space information.
row	[]Column Object	Rows of data being queried.
resource	Resource Object	The Resource being queried.
connector	Connector Object	The current Connector.
http	HTTP Object	HTTP request details. Populated for HTTP-based resources, including LLM.
clickhouse	ClickHouse Object	ClickHouse-specific request context.
mongodb	MongoDB Object	MongoDB-specific request context.
snowflake	Snowflake Object	Snowflake specific information.

Available actions

For this policy stage, four types of actions are possible: allow, block, rewrite, and decrypt.

Response stage

Response rules are evaluated by the proxy when it intercepts data received from the resource. This evaluation stage is particularly useful in the context of masking or filtering read requests.

Available inputs

Name	Type	Description
policy_id	STRING	ID of the policy evaluated.
session	Session Object	Formal session identity. Use `input.session.id` for the session ID.
request	Request Object	Formal request identity. Use `input.request.id` for the request ID.
application	Application Object	Client application. Use `input.application.name` for the application name.
client_network	Client Network Object	Client IP address and whether the client connection is encrypted.
sql_query	SQL Query Object	SQL query.
query	SQL Query Object	Deprecated alias for `sql_query`.
db_name	STRING	Name of the database.
schema_paths	[]STRING	List of the schema paths that are accessed by a query.
table_paths	[]STRING	List of the table paths that are accessed by a query.
row	[]Column Object	Rows of data being queried.
user	User Object	The user making a connection to the database. User object includes name, email and groups.
end_user	User Object	If the user is a machine user, the end user is the user behind the application, otherwise the end user has the same value as the user.
device	Device Object	Device information.
agent	Agent Object	AI agent context. Populated when the connection originates from an AI coding agent via the Formal Endpoint.
resource	Resource Object	The Resource being queried.
connector	Connector Object	The current Connector.
http	HTTP Object	HTTP response details. Populated for HTTP-based resources, including LLM.
clickhouse	ClickHouse Object	ClickHouse response context, including the server-produced output format.
snowflake	Snowflake Object	Snowflake specific information.
space	Space Object	Space specific information.

Available actions

For this policy stage, these actions are possible: allow, block, filter, mask, encrypt, and rewrite. rewrite at this stage changes HTTP response headers or bodies.

Standard input data

Policies can access various data types, including user information, resource information, SQL query information, and HTTP request information. The following sections describe the available data types.

Session object

Value	Type	Description
id	STRING	Formal session identifier

Request object

Value	Type	Description
id	NUMBER	Formal request identifier within the session. Present at request and response stages.

Application object

Value	Type	Description
id	STRING	ID of the application, when the client sends one
name	STRING	Name of the client application (e.g. `psql`)
environment	STRING	Environment of the application, when the client sends one

Client network object

Value	Type	Description
ip_address	STRING	IP address of the client
encrypted_connection	BOOLEAN	Whether the connection between the client and the Connector is encrypted with TLS or SSH

User object

Value	Type	Description
username	STRING	Username of the user
email	STRING	If it’s a human user, their email address
groups	[]STRING	Groups in which the user is included
type	STRING	Type of the user, can be either `human` or `machine`

Connector object

Value	Type	Description
id	STRING	ID of the Connector
name	STRING	Name of the Connector

Resource object

Value	Type	Description
id	STRING	ID of the Resource
name	STRING	Name of the Resource
technology	STRING	Technology of the Resource
hostname	STRING	Hostname of the Resource
hostname_name	STRING	Name of the Hostname of the Resource
environment	STRING	Environment of the Resource
port	STRING	Port of the Resource

Column object

Value	Type	Description
name	STRING	Name of the column
data_label	STRING	Label assigned to the column
json_path	STRING	JSON path of the column
data_type	STRING	Data type of the column
value	STRING	Value of the column
in_functions	[]Function Object	List of functions that the column is used in

input.row lists all columns extracted from your SQL query. A single returned column can come from multiple source columns (e.g. when using wildcards, joins, or unions), and thus result in several policy columns. When the Connector cannot resolve a source, the returned column itself stands in as its own policy column. This column lineage mapping is then used by the Connector’s policy engine: a response rule that masks a policy column will be able to mask every returned column whose lineage includes it. For example, in SELECT email FROM users UNION SELECT email FROM customers, the returned email column has two source columns: users.email and customers.email. Either one alone is enough to mask it for the entire result.

Function object

Value	Type	Description
name	STRING	Name of the function (e.g. `MAX`)
categories	[]STRING	Categories of the function (e.g. `["aggregate", "window"]`)

Function categories are used to group functions into different categories. The following categories are available: aggregate, bitwise, conditional, context, conversion, data_generation, date_time, differential_privacy, encryption, file, geospatial, hash, metadata, notification, numeric, scalar, semi_structured, string_and_binary, system, table, vector_similarity, window. These categories are inspired by the Snowflake documentation.

Space object

Value	Type	Description
name	STRING	Name of the space
id	STRING	ID of the space

HTTP object

Value	Type	Description
hostname	STRING	Upstream hostname (e.g. `api.anthropic.com`)
method	STRING	HTTP method
path	STRING	Request path
headers	OBJECT	HTTP headers as a map from header name to string array. Header names are normalized to lowercase in policy input.
body	STRING	Raw HTTP body, when available
json	OBJECT	Parsed JSON body, when the body is valid JSON and the content type is JSON

Native users

You can enforce policies on the Native User selected for an upstream connection. input.native_user contains the selected label. This policy allows only the reader label:

package formal.v2

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

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

session := { "action": "allow", "reason": "reader native user" } if {
	input.native_user == "reader"
}

Native user assignment

The native_user_assignment field explains how Formal selected the Native User:

Value	Model	Description
`cel`	Current	The Resource’s default selection expression assigned the user
`user-requested`	Current and legacy	The client requested a Native User in the connection username
`user`	Legacy	A user identity link assigned the user
`group`	Legacy	A group identity link assigned the user
`resource-hostname`	Legacy	A Resource hostname link assigned the user
`default`	Legacy	The Resource’s default Native User was used

See Legacy Native Users for the legacy selection behavior behind these values. This policy blocks every explicit override:

package formal.v2

import future.keywords.if

default session := { "action": "allow" }

session := { "action": "block", "type": "block_with_formal_message", "message": "Manual native user override is not allowed" } if {
	input.native_user_assignment == "user-requested"
}

Requested and assigned Native Users

Native Users add input.native_user_selection. It can contain:

{
  "requested": {
    "id": "nativeuser_requested",
    "label": "break-glass",
    "user_type": "basic"
  },
  "assigned": {
    "id": "nativeuser_assigned",
    "label": "reader",
    "user_type": "basic"
  }
}

requested is present when the client uses an @<label> suffix. assigned is present when the Resource has a default Native User selection. The selected Native User is requested when both values exist. Policies can compare the two before allowing the connection:

package formal.v2

import future.keywords.if

default session := {"action": "allow"}

session := {
  "action": "block",
  "type": "block_with_formal_message"
} if {
  input.native_user_assignment == "user-requested"
  input.native_user_selection.requested.id != input.native_user_selection.assigned.id
}

The user_type value describes the credential shape. See supported credential types for the full list. See Select a default Native User for selection examples.

ClickHouse resources

ClickHouse request policies receive ClickHouse-specific fields under input.clickhouse. HTTP transport context is available through input.http at request and response policy. SQL context is available through input.sql_query. Database and write-target context use input.db_name and input.table_paths.

ClickHouse object

Value	Type	Description
`endpoint`	STRING	Type of ClickHouse request or custom-handler path. Available at request and response stages.
`format`	STRING	Output format reported by ClickHouse. Populated at the response stage only.
`url_settings`	OBJECT	Settings supplied as URL parameters by this request.
`url_filters`	[]STRING	`filter` URL parameters supplied by this request, in order.
`request_parameters`	OBJECT	Request-scoped `param_*` query bindings, without the prefix.
`query_id`	STRING	Query ID used for the request.
`quota_key`	STRING	Effective quota key supplied by the request.
`session_id`	STRING	Named ClickHouse HTTP session; empty for a stateless request. This is the ClickHouse-specific field available at session policy.
`session_check`	BOOLEAN	Whether ClickHouse must reject the request unless the named session already exists.

For database, query, and table-path inputs, see ClickHouse policy evaluation.

Snowflake resources

You can enforce policies on Snowflake resources based on the role used to connect to the resource.

Snowflake object

Value	Type	Description
role	STRING	Role used to connect to the Snowflake resource

MongoDB resources

MongoDB request policies receive the command being run under input.mongodb, and its database under input.db_name. MongoDB has no schema layer, so the collections a command names are available in input.table_paths using the database.collection format. That includes the namespaces a bulkWrite or a renameCollection names. It does not yet include collections reached from inside an aggregation pipeline (e.g. $lookup, $unionWith, $out or $merge).

MongoDB object

Value	Type	Description
`command`	STRING	Name of the command, such as `find`, `insert`, or `aggregate`.
`projection`	OBJECT	Projection of a `find`, or `fields` of a `findAndModify`, as written by the client. For example, `{"name": 1, "_id": 0, "exposed": "$ssn"}`. Absent when the command has no projection.

SQL resources

Formal can also enforce policies specific to SQL queries. SQL Query Object

Value	Type	Description
query	STRING	SQL query
statement_type	STRING	Type of the SQL statement
command_type	STRING	Type of the SQL command
incomplete	BOOLEAN	Whether the query context may omit details.
limit	INT	Limit of the SQL query
transaction_in_progress	BOOLEAN	Whether a transaction is currently in progress. Postgres only.
transaction_history	[]STRING	List of the most recent statements executed in the current transaction (up to 15). Postgres only.

Example: Run all SQL statements in a transaction in order

You can use a workflow to create a policy suspension that ensures a sequence of SQL statements is executed in the correct order within a transaction. The workflow below accepts a list of ordered statements via its API trigger and creates a suspension that validates each statement matches the expected sequence using transaction_history.

trigger:
  type: api-request
  name: my_workflow_trigger
  args:
    allow: <allow expression here>
actions:
- type: formal-app-command
  name: create_policy_suspension
  args:
    app: Policies
    command:
      name: PolicySuspension
      type: Create
    machine_user_id: <machine user id>
    input:
      policy_id: <policy id>
      identity_type: user
      identity_id: ${{trigger.user.id}}
      input_condition: "input.sql_query.transaction_in_progress && size(input.sql_query.transaction_history) < size(${{trigger.payload.transaction}}) && lists.range(size(input.sql_query.transaction_history)).all(i, ${{trigger.payload.transaction}}[i] == input.sql_query.transaction_history[i]) && ${{trigger.payload.transaction}}[size(input.sql_query.transaction_history)] == input.sql_query.query"
      oneoff: false
      expiration_minutes: 60

AWS resources

Formal can also enforce policies on specific AWS Resources. These policies can be actively used for the SSH or Kubernetes.

AWS object

Value	Type	Description
account	Account Object	AWS account
ecs	ECS Object	Configuration details for ECS resources
ec2	EC2 Object	Configuration details for EC2 instances
eks	EKS Object	Configuration details for EKS resources

ECS object

Value	Type	Description
cluster_name	STRING	Name of the ECS cluster
service_name	STRING	Name of the ECS service
task_id	STRING	ID of the ECS task
container_name	STRING	Name of the ECS container

EC2 object

Value	Type	Description
tags	[]STRING	Tags of the EC2 instance
instance_id	STRING	Identifier of the EC2 instance

EKS object

Value	Type	Description
cluster_arn	STRING	Amazon Resource Name (ARN) of the EKS cluster
cluster_name	STRING	Name of the EKS cluster

Kubernetes resources

Formal can enforce policies on Kubernetes API requests based on the resource being accessed. The Kubernetes context is available via input.kubernetes.

Kubernetes object

Value	Type	Description
group	STRING	API group of the resource (e.g. `apps`). Empty string for core API resources.
group_version	STRING	API version of the resource (e.g. `v1`).
namespace	STRING	Namespace of the resource. Empty for cluster-scoped resources.
kind	STRING	Kind of the resource (e.g. `pods`).
name	STRING	Name of the specific resource. Empty for list or collection operations.
subresource	STRING	Subresource being accessed (e.g. `exec`).
verb	STRING	Kubernetes API verb: `get`, `list`, `watch`, `create` or the lower-cased HTTP method for non-resource requests (e.g. `get` for `/healthz`).

SSH resources

Formal can enforce policies on SSH sessions. The SSH context is available via input.ssh. SSH states what a session is for before any of it happens, so a session rule can decide on the command the client asked to run.

SSH object

Value	Type	Description
is_sftp	BOOLEAN	Whether the session is an SFTP transfer rather than a shell or a command
is_pty	BOOLEAN	Whether the client asked for a terminal
is_shell	BOOLEAN	Whether the session opens a shell rather than running a command
command	STRING	What the far side will run, verbatim. Absent when the session gets a shell

command is the string as the client sent it. The far side runs it with a shell, so one session can ask for several things at once: match on what a rule cares about inside the command rather than comparing the whole of it. Git runs over SSH this way, which is what makes a push distinguishable from a clone: git-receive-pack writes to a repository and git-upload-pack reads from one, each naming the repository.

package formal.v2

import future.keywords.if

repository := "acme/infrastructure.git"

session := {
	"action": "mfa",
	"message": sprintf("push to %s", [repository]),
} if {
	contains(input.ssh.command, "git-receive-pack")
	contains(input.ssh.command, repository)
}

LLM resources

Formal can enforce policies on LLM API sessions. Use session rules to block a connection before it reaches the upstream provider, request rules to inspect and rewrite outgoing request headers or bodies, and response rules to evaluate model responses. For assessed LLM tool calls, response policies can also read input.assessment. See Assessments for its fields and an example.

Tool calls are part of the model response, so policies that inspect input.llm.tool_calls should use the response rule.

LLM object

Value	Type	Description
`provider`	STRING	LLM provider name (e.g. `anthropic`, `openai`)
`model`	STRING	LLM model name
`request_format`	STRING	Wire format (e.g. `anthropic_messages`, `openai_responses`)
`system_instruction`	STRING	System prompt when present
`messages`	[]Message Object	Request messages and content parts
`response_messages`	[]Message Object	Model reply, available in the `response` rule once the full response is evaluated; empty when a streamed tool call is checked before the response ends
`tools`	[]Tool Object	Tools declared on the request
`available_skills`	[]Object	Skills the agent can load. Each has `name` and `description`. Populated for Claude Code requests.
`loaded_skills`	[]Object	Skills loaded into the conversation. Each has `name`, `description`, and `contents`. Populated for Claude Code requests.
`stop_reason`	STRING	Reason the model stopped generating
`input_tokens`	INT	Number of input tokens
`output_tokens`	INT	Number of output tokens
`tool_calls`	[]Tool Call Object	Tool/function calls made by the model
`provider_session_id`	STRING	Provider’s session identifier

Message object

Value	Type	Description
`role`	STRING	Normalized role: `system`, `user`, `assistant`, `tool`
`raw_role`	STRING	Provider role before normalization
`content_parts`	[]Content Part	Text, media, and tool parts in the message

Content part object

Value	Type	Description
`type`	STRING	`text`, `reasoning`, `image`, `audio`, `file`, `tool_call`, `tool_result`, or `unknown`
`text`	STRING	Text content when `type` is `text`, `reasoning`, or `tool_result`
`name`	STRING	Tool name or filename when applicable
`tool_call_id`	STRING	Correlates tool call and tool result parts
`input`	Object	Tool-call arguments when `type` is `tool_call`

Tool object

Value	Type	Description
`name`	STRING	Request-declared tool or function name
`type`	STRING	Request-declared tool type
`description`	STRING	Tool description when present
`input_schema`	Object	Request-declared input schema when available

Tool call object

Value	Type	Description
`name`	STRING	Name of the tool/function called
`id`	STRING	Unique identifier for the call
`input`	Object	Arguments passed to the tool

Example: Rewrite request headers

The following policy adds request headers before the LLM request is sent to the upstream provider. Header values must be arrays of strings. Set a header to an empty array to remove it.

package formal.v2

import future.keywords.if

rewritten_headers := object.union(input.http.headers, {
  "anthropic-allowed-org-ids": ["aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"],
})

request := {
  "action": "rewrite",
  "headers": rewritten_headers,
} if {
  input.resource.technology == "llm"
}

For the full walkthrough, see Restrict Anthropic Sign-Ins to One Org.

Example: Redact SSNs from request messages

Use a request-stage rewrite with regex.replace on input.http.body to strip sensitive values from prompts without blocking the session. This keeps coding agents usable when SSNs appear in the context window.

package formal.v2

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

ssn_pattern := `\b\d{3}-\d{2}-\d{4}\b`

request := {
  "action": "rewrite",
  "body": regex.replace(input.http.body, ssn_pattern, "[REDACTED-SSN]"),
  "reason": "Redact SSNs from LLM request messages",
} if {
  input.resource.technology == "llm"
  some msg in input.llm.messages
  some part in msg.content_parts
  part.type in {"text", "tool_result"}
  regex.match(ssn_pattern, part.text)
}

The rewrite replaces the full HTTP body string. Keep replacements JSON-safe so the upstream request stays valid. See HTTP body rewrites.

Example: Block specific tool calls

The following policy blocks any LLM response that includes a Bash tool call with a specific command:

package formal.v2

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

response := {"action": "block", "type": "block_with_formal_message"} if {
  some tool_call in input.llm.tool_calls
  tool_call.name == "Bash"
  tool_call.input.command == "echo hi"
}

MCP resources

Formal can enforce policies on MCP tool calls. The MCP context is available via input.mcp at the request and response stages when the request is a tool call.

MCP object

Value	Type	Description
`method`	STRING	JSON-RPC method (e.g. `tools/call`, `tools/list`)
`tool_name`	STRING	Name of the MCP tool being called (e.g. `read_file`, `delete_file`)
`tool_params`	Object	Parameters passed to the tool

To block unapproved MCP servers and point agents to approved ones, see mcp_suggest_alternatives.

Example: Block a specific tool

package formal.v2

import future.keywords.if

default request := {"action": "allow"}

request := {"action": "block", "type": "block_with_formal_message"} if {
  input.mcp.tool_name == "list_pull_requests"
}

To seal OAuth Bearer tokens for MCP clients, see Encrypt MCP OAuth Tokens.

Device

Formal can also enforce policies on specific device attributes.

This feature is only available for devices using the Formal Endpoint.

Device info object

Value	Type	Description
hardware	Hardware Info Object	Hardware information of the device
software	Software Info Object	Software information of the device

Hardware info object

Value	Type	Description
model_name	STRING	Model name of the device
model_identifier	STRING	Model identifier of the device
model_number	STRING	Model number of the device
system_firmware_version	STRING	System firmware version of the device
os_loader_version	STRING	OS loader version of the device
serial_number	STRING	Serial number of the device
hardware_uuid	STRING	Hardware UUID of the device
provisioning_udid	STRING	Provisioning UDID of the device
activation_lock_status	STRING	Activation lock status of the device

Software info object

Value	Type	Description
system_version	STRING	System version of the device
kernel_version	STRING	Kernel version of the device
boot_volume	STRING	Boot volume of the device
boot_mode	STRING	Boot mode of the device
computer_name	STRING	Computer name of the device
user_name	STRING	User name of the device
secure_virtual_memory	STRING	Secure virtual memory of the device
system_integrity_protection	STRING	System integrity protection of the device
time_since_boot	STRING	Time since boot of the device

AI agents

Formal tracks connections that originate from AI coding agents running through the Formal Endpoint. When an agent is detected, input.agent is populated with context about that agent.

input.agent is only populated for connections made via the Formal Endpoint. It is empty for direct connections.

Agent object

Value	Type	Description
type	STRING	The agent type (e.g. `claude-cli` for Claude Code, `cursor`, `codex_cli_rs` for Codex).
provider	STRING	The LLM provider used by the agent (e.g. `anthropic`, `openai`).
provider_session_id	STRING	The LLM provider’s session ID for the current conversation.
version	STRING	The version of the agent.
yolo_mode	BOOLEAN	`true` if the agent was launched with the `--dangerously-skip-permissions` flag. This flag is specific to Claude Code and bypasses its interactive permission prompts, allowing it to execute tool calls without user confirmation.

Example: block Claude Code in YOLO mode

Use input.agent.yolo_mode to block autonomous agents from accessing sensitive resources without per-action approval:

package formal.v2

import future.keywords.if

default session := {"action": "allow"}

session := {"action": "block", "type": "block_with_formal_message"} if {
    input.agent.yolo_mode == true
}

Policy Input Retention

Formal can optionally retain these inputs for policy backtesting where you can test policies on historical data.

Extending Policies with External Data

You can extend policies with custom data fetched by Policy Data Loaders. The data is accessible via the data object using the loader’s configured key. Example:

# If your Policy Data Loader has key "approved_users"
data.approved_users.user_ids

For more information, see Policy Data Loaders.

Legacy Stage Names

Prior to Connector v1.31.19, the Rego rule names for the request and response stages were pre_request and post_request. These legacy names still work and existing policies do not need to be updated. To migrate, rename pre_request to request and post_request to response in your policy code. Different policies can use different naming conventions.

​Policy Scope

​User Context Quick Reference

​Resource Context Quick Reference

​Policy stages

​Session stage

​Available inputs

​Available actions

​Request stage

​Available inputs

​Available actions

​Response stage

​Available inputs

​Available actions

​Standard input data

​Session object

​Request object

​Application object

​Client network object

​User object

​Connector object

​Resource object

​Column object

​Function object

​Space object

​HTTP object

​Native users

​Native user assignment

​Requested and assigned Native Users

​ClickHouse resources

​ClickHouse object

​Snowflake resources

​Snowflake object

​MongoDB resources

​MongoDB object

​SQL resources

​Example: Run all SQL statements in a transaction in order

​AWS resources

​AWS object

​ECS object

​EC2 object

​EKS object

​Kubernetes resources

​Kubernetes object

​SSH resources

​SSH object

​LLM resources

​LLM object

​Message object

​Content part object

​Tool object

​Tool call object

​Example: Rewrite request headers

​Example: Redact SSNs from request messages

​Example: Block specific tool calls

​MCP resources

​MCP object

​Example: Block a specific tool

​Device

​Device info object

​Hardware info object

​Software info object

​AI agents

​Agent object

​Example: block Claude Code in YOLO mode

​Policy Input Retention

​Extending Policies with External Data

​Legacy Stage Names

Policy Scope

User Context Quick Reference

Resource Context Quick Reference

Policy stages

Session stage

Available inputs

Available actions

Request stage

Available inputs

Available actions

Response stage

Available inputs

Available actions

Standard input data

Session object

Request object

Application object

Client network object

User object

Connector object

Resource object

Column object

Function object

Space object

HTTP object

Native users

Native user assignment

Requested and assigned Native Users

ClickHouse resources

ClickHouse object

Snowflake resources

Snowflake object

MongoDB resources

MongoDB object

SQL resources

Example: Run all SQL statements in a transaction in order

AWS resources

AWS object

ECS object

EC2 object

EKS object

Kubernetes resources

Kubernetes object

SSH resources

SSH object

LLM resources

LLM object

Message object

Content part object

Tool object

Tool call object

Example: Rewrite request headers

Example: Redact SSNs from request messages

Example: Block specific tool calls

MCP resources

MCP object

Example: Block a specific tool

Device

Device info object

Hardware info object

Software info object

AI agents

Agent object

Example: block Claude Code in YOLO mode

Policy Input Retention

Extending Policies with External Data

Legacy Stage Names