An AI agent needs to read from your production database. Something has to stand between them. The market offers two architecturally distinct answers to that requirement, and the difference between a data-layer proxy and an context-aware proxy determines which failures you can actually prevent.
Both deploy inline. Both enforce least privilege. Both are now marketed with the vocabulary of AI agent security. Underneath, one of them reads the contents of your queries and the other reads the identity and context of the caller.
Choosing the wrong one is not usually a performance problem or a cost problem. It is a coverage gap that shows up during an incident.
This page explains how each architecture works, what each can and cannot enforce, and how to tell which one your risk actually requires.
A data-layer proxy parses wire protocols to inspect and rewrite the contents of requests and responses — masking columns, filtering rows, blocking queries. A context-aware proxy authenticates the caller and authorizes each request against context. One governs content; the other governs access.
Non-human access has outgrown the controls designed for it. 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 90% suffered an identity-related breach in the past twelve months.
Machine identities are projected to grow 77% over the following twelve months and AI agent identities 85%, per Help Net Security's coverage. Palo Alto Networks separately reports that 96% of organizations have human identities operating with access far beyond what their roles require, and that 61% of privileged access requests are fulfilled with standing privilege rather than granted on demand.
The credential sprawl underneath is independently documented. GitGuardian's fifth annual State of Secrets Sprawl, published March 2026, reports approximately 29 million secrets detected on public GitHub in 2025 — a 34% year-over-year rise — and an 81% increase in leaked AI-service credentials, to 1,275,105.
Agents introduce a failure mode that service accounts never had. A service account does the same thing every day. An agent decides what to do based on text it reads at runtime, which means an attacker who controls that text partially controls the agent. CVE-2025-6514 demonstrated the shape of this: a CVSS 9.6 (Critical) vulnerability in the mcp-remote client let an untrusted MCP server trigger OS command execution on the connecting machine, across versions 0.0.5 through 0.1.15.
The Model Context Protocol specification explicitly leaves security enforcement to the implementor. Proxies are the implementation. Which kind you choose decides what you can enforce.
A data-layer proxy — also called a protocol-aware proxy — terminates the connection and parses the application wire protocol itself. Not TCP. The actual Postgres, MySQL, MongoDB, or Snowflake protocol, down to the statement.
Because it understands the protocol, it can act on the contents:
Parse the request → the proxy reads the SELECT statement and identifies the tables and columns it touches
Evaluate policy against the payload → it checks whether this identity may see a column labeled ssn or email
Rewrite inline → it modifies the query, or nullifies columns in the response, before either side sees the change
Log with query-level detail → the audit record contains the statement, not just the connection
The characteristic capability is masking. An analyst and an administrator run the identical query and receive different values, with no change to the application, the ORM, or the driver.
What it cannot do: reason about anything absent from the protocol. Device posture, the human who delegated authority to an agent, and the broader session context are not fields in the Postgres wire protocol, so they are not available to the decision.
A context-aware proxy (sometimes called an identity-aware proxy) sits in front of the resource and makes a fresh authorization decision on every request, based on who is calling and under what conditions. It implements the BeyondCorp model: no implicit trust from network position, and no long-lived session that assumes trust established once still holds.
Authenticate the caller → the proxy verifies identity against the identity provider before any traffic reaches the resource
Resolve context → group membership, device posture, time, origin, request path, session claims, and any other external context provided
Evaluate policy per request → every single request is authorized independently, not just the first one
Pass or deny, then log → permitted requests reach the resource carrying verified identity; everything is recorded
For agents, the decisive capability is attribution. A well-implemented context-aware proxy binds an agent's actions to the verified human identity that authorized them, so the audit trail contains a delegation chain rather than an anonymous authenticated connection.
What it cannot do: rewrite the contents of a response. A context-aware proxy decides whether a request happens. It does not mask a column inside the result set.
Data-layer proxy | Context-aware proxy | |
Question answered | What should this query return? | Should this actor make this request? |
Operates on | Wire protocol payloads | Identity and request context |
Policy inputs | Statements, tables, columns, data labels | Identity, group, device, time, origin, path, claims |
Signature capability | Inline masking and query rewriting | Per-request authorization with identity attribution |
Agent identity | Authenticated connection | Delegation chain back to a human |
Coverage | Databases and supported protocols | Applications, services, Kubernetes, SSH, MCP |
Blind spot | Context outside the protocol | Contents of the payload |
Example products | Formal.ai, Varonis DAM | Pomerium, Cloudflare Access, Google IAP |
Scenario one: the over-broad query. An analyst with legitimate database access runs a query that returns a column of customer national ID numbers. The access was authorized. The exposure was not. A data-layer proxy prevents this by nullifying the column; a context-aware proxy does not, because nothing about the request was unauthorized.
Scenario two: the hijacked agent. An agent processes a support ticket containing injected instructions and begins issuing requests nobody sanctioned. A context-aware proxy prevents this by evaluating each request against what that agent's authorizing user is permitted to do, denying anything outside it and recording who the agent was acting for. A data-layer proxy sees a well-formed query from an authenticated connection and masks a few columns of a request that should never have been made.
Both are real. They are different failures, and they need different controls. The difference in severity is worth noting: the first is an over-disclosure within an authorized session; the second is an attacker executing operations through your infrastructure.
The phrase "the agent acts on behalf of a user" is used loosely enough to be meaningless. It is worth being concrete, because this is the capability that separates the two architectures and the one most likely to be overstated in a demo.
In a weak implementation, an agent holds a credential — an API key, a service account, a long-lived token. It authenticates as itself. The audit log records that agent-prod-07 ran a query at 14:32. If three engineers and an automated workflow can all invoke that agent, the log cannot tell you which of them caused the action, and incident review stalls immediately.
In a strong implementation, the chain is preserved end to end:
The user authenticates to the identity provider → the proxy receives a verified identity, not a shared secret → the human is established before the agent does anything
The agent's session is bound to that identity → the agent does not hold independent standing authority → revoking the user revokes the agent
Each tool call is authorized against the user's permissions → the agent cannot exceed what the human could have done directly → a compromised agent inherits a bounded blast radius rather than a service account's
Context is evaluated per request, not per session → device posture, time, and origin are checked continuously → a session that was safe an hour ago is not assumed safe now
Every action is logged with both identities → the record names the agent and the authorizing human → incident review starts with a name instead of a hostname
The test is simple and worth running in any evaluation: trigger an agent action, open the audit log, and see whether a human appears in the record. If not, the delegation chain does not exist regardless of how the capability was described.
Pomerium is an open-source context-aware proxy released under Apache 2.0. It authorizes every request against context rather than establishing trust once at a tunnel, and for agentic workloads it binds each agent action to a verified user identity — the delegation chain that data-layer proxies structurally cannot produce. Because the full stack including the control plane is self-hostable, it deploys in regulated environments where a vendor-operated control plane in the request path is disqualifying. See Pomerium's agentic access gateway for the implementation, and continuous verification for how per-request evaluation works in practice.
Ask what your top risk actually is, phrased as a sentence.
"Someone with legitimate access will see data they shouldn't." That is a payload problem. Start with a data-layer proxy.
"Something will act with authority nobody granted it." That is an access problem. Start with a context-aware proxy.
"Both." Sequence them. Access control is the prerequisite: masking a column for an agent that should never have held a database session is a second line of defense against a failure that already occurred. Establish who may act, then constrain what a permitted action returns.
Three practical signals point toward the identity layer first:
Your access surface includes more than databases — internal apps, Kubernetes, SSH, MCP servers
You need to answer "who authorized this agent to do that?" during an incident review
You operate in an environment where a vendor-managed control plane cannot sit inline on production traffic
Two point toward the data layer first:
You have a named regulatory requirement for field-level masking under HIPAA, PCI DSS, or GDPR
Your production access is dominated by analysts and BI tools rather than services and agents
ZTNA is the market category context-aware proxies sit in, usually sold as VPN replacement. The proxy is the enforcement mechanism; ZTNA is the architecture around it.
Database activity monitoring observes and records database access. Traditional DAM is detective rather than preventive — it tells you what happened. Data-layer proxies are the preventive evolution of it.
CASB and DSPM operate on discovery and posture. They find sensitive data and report on exposure but do not stand inline on the request path, so neither prevents an action in the moment.
Vendors are often shelved under the wrong heading in this taxonomy. For a worked example of two specific products on either side of the line, see Pomerium vs Formal; for the wider field, see our guide to Formal.ai alternatives.
API gateways authenticate and rate-limit at the application layer but generally lack both context-aware per-request authorization and payload-level data policy.
Do I need both a data-layer proxy and a context-aware proxy? Only if you have both a payload governance requirement and an access control requirement that genuinely differ. Many teams discover their masking requirement dissolves once access is properly scoped — the agent that should not see the column should not have reached the database. Start with access control and add payload governance if a specific control still has no owner.
Can a context-aware proxy mask database columns? No. Context-aware proxies make access decisions; they do not parse SQL or rewrite result sets. Field-level masking requires a proxy that understands the database wire protocol.
Which architecture is better for securing MCP servers? Context-aware proxies map more directly to the MCP threat model, where the central risk is an agent being induced to take actions its user never authorized. Data-layer proxies can strip fields from tool call responses, which is useful but addresses disclosure rather than unauthorized action.
Is a protocol-aware proxy the same as a data-layer proxy? Yes, the terms are used interchangeably. Both describe a proxy that parses application wire protocols rather than passing TCP through, enabling decisions based on request and response contents.
Does adding a proxy slow down database queries? Both architectures add latency, typically in the single-digit millisecond range at median for well-implemented proxies. Data-layer proxies do more work per request because they parse and potentially rewrite payloads. Benchmark against your own workload rather than trusting a vendor number.
Where does the agent's identity actually come from? This is the question to press vendors on. In some implementations the agent presents a static credential and is treated as a service account — which means the audit log cannot tell you which human's request produced an action. In others, the agent's session is bound to an authenticated user and every action inherits that attribution. Only the second supports meaningful incident review.
The architecture you choose determines the incidents you can prevent rather than merely record. For agentic workloads, the failure that matters most is an agent acting with authority nobody granted — and that is an identity and authorization decision, made before any query is parsed.
Read the Pomerium MCP documentation to see per-request authorization with verified agent identity running against a real MCP server.
Stay up to date with Pomerium news and announcements.
Embrace Seamless Resource Access, Robust Zero Trust Integration, and Streamlined Compliance with Our App.
Use Cases
Quicklinks
Stay Connected
Stay up to date with Pomerium news and announcements.
