Row-Level Security Enforcement at Every Agent Hop in Enterprise Pipelines

Row-level security in enterprise agent pipelines must hold at login and every subsequent handoff. Permission-aware multi-agent orchestration for large enterprises needs checks that user and agent identities are verified, that delegation is scoped, that policy is checked before queries run, and that results are checked before they reach another agent. Database filters are still needed, but they cannot protect the right boundary when downstream tools get the wrong identity.

Why row-level security fails at agent handoffs, not at the front door

A user signs in, an orchestrator delegates to a sub-agent, and the sub-agent queries a database under a generic service account. The login was valid. But the database now sees the service account’s permissions, so a successful authentication has led to access the user may never have been allowed. Nothing in that sequence requires a failed password check or a breached perimeter. The boundary disappears during an ordinary handoff.

A server with broad authority performs an action for someone whose permissions are narrower, without checking that difference. Wiz Research describes MCP deployments as giving the model runtime ambient authority across multi-hop trust chains, meaning access is available without a fresh, user-scoped decision at each step. Additional agents widen that exposure because they can chain tools and pivot between services. A security model built around human login behavior does not account for those delegated actions.

What MCP's architecture actually delegates to operators on security

The Model Context Protocol sets out a standard way for hosts to find and use tools, resources, and prompts. It does not define an enterprise role-based access control model, require authentication in every deployment, or specify how each request maps to a verifiable enterprise identity. Those decisions remain with the operator. Where authorization is used, the MCP server acts as a resource server, validating tokens issued by a separate authorization server. That separation leaves the identity chain dependent on how each link is implemented.

The protocol’s three primitives also expose different routes into an agent’s work. Tool definitions enter model context before any user action, resources supply the data it reads, and prompts can contain pre-seeded malicious instructions. Authentication alone does not tell the operator how much to trust those inputs. Wiz Research found MCP servers in the majority of observed cloud environments in early 2026, including internet-facing endpoints. The operational consequence is straightforward. Deploying a standard connection protocol does not deploy the enterprise permissions needed to govern what flows through it.

The specific ways identity drops or gets overridden between hops

The simplest failure is a generic service account with broad access to customer, revenue, and transaction tables. Every downstream hop inherits the same credential, without user-specific row filters, column masking, or purpose controls. If a sub-agent’s token identifies only the orchestrator, downstream systems apply the orchestrator’s broader permissions, exceeding the originating user’s narrower scope.

Tool poisoning attacks the decision before the query. The Postmark MCP incident in September 2025 involved a package that passed standard review at installation, then received a malicious update, version 1.0.16. It sent a hidden copy of every email an agent sent to a domain under the attacker’s control. Invariant Labs demonstrated a different route in April 2025, when a poisoned math tool read SSH keys and exfiltrated them encoded in a math function parameter, without user interaction or a persistent trace. Neither example required defeating a database row predicate.

Connectors create another route around the intended boundary. Without egress allowlists and URL scheme validation, tool-supplied URLs can direct server requests to internal endpoints or cloud metadata services. Shadow MCP servers bypass the managed path altogether when developers run local servers without enterprise authentication or logging.

Why database-layer RLS alone cannot close these gaps

Database RLS enforces the identity it receives. If that identity belongs to a broad service account, the engine can enforce its policy correctly while still exposing rows the human should not see. A regional filter also needs the session to get the correct regional attribute. The database cannot infer the missing user binding from the fact that an agent issued the query.

An agent can combine permitted columns or aggregate results to derive information the filter was not designed to protect. A runtime alert may also come after a query has already returned data. Wiz Research describes the dangerous combination as untrusted input, access to sensitive data, and the ability to act. Database RLS addresses only the data-access leg. Enforcement must also shape the query before generation and inspect its result afterward.

How do you keep row-level permissions intact through every agent hop?

A layered pipeline begins by authenticating the user, agent, tenant, and purpose. Each agent receives a unique service principal with short-lived credentials. When the orchestrator delegates, the token must identify both the agent and the originating user so downstream systems apply the stricter permission set. Delegation must not expand the user’s authority.

The next layer mediates access to raw columns by resolving the user’s intent into approved metrics and data objects. Compile-time policy then applies role-based and attribute-based controls, row predicates, and column masking before SQL generation. Query validation then checks that the plan uses tables that are approved, has the row filters it needs, and keeps restricted columns out of projections.

The database then receives a policy-compliant query and applies its own row-access rules using the bound session attributes. An agent requesting EMEA and APAC rows through an EMEA-scoped session sees only EMEA rows. Before the result returns to model context, a response guard checks for derived disclosure and aggregation leakage. Immutable, tamper-evident logs keep a record of the agent and user behind each action all the way through the flow. For destructive or irreversible actions, including database deletions, financial transactions, bulk record changes, and outbound data transfers, human approval remains required even when the automated layers permit them.

