Pomerium vs Formal.ai: Agentic Access Control Compared

Your AI agents are in production, and something has to decide what they are allowed to do. Two proxies come up in that evaluation, and teams comparing Pomerium vs Formal.ai usually discover partway through that they are not evaluating the same category of product.

Formal.ai is a protocol-aware proxy that inspects and rewrites the contents of database queries and tool calls. Pomerium is an context-aware proxy that authenticates every actor and authorizes every request against context. Both sit inline and enforce least privilege, however, they enforce it at different layers of the stack, against different questions.

This page is a direct technical comparison for security engineers and platform teams choosing between them, or deciding whether they need both. It covers architecture, policy models, licensing, deployment, and the specific scenarios where each one is the stronger choice.

All product details are drawn from public documentation and vendor sites as of September 2026.

What is the difference between Pomerium and Formal.ai?

Pomerium is an open-source context-aware proxy that authorizes every request based on who the actor is and what context they are in. Formal.ai is a closed-source protocol-aware proxy that inspects the payload of database queries and tool calls to mask or rewrite the data returned. Pomerium governs access; Formal.ai governs content.

Why this comparison keeps confusing people

While both companies describe themselves as proxies enforcing least privilege for AI agents, their architectures take a different approach to the problem.

The clearest way to separate them is by the question each product is built to answer.

Formal.ai answers: what is inside this query, and what should come back? It parses the Postgres wire protocol, sees that a SELECT touches a column labeled ssn, and nullifies that column before the response reaches the caller.

Pomerium answers: should this actor be making this request at all? It verifies the agent's identity, resolves the human who authorized it, evaluates device posture and context of the request, and allows or denies the request before it reaches the resource.

Evaluation criteria

We compared both products against the criteria that actually change the outcome of a security review:

• Enforcement layer — where in the stack the decision happens

• Policy model — what inputs the policy engine can reason about

• Identity handling — how non-human actors are identified and attributed

• Licensing and source availability — what you can inspect, fork, and self-host

• Control plane trust — who operates the system that sits inline on your traffic

• Protocol coverage — what the proxy can terminate and understand

• Evaluation path — how long it takes to get to a working proof of concept

Pomerium vs Formal.ai at a glance

What Formal.ai does well

Formal.ai is a single stateless Go binary deployed in the customer's VPC that natively parses more than fifteen wire protocols, including Postgres, MySQL, MongoDB, Snowflake, SSH, Kubernetes, HTTP, and MCP.

Two things about it are interesting:

Nine inline actions across three evaluation stages. Formal.ai evaluates policy at the session, request, and response stage, with actions ranging from allow and block through mask, filter, rewrite, quarantine, and impersonate. That range of inline response-path actions is broader than most proxies offer.

Policy backtesting. Formal.ai can test a proposed policy against up to 31 days of historical logs before it is enforced, showing which queries would have been blocked or masked. This directly addresses the strongest objection to any inline proxy: that it will break production.

What Pomerium does well

Pomerium is an open-source context-aware proxy released under Apache 2.0, implementing the BeyondCorp model: no implicit network trust, and a fresh authorization decision on every single request rather than a session established once at a tunnel.

Agent identity has provenance. This is the difference that matters most in agentic deployments and the one that is hardest to retrofit. Pomerium ties every agent action back to the verified human identity that authorized it. An agent is autonomous, not anonymous. A data-layer proxy (e.g., Formal.ai) sees an authenticated connection; it does not see a chain of delegated consent, because that information never appears in the wire protocol.

One policy model across every actor. The same context-aware policy governs a human on a laptop, a CI/CD pipeline, an internal service, and an MCP client. Most of an enterprise's access surface is not a datastore, and splitting policy across two engines by actor type is how gaps appear.

Nothing opaque sits inline. The full stack is Apache 2.0 and self-hostable, including the control plane. For regulated buyers and large enterprises, running a closed binary inline on every production query, managed from a hosted control plane, is a threat vector.

