Comparison · agent governance · Solo.io

Solo.io, measured.

Q: What is Solo.io?

Solo.io builds cloud-native connectivity software and is known for its work on Istio. Its agent stack is agentgateway, an open-source proxy for MCP, agent-to-agent and LLM traffic with an enterprise build; Solo's ambient mesh distribution of Istio, where agentgateway runs as a waypoint; kagent, a Kubernetes-native agent runtime; and agentregistry, a catalog with approval workflows and discovery of agents on connected runtimes.

Q: Does Solo.io block agent actions at runtime?

Yes, for traffic on its path. agentgateway evaluates Allow, Require and Deny policies written in CEL on every request and MCP tool call that crosses it, and a denied call returns a 403 without stopping the agent. Prompt guards can mask PII and apply Microsoft Purview DLP on model traffic. The decision point is the gateway or a mesh waypoint, so an action that crosses neither is not evaluated.

Q: How does Solo.io identify the human behind an agent?

Through delegation. Its token service performs RFC 8693 on-behalf-of exchange, so a delegated call carries both the user and the agent identity and policy can reference both. An agent acting on its own is identified by its mesh workload identity, which names a service account and namespace rather than a person, and no owner field on an agent is documented. Agen carries one named accountable owner on every agent, wherever it was built, and attributes each action to that human.

Q: Can Agen.co run alongside Solo.io?

Yes. Agen does not require agent traffic to move off an existing gateway or mesh. It discovers agents agentlessly across five surfaces, judges every action against your policy in under 30ms, and resolves each verdict to a named accountable human, including agents that never join a mesh or route through a gateway.

Q: How is Solo.io priced?

Solo.io does not publish pricing; licence keys are issued by an account representative, with 30-day trial keys available. The enterprise gateway, the registry and Solo's Istio distribution are licensed separately, and the egress waypoint requires both the Istio and the gateway licence. Agen is priced per governed agent with no prerequisite tier.

Q: Where does Solo.io score better than Agen.co?

Two rows of sixteen outright, and four more are level. Network-layer enforcement goes to Solo.io through its ambient mesh, and so does ecosystem breadth, from open-source projects with foundation backing to integrations across LLM providers, MCP clients and agent runtimes. Level with us on single-call blocking, MCP tool governance, on-behalf-of delegation and deployment model.

Q: Does this cover agents that never go through a gateway?

That is the difference the table measures. Agen discovers agents agentlessly across identity provider, gateway, devices, cloud and registries, so an agent does not have to be routed, deployed through a registry or enrolled in a mesh to be found, owner-mapped and governed. Internal and customer-facing agents run on the same policy plane across endpoint, browser, gateway and cloud.

Q: How current is this comparison?

It is scored against vendor public documentation and re-scored on a schedule we hold ourselves to. Every published row is backed by at least one primary vendor source, all of which are listed on this page, so any row can be checked against the vendor's own docs rather than taken on trust.

Solo.io puts agent, tool and model traffic through agentgateway and its ambient mesh, and governs every request that crosses them in depth. This page scores that architecture against Agen.co across 16 capabilities, with the sources, the scoring ladder, the four rows that come out level and the two Solo.io wins all on the page.

Get the walkthrough Jump to the comparison

The short answer

Solo.io is agent connectivity infrastructure for Kubernetes. agentgateway proxies MCP, agent-to-agent and LLM traffic, evaluates Allow, Require and Deny policies in CEL on every request, and can run as a waypoint inside an ambient mesh.
Enforcement on the path is deep. MCP tool governance, single-call blocking, on-behalf-of delegation and self-hosted deployment all score level with ours.
Solo.io leads where its heritage is: network-layer enforcement through the ambient mesh, and an ecosystem of open-source projects and integrations. Both rows go to Solo.io.
Its reach is the traffic routed through it. An action is judged when it crosses agentgateway or a waypoint; agents the registry finds on a connected cloud runtime are listed as unmanaged, and nothing on the device or in the browser is documented.
Identity is the workload's, or the delegating user's. An autonomous agent resolves to its mesh identity; no named owner per agent is documented. Agen names an accountable owner on every agent it finds and attributes each action to that human.
There is no public price. The gateway, the registry and the Istio distribution each carry their own licence. Agen is priced per governed agent.