The MCP gateway as the practical enforcement chokepoint

A centralized MCP gateway gives security teams one inventory and one policy enforcement point rather than separate configurations spread across dozens of servers. Its role is to concentrate protocol-level controls alongside the query and response layers. An agent-specific tool allowlist limits both discovery and invocation, so tools outside the agent’s scope never become options for it to use. Scope is enforced outside the model’s reasoning.

Team-scoped provisioning makes that control usable in daily work. Administrators can give Sales CRM read/write and Slack tools, Engineering GitHub, Jira, and CI tools, and Finance accounting read tools. Developers discover approved servers through an internal portal that replaces distribution of raw server URLs. Microsoft Entra Agent ID, made generally available in April 2026, shows how enterprise identity infrastructure is starting to give agents identities of their own. That identity layer helps the gateway decide, and an internal registry lists which servers are approved to take part. With both in place, shadow servers still need to be kept from going around the managed path.

Non-human identity management as a prerequisite for hop-by-hop enforcement

Agents need identities built for automated workloads. A unique service principal makes each agent distinguishable, while explicit user binding identifies whose permissions govern its work. Both identities are needed at the same time. Short-lived credentials should rotate on cycles of minutes to hours rather than the 90-day cycles common for service principal and machine credentials. Shorter lifetimes avoid relying on long-standing credentials throughout the chain.

Each server must reject tokens not explicitly issued for it, preventing a token accepted by one MCP server from being replayed against another. MCP security guidance identifies client registration checks, including URI validation, redirect checks, and network-level IP validation, as controls against spoofing and stale client entries impersonating legitimate agents. The NSA’s Artificial Intelligence Security Center released its MCP Cybersecurity Information Sheet on May 20, 2026, placing these deployment concerns within formal security guidance.

Governing the server supply chain that feeds the pipeline

The Postmark incident exposes a limit of installation-time approval. A package can pass review and later change what an agent does through an update delivered to installed instances. The approved version is not the deployed contract forever. If a tool description changes, the model may reason against instructions the security team never approved, before any database policy has a chance to operate. Server provenance therefore belongs within access governance.

The practical control is to pin dependencies with hash-based verification rather than version ranges, and to hash tool descriptions at deployment. Those description hashes should be checked on every tools/list response before the descriptions go into model context. The controls cover different forms of change. Description checks catch changes to metadata, while dependency pinning stops reviewed software from being quietly replaced as it was in the malicious update.

The public ecosystem makes internal governance more important because its registries are fragmented, with no single authoritative index. An enterprise registry needs software bill of materials tracking, pinned dependencies, and automated vulnerability scanning. Each time a new server is registered, it should go through security review. Ownership and lifecycle controls must also account for deprecated servers that remain active and malicious packages posing as legitimate tools, so approval of installed tools governs what can run.

Making the same permissions travel across every surface agents run on

An MCP server built for a CRM can serve Claude, ChatGPT, Cursor, or a custom interface. That portability is useful only if the user’s permissions survive the change of host. The client must not become the permission boundary. Rebuilding row filters separately for each surface creates another place where user identity can be dropped or scope can drift, even when every implementation began with the same policy.

Permissions must be bound to the server and the identity token, with user-scoped claims governing access regardless of the invoking client. Team-scoped servers can inherit permissions from source systems, so a Sales CRM server applies the same row filters in Claude Desktop, Cursor, and a Slack integration. The permissions do not need a separate implementation for each surface. Salesforce’s hosted MCP servers, extended with custom servers that respect the org’s sharing and security model, illustrate this principle. Custom servers make chosen tools and prompts available under the org’s security rules, so the access boundary stays the same wherever the agent runs.

The audit trail as the only way to verify enforcement actually held

An allow decision does not prove the whole chain stayed within scope. Verification requires records of authentication, authorization, and data flow that can reconstruct what each hop did. Every action needs dual attribution to the originating user and the acting agent. A service-principal-only log cannot establish which human’s row permissions should have applied. Immutability and tamper-evidence protect the record needed to distinguish correct enforcement from a silent failure.

The MCP 2026-07-28 specification removes persistent protocol sessions, so related actions can no longer rely on session grouping alone. Every request needs enough metadata to be independently attributable. Governed registries add to that upstream record by keeping version control, records of who owns the servers, access scoping, and a history of who approved tool-description changes. This connects the data-access trail to the server contract under which the agent acted.

The record must show who approved an action, which agent performed it, on behalf of which user, and at which hop. It must also connect that action to the permissions and server version that governed it. Without that record, there is no way to verify continuous enforcement. There is only hope that the handoffs preserved it.