You can evaluate it tonight. Pomerium publishes its pricing and its source. An engineer can stand up a working policy without a procurement conversation. With Formal.ai the calls to action are for a demo request.

It works where commercial SaaS cannot. Because Pomerium is self-hosted end to end with no vendor service in the request path, it is viable in federal, defense, and other high-security environments where a vendor-operated control plane is disqualifying.

The problem both products are responding to

The scale of non-human access is the reason this category exists at all.

Palo Alto Networks reports that, based on responses from 2,930 cybersecurity decision-makers for its 2026 Identity Security Landscape report, organizations now manage an average of 109 machine identities for every human identity, of which 79 are AI agents. The same source states that 91% of organizations already run autonomous agents in production and that 90% suffered an identity-related breach in the past twelve months.

Elsewhere, Palo Alto Networks reports that 96% of organizations have human identities operating with access far beyond what their roles require, while machine identities are projected to grow 77% over the following twelve months and AI agent identities 85%, according to Help Net Security's coverage of the report.

These are figures from a single vendor survey, and published machine-to-human ratios vary widely across vendors. Although the exact numbers may be directional, the direction is not in dispute.

The agent layer inherits every one of those problems and adds one more: an agent's behavior is determined partly by text it reads at runtime. The CVE-2025-6514 vulnerability in mcp-remote carried a CVSS score of 9.6 (Critical) and allowed an untrusted MCP server to trigger OS command execution on the connecting machine, affecting mcp-remote versions 0.0.5 through 0.1.15. The MCP specification itself leaves security enforcement to the implementor.

When Formal.ai is the better choice

Choose Formal.ai if your primary risk is what comes back in the response body:

• Your compliance requirement is column-level masking for HIPAA, PCI DSS, or GDPR, and you need it enforced without touching application code

• You are governing access to a large fleet of heterogeneous datastores — Postgres, Mongo, Snowflake, ClickHouse — and want one binary that speaks all of them

• Analysts connect to production through BI tools like Looker, Metabase, or Tableau and need row- and column-level restrictions applied per role

• The specific thing keeping you up at night is an agent pulling PII out of a production table into a model context window

If that describes your problem, Formal.ai solves it more directly than Pomerium does, and you should evaluate it seriously.

When Pomerium is the better choice

Choose Pomerium if your primary risk is who is acting and on whose behalf:

• You need every agent action attributable to a verified human identity for audit or incident response

• Your access surface spans web applications, internal services, Kubernetes, SSH, and MCP servers — not just databases

• You are in a regulated, federal, or air-gapped environment where a vendor-operated control plane inline on production traffic will not pass review

• You need to inspect, fork, or extend the enforcement layer rather than trust a closed binary

• You want to prove it works on your own before you start a procurement cycle

Three teams, three answers

Head of Security at a 200-person AI-native SaaS company. Engineers ship agents that touch production weekly, and the board is asking who approved what. The binding constraint is attribution during incident review, not masking — when an agent does something unexpected, the security team needs to name the human whose request produced it. Pomerium's delegation chain answers that question; a connection-level log does not.

Platform lead at a healthcare SaaS company under HIPAA. Analysts connect Looker to a production replica containing PHI, and the auditor wants field-level evidence that non-privileged roles never see identifiers. This is a payload requirement stated in regulatory language, and Formal.ai addresses it directly. The team should still expect a separate conversation about agent authorization, because masking does not constrain what an agent is permitted to attempt.

Systems integrator delivering to a federal customer. The deployment must run in a disconnected enclave with no vendor-operated control plane in the request path, and the source must be reviewable. This narrows the field before any feature comparison happens: Apache 2.0, self-hosted, no outbound dependency. Formal.ai is not a candidate here, not because of product quality but because of deployment model.

How to run a two-week evaluation

Feature matrices alone will not answer this, a short structured proof of concept will. These steps work for either product:

1. Pick one real resource, not a test fixture → choose a production-shaped database or MCP server that a real agent actually uses → synthetic environments hide the integration problems that decide the outcome