The long read

Governed in the mesh, and only in the mesh.

Solo.io makes one strong architectural bet: agents are workloads, so govern them where workloads already talk to each other. Inside that path the controls run deep: identity-aware policy on every request, guardrails on model traffic, delegated tokens and a mesh underneath. The question this page measures is what sits outside it, and who answers for an agent once it acts.

What the platform is

Solo.io comes from the team behind Istio, and its agent stack is built the way a service mesh is built: a data plane in the traffic path, a control plane in Kubernetes, and policy attached to identity. Four pieces make it up.

agentgatewayan open-source proxy for MCP, agent-to-agent and LLM traffic, with an enterprise build that adds on-behalf-of identity, OAuth scope restriction, Microsoft Purview DLP, LLM budgets and a cost-management UI. Policy is written in CEL against headers, token claims, source identity and MCP tool names.
The ambient meshSolo's Istio distribution, where agentgateway runs as an ingress, egress or waypoint proxy and every enrolled workload receives a cryptographic identity issued by the infrastructure rather than declared by the application.
kagenta Kubernetes-native agent runtime that defines agents as cluster resources, with tool approval gates for a human in the loop and mTLS and egress policy from the mesh underneath.
agentregistrya catalog for agents, MCP servers, skills and prompts with an approval queue for new artifacts, plus discovery of agents already running on Kubernetes, Amazon Bedrock AgentCore, Microsoft Foundry and Copilot Studio.

All of it is self-hosted, with air-gapped installs and FIPS builds for regulated environments, and per-request access logs and traces export to the customer's own telemetry stack.

Where Solo.io is strongest

Two of the sixteen rows below go to Solo.io and four are level. Most follow from the same choice: the traffic path is the product, so everything on it is engineered deep.

Network-layer enforcementLayer 4 and Layer 7 policy through the ambient mesh, with workload identity on every connection. We govern the action rather than the network, and run alongside whatever mesh is already there, which is what lets one policy reach agents that never join it.
Ecosystem breadthopen-source projects with foundation backing, and integrations across the major LLM providers, MCP clients, agent frameworks and cloud agent runtimes. We run a focused set of governed connectors with a fixed integration SLA instead, which is what lets every one carry the same per-action policy.
MCP tool governance and single-call blockingCEL rules on tool name and caller identity that hide a tool from one caller and deny a single call with a 403 while the agent keeps running. Both level.
Delegationa built-in token service for RFC 8693 on-behalf-of exchange, with policies that see the user and the agent together. Level.
Deploymentself-hosted on Kubernetes or OpenShift, air-gapped, with FIPS builds. Level.

Where the path ends

A gateway and a mesh govern what flows through them. Solo.io extends that reach in two directions: desktop AI clients can authenticate to the gateway, and the registry can list agents running on connected cloud runtimes. Both are real, and both depend on the agent being routed or the runtime being connected.

What remains outside is the agent that never takes that path: one running inside a SaaS platform, one calling an internal API directly with a static key, one on a laptop. The registry's own documentation draws the line clearly: agents it discovers but did not deploy are listed as unmanaged, and only the ones it deployed can be acted on. That is where the architecture stops, and it is why agents with no vendor identity object score a 2.

Who a Solo.io request answers to

Solo.io answers this in two ways. When a user delegates to an agent, the token service exchanges the user's token for one carrying both identities, policy can reason about the pair, and the audit trail follows the chain. When an agent acts on its own, the mesh gives it a cryptographic workload identity tied to where it runs, and policy attaches to that.

The distinction is between which workload made a call and who answers for the agent. A workload identity says which service account in which namespace sent the request; it does not name a person. Across the gateway, registry and runtime documentation, no field records the human accountable for an agent; the registry logs who published and approved an artifact, which is the closest equivalent. So an autonomous action resolves to infrastructure, and a delegated one to whoever delegated it.

Three questions to put to Solo.io's stack

