Both sit at the MCP boundary, federate multiple servers, and enforce access tied to identity, with a unified audit log. The difference that matters is the shape of enforcement and the deployment model. agentgateway gates which tool an identity may call; PolicyLayer evaluates the arguments inside the call and adds approval gates. agentgateway is self-hosted open-source infrastructure; PolicyLayer is a hosted control plane. Here is where each one fits.
agentgateway gates the tool and the identity, across MCP, A2A, and LLM traffic, self-hosted. PolicyLayer gates the contents of the call, with approvals, hosted. Genuine competition, different depth and form factor.
PolicyLayer is the hosted gateway your MCP traffic runs through. Connect your servers and every tool call is checked against deterministic, deny-by-default policy before it executes, with rules that read the call's argument values, plus human approval gates and tool-action spend limits. There is no data plane to run and no self-hostable binary. Recommended policy ships pre-classified across 220,000+ catalogued tools.
Solo.io agentgateway is an open-source (Apache 2.0), Rust-based gateway that federates many MCP servers behind one endpoint and also routes A2A and LLM traffic across providers. Its authorisation is CEL-based RBAC over MCP method invocations (allow-by-default until you add a policy), using the tool name and JWT claims; unauthorised tools are filtered from list responses. It supports JWT, API keys, and MCP OAuth with secure token exchange, and the Solo Enterprise distribution adds cryptographically verifiable audit trails and supply-chain protections.
A self-hosted, multi-protocol data plane, versus a hosted, argument-level policy layer.
| PolicyLayer | Solo.io agentgateway | |
|---|---|---|
| Enforcement shape | Deterministic rules that read the call and its arguments | Deterministic CEL RBAC over the tool name and identity claims |
| Granularity | Per argument (allow refund_payment only when amount is under $100) | Per tool and identity; the documented CEL context does not appear to expose argument values |
| Approvals | Human approval gates that pause a call until sign-off | Not documented as approval gates; Enterprise documents secure elicitation |
| Protocol coverage | MCP-native | Broader: MCP, A2A, and LLM provider routing, with failover and load balancing |
| Spend limits | Tool-action spend limits (for example, total refund value) | LLM-token-centric: token-based rate limits and denial-of-wallet protection |
| Identity | Per-person scoped tokens, attributable per call | JWT, API keys, MCP OAuth, with secure token exchange to downstream SaaS |
| Audit | Every call logged with the tool, its arguments, and the decision | Unified log; Enterprise adds cryptographically verifiable audit trails |
| Supply chain | Per-tool risk classification across the catalogue | Enterprise supply-chain protections: tool fingerprinting, versioning, poisoning defence |
| Deployment | Hosted control plane; no data plane to run, no air-gapped option | Self-hosted Rust data plane; standalone binary or Kubernetes Gateway API; no public hosted SaaS advertised |
| Best fit | Teams whose risk lives in the values agents pass, who want hosted enforcement | Kubernetes-native platform teams wanting one self-hosted data plane for agent traffic |
Allow refund_payment only when the amount is under a limit, not just decide whether the tool can be called at all.
Pause a call until a person signs off, which a CEL allow or deny decision at call time does not provide.
Stand up a policy point and route Claude Code, Cursor, and Codex through it, without running a data plane, a mesh, or xDS and YAML config.
Cap the total value of an action like refunds, distinct from LLM-token budgets.
Open-source Rust infrastructure you run yourself, on-prem or air-gapped, is a requirement.
You want one data plane covering MCP, A2A, and LLM provider routing, with failover and load balancing.
Tool-server fingerprinting and versioning, and standards-based token exchange propagating user identity to downstream SaaS.
This is genuine competition, and the two can also sit together. agentgateway's connectivity, A2A handling, LLM-token spend governance, and supply-chain protections address concerns largely outside PolicyLayer's scope. A team could run agentgateway for transport and connectivity and still want PolicyLayer-style per-argument enforcement and approvals layered on the calls.
Whatever your agents touch, the same engine, audit, and access model is doing the work underneath every rule you write.
Rules run as code, not model judgement: argument-level conditions, quotas, deny-by-default. The same call gets the same decision every time.
Writing policies →Your security or compliance team writes and attaches policy without ever holding the upstream credentials or grant tokens.
Roles →Every call is logged with its decision and the rule that fired, attributed to the identity, in an append-only record. Argument values are redacted, never stored.
Logs & security →Upstream secrets are encrypted at rest and injected by the gateway. The agent only ever holds a scoped token.
Logs & security →Every person and agent connects with its own scoped grant. Rotate or revoke any one of them instantly, without disrupting the rest.
Core concepts →Hosted gateway. Point your clients at it, register a server, issue a token. Nothing to install.
Quick start →agentgateway's CEL authorisation gates the tool name, target, and identity claims; the documented CEL context does not appear to expose the argument values inside a call. PolicyLayer evaluates those arguments deterministically before the call runs.
No. PolicyLayer is a hosted control plane with no data plane to operate. agentgateway is a self-hosted Rust data plane you run as a binary or on Kubernetes; there is no public hosted SaaS advertised.
Yes. It also routes A2A and LLM provider traffic with failover and load balancing, which is broader protocol coverage than PolicyLayer. PolicyLayer is MCP-native and focuses on per-call policy depth.
Yes. Run agentgateway for transport, connectivity, and multi-protocol routing, and PolicyLayer for argument-level enforcement and approval gates on the tool calls.
Deterministic, deny-by-default policy on every MCP tool call: argument-level rules, approval gates, per-identity scopes, and a tamper-proof audit log. Hosted, no data plane to run. Live in minutes.
Instant setup, no code required.