The PAM solution for engineers and AI agents

A classic PAM tool is built around a vault: store the password of each privileged account, check it out to an admin, rotate it afterward. Formal PAM is privileged access management software that takes the credential out of the user’s hands entirely. Engineers and AI agents connect with their own identity, and the Connector decides, query by query and session by session, what that identity may do.

How does the Formal PAM solution work?

Formal PAM runs on the Formal Connector, a protocol-aware reverse proxy you deploy as a container in your own infrastructure. Every connection to a protected resource goes through it. The Connector authenticates the identity, evaluates policies on the request and the response, forwards what’s allowed, and logs the session.

The Control Plane, hosted by Formal, manages configuration and shows logs, but it can’t interact with your data: only the Connector can. The Connector detects the wire protocol each client speaks, so one deployment can front Postgres, Snowflake, SSH, Kubernetes and internal HTTP APIs, without exposing them publicly.

How do users connect without shared credentials?

Each person or agent authenticates as a Formal identity: a human user, usually provisioned from your identity provider through SSO or SCIM, or a machine user. Each user has their own rotating access token, valid for 7 days by default. Upstream, the Connector signs in as a Native User: a password, an SSH key, a Snowflake key, cloud IAM or a kubeconfig, picked per identity with a CEL expression. Formal identities never know or send these upstream credentials.

Do engineers have to change their tools?

No. Engineers keep psql, mysql, mongosh, ssh and kubectl. formal connect starts a localhost listener for databases, or updates ~/.ssh/config and ~/.kube/config, and injects Formal credentials so users never type them. Database clients can also point straight at the Connector with a Formal username and access token.

Database access management: control at the query, not the connection

For databases, privileged access has to be governed past the login. The Connector parses each statement, so a request policy can check the statement type, the environment or the user’s groups before the query runs. Response policies see each returned row and its columns, and can mask or filter data before it reaches the client. That’s database access control where the risk sits.

Formal PAM covers Postgres, MySQL, MariaDB, Redshift, MongoDB, Snowflake, BigQuery, ClickHouse, DynamoDB and Redis. This masking policy from the enforcement docs hides the username part of every column labeled email_address:

package formal.v2

import future.keywords.if

response := {
  "action": "mask",
  "type": "redact.partial",
  "sub_type": "email_mask_username",
  "columns": columns
} if {
  columns := [col |
    col := input.row[_]
    col["data_label"] == "email_address"
  ]
  count(columns) > 0
}

Labels come from the Data Inventory, where the Data Discovery Satellite classifies columns on a schedule, so the policy follows the data rather than a list of tables. When policies conflict, Formal resolves toward least privilege: block beats allow, and the strictest mask wins.

Run new masking policies in dry-run first. Formal doesn’t validate mask names when you save a policy, and an unknown subtype leaves the value unmasked. Dry-run logs what a policy would do on real traffic without enforcing it.

Each session keeps the full query text, rows affected and policy actions, so the database proxy that enforces access also gives you database activity monitoring. Masking has its own data masking page; setup lives on the Postgres and Snowflake pages.

How does Formal handle SSH and Kubernetes access?

SSH and AWS SSM (EC2 and ECS Fargate) go through the Connector, with a Native User holding the SSH key or certificate. Session policies run at connection time and can read the remote command. The Connector provides session recording for every SSH session: the Sessions page replays the terminal, lists the commands and summarizes what happened. See the SSH page.

For Kubernetes, a policy runs on every API request, with the namespace, kind, verb and subresource as input, so you can block kube-* namespaces or require MFA for kubectl exec. With impersonation, the Connector adds Impersonate-User and Impersonate-Group headers so cluster RBAC sees the real user (Kubernetes user impersonation). kubectl exec and attach are recorded; other requests, including port-forward, are logged only. More on the Kubernetes page.

That’s privileged session management with enforcement attached. Session monitors describe a scenario in plain English, such as a download piped to bash. When the AI analysis detects it, a policy can suspend the session or quarantine the user. Monitors need an AI provider configured on the Connector.

Just-in-time access and zero standing privileges

Zero standing privileges means nobody holds production access until they need it. In Formal, that’s a default policy, such as “no writes to production”, plus a policy suspension: an exemption for one user or group, one-off or time-bound, with an optional CEL condition and an expiry. Delete it to revoke immediately; expired suspensions are removed automatically.

Employees can request an exception in the Catalog, a workflow can run the request and approval in Slack, or your tooling can call the API. Approvals live in the platform (Workflows); the concept is on the just-in-time access page. At Cursor, per its case study, “Engineers request just-in-time access for a specific operational need instead of holding permanent production permissions.”

Privileged access management for AI agents

Agents need the same controls as engineers, plus a record of which person they acted for. In the Devin guide, Devin authenticates with a short-lived OIDC token and its machine user is blocked by default. The requester approves in Slack, which creates a suspension for that requester and that session. Devin mints a short-lived federation token, connects with psql, and the Connector logs the session with the requester as the end user.

Cursor’s Cloud Agents connect through a dedicated Formal identity with limited access, and end-user identity propagation adds the employee who started the task (Cursor case study). The same Connector runs Formal’s MCP gateway; for agents on laptops and in sandboxes, see Formal Endpoint.

What should you look for in PAM tools?

Whether you call them privileged access management solutions, privileged access management tools or PAM software, ask every candidate these questions. Here’s how Formal answers each:

• Does the user ever hold the credential? No: the Connector holds it as a Native User.
• Do people keep their own clients? psql, ssh and kubectl work through the Connector.
• Can policy act inside the session? Formal blocks, rewrites, filters and masks individual queries.
• Are sessions recorded and searchable? SSH and kubectl exec sessions are recorded with a risk score; every query and command is logged and can go to your SIEM.
• Does access expire on its own? Suspensions are one-off or time-bound.
• Are AI agents covered? Machine users, OIDC federation and end-user attribution apply the same policies.
• Where does the data path run? In your infrastructure; the Control Plane can’t interact with your data.
• Can you manage it as code? Yes, with the Terraform provider.

Two limits to weigh. Formal doesn’t document automatic rotation of upstream passwords: you update a Native User’s secret yourself, or fetch it at connection time with a hook from your secrets manager. And Kubernetes access requires the Formal Endpoint. If you’re comparing PAM products side by side, we publish pages for Teleport and StrongDM.

Which teams use Formal as their PAM tool?

Cursor replaced its homegrown access proxies with Formal Connector and secures SSH, PostgreSQL, Redis, ClickHouse, and Kubernetes through it. Notion governs developer access across 100+ RDS instances with short-lived credentials and group-based policies, and rolled it out in under a week.

“We did a vendor bakeoff between a number of products and Formal came out on top.”

Daniel Pyykonen, Head of Security Engineering @ Notion

Modern Health automated user provisioning and deprovisioning across 20+ Postgres databases and added real-time masking and redaction for sensitive data.

“Formal’s solution, with its robust data governance model and deep integrations into Modern Health’s IDP, allowed database access to become more secure and more scalable for internal users that needed access.”

Michael Hensley, Head of Cyber Security at Modern Health

ManoMano enforces policies on Okta groups across Metabase, Snowflake and Postgres, and found former employees with active Metabase jobs. Read the Notion, Modern Health and ManoMano stories.