The table is organised around three questions, and each lands on a different part of Solo.io's architecture: the gateway, the identity model and the reach of the mesh and the registry.

Be at runtimefor anything crossing agentgateway or a waypoint, Solo.io decides on every request. What decides for an action that crosses neither?
Know the identityan autonomous agent resolves to its workload identity, and a delegated call to the user who delegated. Which named human answers for the agent itself?
Cover everythingdoes governance reach the agent that is not in the cluster, not on a connected runtime and not routed through the gateway, including the ones on employees' devices and in their browsers?

Then the bill. There is no public price list, licence keys come from an account representative, and the gateway, the registry and the Istio distribution each carry their own licence. A price per governed agent tracks how many agents you run.

The scored comparison

Sixteen capabilities, scored side by side.

Runtime enforcement, identity and accountability, coverage, and what it costs to operate — each scored 0–5 on capability depth against vendor documentation, including the four rows that come out level and the two Solo.io wins.

Capability depthNoneComplete
01 · Runtime enforcement
Verdict rendered at the moment of action	Solo.ioPer request, on its pathStrong4/5	Agen.coPer-action verdicts, <30msComplete5/5
Human-in-the-loop approval on a risky action	Solo.ioTool approval in kagent agentsCapable3/5	Agen.coHuman-in-the-loop, built inComplete5/5
Blocks a single action without disabling the agent	Solo.ioDenies the one call, 403Complete5/5	Agen.coAction-level enforcementComplete5/5
02 · Identity & accountability
Agent has a first-class identity object	Solo.ioWorkload identity in the meshCapable3/5	Agen.coFirst-class agent identityComplete5/5
A named human accountable for each agent	Solo.ioPublisher and approver loggedBasic1/5	Agen.coNamed owner, every agentComplete5/5
Each individual action attributed to that human	Solo.ioDelegating user, via on-behalf-ofCapable3/5	Agen.coAttributed per actionComplete5/5
Delegated (on-behalf-of) access	Solo.ioRFC 8693 on-behalf-of, enterpriseComplete5/5	Agen.coOn-behalf-of, governedComplete5/5
03 · Coverage
Endpoint enforcement	Solo.ioNot documented; clients route via gatewayBasic1/5	Agen.coAgenShield on the deviceComplete5/5
Browser enforcement	Solo.ioNot documentedBasic1/5	Agen.coBrowserShield, early accessCapable3/5
Network-layer enforcement	Solo.ioAmbient mesh, L4 and L7Complete5/5	Agen.coNot our layer — works alongsidePartial2/5
Agents carrying no vendor identity object	Solo.ioListed as unmanaged, not governedPartial2/5	Agen.coDiscovered, owned, governedComplete5/5
MCP tool governance	Solo.ioCEL policy per tool callComplete5/5	Agen.coMCP tools governed per callComplete5/5
04 · Operate & buy
Pricing unit — what you are billed per	Solo.ioQuoted licence, unit unpublishedCapable3/5	Agen.coPer governed agentComplete5/5
Platform cost — total spend to govern N agents	Solo.ioA licence per productPartial2/5	Agen.coScales with agents, not headcountStrong4/5
Deployment model and data residency	Solo.ioSelf-hosted, air-gapped, FIPS buildsComplete5/5	Agen.coSaaS, hybrid, or on-premComplete5/5
Ecosystem and marketplace breadth	Solo.ioOpen-source projects, broad integrationsStrong4/5	Agen.coFocused platform, not a marketplacePartial2/5

10 rows Agen.co leads4 tied2 rows Solo.io leads

Levels reflect capability depth and supporting evidence. Capability descriptions based on vendor public documentation.

Get the walkthrough

Get the scored comparison walkthrough.

Thirty minutes, row by row, including the ones we lose to Solo.io. You leave with the same table, scored for your environment. Tell us anything we should know in the comments.

length30 minutes

formatrow by row

commitmentnone

What the table shows

Depth in the mesh. The gap is reach and ownership.