2. Write down the specific failure you are preventing → one sentence, naming the actor and the action → if the sentence is about who acted, you are testing access control; if it is about what came back, you are testing payload governance

3. Route traffic through the proxy without enforcement → observe-only mode first → you learn your actual access patterns, which are almost always broader than the team believes

4. Measure added latency against your own workload → p50 and p99, under realistic concurrency → vendor benchmarks are run on vendor workloads

5. Write the policy that expresses your sentence from step two → then try to violate it → a policy nobody has attempted to break has not been tested

6. Break something on purpose → have an engineer attempt an action the policy should deny → confirm both that it was blocked and that the log tells you who tried

7. Read the audit output as an incident responder would → open the log and try to reconstruct what happened → if you cannot answer "who authorized this," the product has not solved your problem regardless of what it blocked

Step seven is where these two products separate most visibly. Run it before you decide.

If you are still mapping the field rather than choosing between these two specifically, our guide to Formal.ai alternatives covers six options including StrongDM, Teleport, and Varonis. For the underlying architectural distinction, see data-layer vs identity-aware proxies.

Can you run both?

Yes, and for some architectures that is the correct answer. They are complementary rather than mutually exclusive: Pomerium decides whether the agent gets a session and which resources it can reach, and Formal.ai decides what the payload of a permitted database query is allowed to contain.

The question to ask before buying both is whether your datastore masking requirement is genuinely distinct from your access control requirement. For many teams it is not — the agent that should not see the PII column is an agent that should not have had access to that database at all, which is an identity decision, not a payload decision.

Verdict

Best for agent identity and authorization across a mixed access surface: Pomerium. The delegation chain from agent back to authorizing human is the control that data-layer proxies structurally cannot provide, and one policy engine across humans, services, and agents is easier to reason about than two.

Best for column-level data masking across many database protocols: Forma.ail. Wire-protocol parsing with inline rewriting is their core competence and they execute it well.

Best for regulated, federal, and air-gapped environments: Pomerium. Apache 2.0 licensing and a fully self-hosted control plane clear reviews that a proprietary vendor-operated control plane cannot.

Best for a fast, low-commitment evaluation: Pomerium. Open source, published pricing, no sales conversation required to test it.

Frequently asked questions

Is Pomerium an alternative to Formal.ai? Partially. Pomerium is a direct alternative for AI agent access control, MCP authorization, and identity-based policy enforcement. It is not a replacement for Formal.ai's column-level data masking, which operates on query payloads rather than access decisions.

Is there an open source alternative to Formal.ai? Pomerium is the closest open-source option for the access control and agent authorization side of Formal.ai's offering, released under Apache 2.0 and fully self-hostable. For the data masking side specifically, the open-source landscape is thinner — most column-masking implementations are features of commercial data governance platforms.

How much does Formal.ai cost? Formal.ai does not publish pricing. Every call to action on its site routes to a demo request, so cost is established through a sales conversation. Pomerium publishes pricing and offers a free open-source tier.

Does Formal.ai or Pomerium secure MCP servers? Yes, both do, but differently. Formal.ai proxies traffic between agents and MCP servers to strip fields and block tool calls. Pomerium authenticates the agent, ties it to a verified user identity, and authorizes each tool call against context-aware policy. See the Pomerium MCP documentation for the implementation.

Can Pomerium mask database columns? No. Pomerium makes access decisions rather than rewriting query payloads. If column-level masking inside a SQL response is a hard requirement, you need a data-layer tool for that specific control.

Which one is better for federal or defense deployments? Pomerium. Self-hosted, source-available deployment without a vendor-operated control plane in the request path is a practical requirement in most government environments. As of September 2026 we found no public sector offering or federal authorization listed on Formal.ai's website.

Getting started

The access control decision for agents is easier to make with a working example in front of you than a feature matrix. Pomerium's agentic gateway runs locally with a single command, authenticates every agent, binds it to a verified user identity, and logs every request — before you talk to anyone.

Read the Pomerium MCP documentation and stand up a secured MCP server in under ten minutes.