Solo.io's enforcement is real, and the scores say so: a 4 on runtime verdicts, four rows level with ours, and network-layer enforcement and ecosystem breadth in its favour. Nothing about the gateway is shallow.

The boundary is the path and the identity on it. Solo.io governs what crosses agentgateway or a mesh waypoint, and the identity it names is a workload's or a delegating user's. The cards below follow that one line through each group of the table.

Reading the table

Solo.io's mesh, group by group.

One card per table group: what Solo.io's scores mean for an agent working against your systems, inside the mesh and outside it.

Every request on the path, judged in line

Allow, Require and Deny rules in CEL run on every request and MCP tool call through agentgateway, and a denied call returns a 403 while the agent keeps running. Human approval lives in kagent's tool gates, so it reaches agents running on kagent.

policy languageCEL

A workload identity, or the user who delegated

Mesh workloads carry a cryptographic identity, and on-behalf-of tokens carry the user and the agent together. An autonomous call resolves to the workload that sent it. No named owner per agent is documented.

owner per agentnot documented

Found on connected runtimes, governed if deployed

The registry lists agents running on Kubernetes, Bedrock AgentCore, Foundry and Copilot Studio once each runtime is connected. Agents it did not deploy are shown as unmanaged, and no device or browser coverage is documented.

unmanaged agentslisted only

A licence per product, quoted

There is no public price. The gateway, the registry and the Istio distribution each need their own licence key from an account representative, and the egress waypoint needs both the Istio and the gateway licence.

public pricingnone

Watch it happen

Every agent found. Including the ones outside the mesh.

Agentless discovery across five surfaces: IdP, gateway, devices, cloud and registries. Nothing has to join a mesh, be routed through a gateway or carry an SDK to be found, owner-mapped and governed.

agent discovery · live product scene

What closes the gap

Keep the mesh. Govern every agent around it.

Your agent traffic can keep flowing through the gateway and mesh you run today. Agen governs across it and beyond it: every agent discovered without being routed or deployed first, every action judged against your policy at the moment it happens, every verdict resolved to a named accountable human, workforce and customer-facing agents on the same plane.

Select a capability

Continuous discovery across your IdP, gateway, devices, cloud, and registries. Nothing has to self-register: agents are found, risk-scored, and resolved to a named human before they act.

Agentless and API-based across five surfaces
First-party, custom, and third-party agents alike
Every agent mapped to an owner, approver, and escalation

Agen Discover AI agent discovery flow: any identity provider, productivity suites and assistants, cloud, gateway, endpoints, and MCP server registries all feed one agent registry where every AI agent is inventoried, risk-scored on arrival, given a named human owner, and shadow AI is surfaced. — Discovery pulls from five surfaces into a single agent registry — no SDK self-registration required.

ClosesWhich agents are running that nobody registered?

no SDK required5 surfacesowner-mapped

Discover in depth →

Every request is evaluated against the identity behind the agent and answered in under 30ms: allow, mask, step up, hand to a human, or deny. The action is where the risk lives, so the action is where the decision happens.

Per-action verdicts anchored to the human behind the agent
Step-up and human-in-the-loop only when policy is crossed
Evidence generated at action time, not reconstructed later

Agen Govern runtime AI agent governance flow: an attempted action such as an assistant reading a document, an agent exporting records, or a custom agent writing to production is resolved to the identity behind the agent and checked against policy in 22 milliseconds, returning a per-action verdict of allow, mask, step-up, human-in-the-loop, or deny. — Every agent action is judged in-line against the human behind it, and answered in under 30ms.

ClosesWho approved this action, and who is accountable for it?

<30ms verdictstep-uphuman-in-the-loop

Govern in depth →

One policy plane enforced identically on the endpoint, in the browser, at the gateway, and in the cloud. Agent risk lives in the gaps between point tools, so there are no gaps to live in.

AgenShield stops dangerous local actions before they execute
BrowserShield catches company data at the paste (early access)
One policy, one identity chain, enforced the same way everywhere

Agen Shield AI agent enforcement flow: one policy plane written once in Govern and anchored to the same identity is enforced identically on the endpoint with AgenShield, in the browser with BrowserShield, at the gateway across 150+ connectors, and in the cloud across SaaS and internal apps. — One policy, written once, enforced the same way on every surface where agents actually run.

ClosesWhat happened on the laptop and in the browser that no log saw?

endpointbrowsergateway · cloud

Shield in depth →

Methodology

How these scores were reached.

Forty-two capabilities were considered against the ladder in our internal rubric; thirty-eight were scored and sixteen are published here. Four were dropped and are not published on any page: two because no public source states the fact either way, one because the row would not be a fair like-for-like measure of an infrastructure vendor, and one held pending confirmation of our own baseline. Each score reflects capability depth in the vendor's best available configuration: where a capability requires an enterprise build or a separate product, it is scored at its real depth and the licensing cost is carried in the Operate & buy group instead of penalised twice.

Sources15 primary

Evidence ledger

Solo.io docs — agentgateway overviewTier AEnterprise data plane for agents, MCP tools, LLMs and inference on Kubernetes; enterprise-only features include on-behalf-of identity, OAuth scope restriction, Microsoft Purview DLP, global rate limits, LLM budgets, a cost-management UI and an ambient waypoint; desktop AI clients authenticate to the gateway.
Solo.io docs — authorizationTier AAllow, Require and Deny policies written in CEL over headers, token claims, source IP and MCP tool names, applied across HTTP routes, LLM providers, MCP servers and agents; Deny is evaluated first and denials return a 403.
Solo.io docs — MCP tool accessTier ACEL rules on MCP tool name and token claims control which tools a caller can list and call; by default all tools are allowed.
Solo.io docs — on-behalf-of delegationTier AA built-in security token service implements RFC 8693 on-behalf-of exchange with any OIDC provider; policies can reference both the user and the agent identity; audit logs track the full call-chain identity.
Solo.io docs — workload identity tokensTier AWorkload identity claims from the mesh certificate are exposed to CEL policy when agentgateway runs as an ambient waypoint; the feature is alpha.
Solo.io docs — agentic meshTier AEvery workload enrolled in the mesh receives a cryptographic identity issued by infrastructure; agentgateway authorizes individual MCP tool invocations by the calling workload's SPIFFE identity and enforces allow and deny decisions before requests reach their destination.
Solo.io docs — egress waypointTier Aagentgateway as an egress waypoint enforces Layer 7 policy on traffic leaving the ambient mesh; requires an Enterprise licence for Solo's Istio distribution and a separate agentgateway licence.
Solo.io docs — LLM guardrailsTier APrompt guards on LLM requests and responses: regex and built-in PII detectors, moderation, AWS Bedrock Guardrails, Google Model Armor, Microsoft Purview DLP, reversible masking and custom webhooks.
Solo.io docs — licensingTier AA licence key is required and is obtained from an account representative; trial keys are typically valid for 30 days.
Solo.io docs — AI artifact registryTier AThe registry is installed separately as Solo Enterprise for agentregistry and requires its own licence.
Solo.io docs — agentregistry editionsTier ADiscovers agents on Kubernetes, Amazon Bedrock AgentCore, Microsoft Foundry and Copilot Studio in one inventory; records who published, approved, updated or deleted each artifact; runtime authorization is enforced through agentgateway.
Solo.io docs — unmanaged agentsTier AAgents on a connected runtime are discovered automatically and listed as unmanaged; only agents deployed through the registry can be interacted with.
kagent — Kubernetes-native agent runtimeTier AAgents defined as Kubernetes resources; human-in-the-loop tool approval gates; runs on Istio or ambient mesh for mTLS, RBAC and policy-driven egress.
agentgateway project — benchmarkTier AProxy benchmark against a mock backend: 0.831ms P50 and 1.970ms P99 at 36,933 requests per second.
Solo.io docs — access logsTier APer-request structured access logs with CEL filtering and enrichment, exportable to ClickHouse through the telemetry collector.

Vendor capabilities change. If a row is out of date or wrong, tell us and we will re-score it — corrections are published with the date they were made.

FAQ

Questions, answered.

What is Solo.io?