Comparison · agent governance · Runlayer

Runlayer, measured.

Runlayer routes employee AI tools through an MCP gateway, scans every tool call it brokers, and finds unmanaged MCP servers on managed devices. This page scores that architecture against Agen.co across 15 capabilities, with the sources, the scoring ladder, the five rows that come out level and the one Runlayer wins all on the page.

Get the walkthroughJump to the comparison

The short answer

  • Runlayer is a deep MCP gateway. Policy is evaluated by its proxy on every tool invocation, with ML scanners on tool definitions, calls and outputs, PII and secret masking, and approval rules on top. MCP tool governance and human-in-the-loop approval score level with ours.
  • Delegation is real. On-behalf-of tokens enforce the intersection of the agent's and the user's policies, and the audit log records both. That row is level too.
  • Its reach is the traffic routed through it. A tool call is governed when it crosses the gateway or a hooked runtime; discovery runs through an endpoint package deployed by MDM. An agent on an unmanaged device, or one calling a system directly, is outside that path.
  • Identity follows the trigger. A run executes as the person chatting, the schedule's creator or the API key's owner, or in an opt-in mode as the agent's own account. Accountable owners live on agent accounts, which an agent gets only when built in Runlayer or registered by an admin. Agen names an owner on every agent it finds and attributes each action to that human.
  • Pricing is an annual contract with a consumption dimension and no public tiers. Agen is priced per governed agent.
  • Runlayer leads on ecosystem breadth: 18,000+ MCPs served through its gateway and integrations across the major AI clients.
The long read

Governed on the path, and only on the path.

Runlayer makes one strong architectural bet: put every employee's AI tool traffic through a single gateway and govern it there in depth. Inside that path the controls run deep: policy on every tool call, scanners on definitions and outputs, approval rules and on-behalf-of delegation. The question this page measures is what sits outside it.

What the platform is

The product is built around an MCP gateway that sits between AI clients and the systems they call. Connectors are managed MCP servers, and their traffic runs through the gateway for authentication, policy, scanning, audit and analytics. Around that core sit four further pieces.

  • Policy at the proxypermission policies and approval rules evaluated on every tool invocation, written against users, groups, roles, agent accounts, AI client, connector, tool arguments, OAuth state and session history. Groups sync from the identity provider over SCIM.
  • Runtime scannersML models that inspect tool definitions at registration, tool calls and outputs at runtime, and intent drift across a session, with block, alert, mask and self-approve actions and a published typical scan time of 50–100ms.
  • Shadow AI discoveryan endpoint package deployed once through MDM that finds AI clients, unmanaged MCP servers, skills and plugins from configuration files, with modes that move from monitoring to blocking on the device. A managed-browser extension carries the same scanning to AI web chats.
  • Agents and hooksemployees can build agents inside the platform, each backed by an agent account with a recorded owner; an admin can register an agent built elsewhere with an account of its own, and a hooks SDK brings custom runtimes built on the major agent frameworks into the same enforcement pipeline.

It deploys either as a single-tenant hosted instance or self-hosted in the customer's own cloud account, and the audit log records every tool call, with a SIEM export that includes policy decisions.

Where Runlayer is strongest

One of the fifteen rows below goes to Runlayer and five are level. Most follow from the same choice: the gateway is the whole product, so everything on it is built deep.

  • MCP tool governancepolicy on every tool call, scanners on definitions and outputs, and an audit record of each call. Level with ours, and the centre of what they build.
  • Delegation and approvalon-behalf-of tokens bound to the intersection of two policies, and approval rules that put a human checkpoint on access already granted. Both level.
  • Deploymentsingle-tenant hosting or a self-hosted install in your own cloud. Level.
  • Browsera generally available extension for Chrome, Edge and Firefox that scans, masks and blocks prompts in supported AI web chats on managed devices. Level.
  • Ecosystem breadtha gateway serving over 18,000 MCPs and integrations across the major AI clients and agent frameworks. We run a focused set of governed connectors with a fixed integration SLA instead, which is what lets every one of them carry the same per-action policy.

Where the path ends

A gateway governs what is sent through it. Runlayer extends that reach in two directions: hooks bring custom runtimes in, and the endpoint package finds unmanaged MCP servers on devices it is installed on. Both are real, and both are forms of enrolment — an SDK integrated, or a package pushed by MDM.

What remains outside is the agent that never enrols: one running inside a SaaS platform, one calling an internal API directly with a static key, one on a device the MDM does not manage. That is not a policy gap. It is where the architecture draws its line, and it is why discovery scores a 3 rather than a 5 and agents with no vendor identity object score a 2.

Who a Runlayer run answers to

Runlayer resolves most actions to a person. An agent run executes under an identity set by its trigger: the person chatting with it, the creator of its schedule or event trigger, the owner of the API key that called its webhook, or the agent's owner when the webhook is unauthenticated. On-behalf-of entries record both the agent and the delegating user. Agent accounts are principals in their own right, and every one records an owner, the person accountable for it. That is genuine attribution, and the identity rows score it as such.

The distinction is between who triggered a run and who answers for the agent. Most actions resolve to the triggering person, who may not be the owner and can change from run to run; in the opt-in run-as-agent-account mode, the audit log attributes the run to the account rather than to a person, so the owner is one lookup away. And an agent has an account and an owner only if it was built in Runlayer or an admin registered it. An agent working through an employee's AI client otherwise simply runs as that employee.

Three questions to put to Runlayer's gateway

The table is organised around three questions, and each lands on a different part of Runlayer's architecture: the proxy, the run-identity model and the reach of the gateway and its endpoint package.

  • Be at runtimefor anything crossing the gateway or a hooked runtime, Runlayer's proxy decides on every tool invocation. What decides for an action that crosses neither?
  • Know the identitya Runlayer run resolves to whoever triggered it, or to its agent account. Is that the same person who answers for the agent, on every run?
  • Cover everythingdoes governance reach the agent that never routes through the gateway or runs on an MDM-managed device, including agents that serve your customers rather than your employees?

Then the bill. Runlayer's marketplace listing pairs a twelve-month contract with a consumption-priced usage dimension, so spend tracks how much traffic its gateway carries. A price per governed agent tracks how many agents you run.

The scored comparison

Fifteen 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 five rows that come out level and the one Runlayer wins.

Capability depthNoneCompleteRunlayerAgen.co
01 · Runtime enforcement
Verdict rendered at the moment of actionRunlayerPer tool call, on its pathStrong4/5Agen.coPer-action verdicts, <30msComplete5/5
Decision latency, published and measuredRunlayer50–100ms ML scans, publishedCapable3/5Agen.co<30ms, published, no samplingComplete5/5
Human-in-the-loop approval on a risky actionRunlayerApproval rules on tool accessComplete5/5Agen.coHuman-in-the-loop, built inComplete5/5
02 · Identity & accountability
Agent has a first-class identity objectRunlayerAgent accounts; external ones added manuallyStrong4/5Agen.coFirst-class agent identityComplete5/5
A named human accountable for each agentRunlayerOwner on each registered agent accountStrong4/5Agen.coNamed owner, every agentComplete5/5
Each individual action attributed to that humanRunlayerTriggering user, not always the ownerStrong4/5Agen.coAttributed per actionComplete5/5
Delegated (on-behalf-of) accessRunlayerOBO, intersection of both policiesComplete5/5Agen.coOn-behalf-of, governedComplete5/5
03 · Coverage
Endpoint enforcementRunlayerMDM package for AI clientsStrong4/5Agen.coAgenShield on the deviceComplete5/5
Browser enforcementRunlayerAI web chats, managed devicesCapable3/5Agen.coBrowserShield, early accessCapable3/5
Agentless discovery — no SDK, no self-registrationRunlayerEndpoint package, deployed by MDMCapable3/5Agen.coAgentless, 5 surfaces, no SDKComplete5/5
Agents carrying no vendor identity objectRunlayerFound on managed devices onlyPartial2/5Agen.coDiscovered, owned, governedComplete5/5
MCP tool governanceRunlayerGateway policy on every tool callComplete5/5Agen.coMCP tools governed per callComplete5/5
04 · Operate & buy
Pricing unitRunlayerAnnual contract plus consumptionCapable3/5Agen.coPer governed agentComplete5/5
Deployment model and data residencyRunlayerSingle-tenant hosted or self-hostedComplete5/5Agen.coSaaS, hybrid, or on-premComplete5/5
Ecosystem and marketplace breadthRunlayer18,000+ MCPs; list on requestStrong4/5Agen.coFocused platform, not a marketplacePartial2/5
9 rows Agen.co leads5 tied1 row Runlayer 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 Runlayer. 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 on the path. The gap is reach.

Runlayer's enforcement is real, and the scores say so: a 4 on runtime verdicts and on action attribution, five rows level with ours, and the ecosystem row in its favour. Nothing about the gateway is shallow.

The boundary is the path itself. Runlayer governs, attributes and discovers what crosses its gateway, a hooked runtime or an MDM-managed device, and the person it names is whoever started the run there. The cards below follow that one line through each group of the table.

Reading the table

Runlayer's path, group by group.

One card per table group: what Runlayer's scores mean for an agent working against your systems, on its gateway and off it.

01

Every call it brokers, judged in line

Policy runs on every tool invocation at the proxy and scanners inspect calls and outputs, with approval rules on top. The decision point is the gateway or a hooked runtime, so an action that never crosses either has none. Published scan times sit at 50–100ms.

typical scan time50–100ms
02

Each run answers to whoever started it

A run executes as the person chatting, the schedule's creator or the API key's owner, and on-behalf-of calls record both the agent and the delegating user. Accountable owners sit on agent accounts, which exist for agents built in Runlayer or registered by an admin; opt-in agent-account runs are attributed to the account, not a person.

owner recorded onagent accounts
03

Discovery needs a package on the device

Shadow MCP servers, skills and plugins are found by an endpoint package pushed through MDM, and it can block on the device as well as report. An agent on an unmanaged device, inside a SaaS platform, or calling a system directly is outside what it can find.

agentless discoveryno
04

An annual contract with a consumption meter

There are no public tiers. The marketplace listing pairs a twelve-month contract with a consumption-priced usage dimension, so the bill tracks activity rather than the number of agents being governed.

public pricingnone
Watch it happen

Every agent found. Including the ones nobody routed.

Agentless discovery across five surfaces — IdP, gateway, devices, cloud and registries. Nothing has to be pointed at a gateway, enrolled or carry an SDK to be found, owner-mapped and governed.

agent discovery · live product scene
What closes the gap

Keep the gateway. Govern every agent around it.

Your MCP traffic can keep flowing where it flows today. Agen governs across it and beyond it: every agent discovered without being routed or enrolled first, every action judged against your policy at the moment it happens, every verdict resolved to a named accountable human — workforce agents 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 →

Methodology

How these scores were reached.

Forty-two capabilities were considered against the ladder in our internal rubric; thirty-four were scored and fifteen are published here. Eight were dropped and are not published on any page — five because no public source states the fact either way, two because the row would not be a fair like-for-like measure of a gateway product, 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 a separate SKU, it is scored at its real depth and the licensing cost is carried in the Operate & buy group instead of penalised twice.

Sources16 primary
Evidence ledger
  1. Runlayer — platform overviewTier AShadow AI discovery, access governance, secure runtime execution, AI spend management, agent creation and an MCP gateway serving 18,000+ MCPs; works with Claude, Cursor, ChatGPT, Codex and internal agents.
  2. Runlayer — securityTier AAccess scoped by user, group, role, agent, AI client, connector, tool, OAuth state and runtime context; shadow AI discovery through existing MDM without employee opt-in; adoption, spend, findings and audit history in one place.
  3. Runlayer docs — policiesTier APolicies evaluated by the proxy on every tool invocation; Allow and Deny permission policies plus approval rules; groups synced over SCIM; on-behalf-of tokens enforce the intersection of the agent's and the delegating user's policies.
  4. Runlayer docs — agentsTier AAgents backed by an agent account Runlayer creates; runs execute as the chat user, schedule creator, API-key owner, trigger creator or agent owner depending on the trigger, or as the agent account in run-as-agent-account mode; the owner is shown on the agent, can be transferred by admins, and only the owner can delete it; agents built outside Runlayer get an agent account created manually.
  5. Runlayer docs — Shadow AITier AOne signed package deployed through MDM discovers AI clients, shadow MCP servers, skills and plugins from configuration files; Monitor, Protect and Enforce modes, the latter two applying block, mask and deny-by-default decisions.
  6. Runlayer docs — ToolGuardTier AML scanners on tool definitions, tool calls and tool intent with typical scan times of 50–100ms; Block, Alert, Mask and self-approve actions; 12 built-in PII types, secret detection and custom rules.
  7. Runlayer docs — AgentGuardTier ASession-level trajectory monitoring with Allow, Alert and Block; a blocked tool call blocks only that call unless the session-wide kill switch is enabled; recommended rollout starts in Alert.
  8. Runlayer docs — audit logsTier ATool calls recorded as audit events; agent-account activity is attributed to the agent account, not to a person, and on-behalf-of entries also record the delegating user and run reference; SIEM export includes policy decisions.
  9. AWS Marketplace — Runlayer listingTier BTwelve-month contract with a consumption-priced usage dimension, delivered as SaaS; no public plan tiers.
  10. Runlayer docs — deploymentTier AHosted single-tenant deployment in an AWS account Runlayer operates, or self-hosted on a Kubernetes cluster or ECS Fargate in the customer's account; no shared database between customers.
  11. Runlayer docs — rolesTier ASCIM provisioning with Okta, Azure AD or Google Workspace as source of truth for groups and roles; agent accounts distinct from user accounts.
  12. Runlayer docs — connectorsTier AConnectors are managed MCP servers whose traffic runs through Runlayer for auth, policy, scanning, audit and analytics; Runlayer-built, vendor-official and custom endpoints; per-user OAuth consent; the full catalogue list is available from the account team.
  13. Runlayer docs — hooks SDKTier APre-tool enforcement with optional argument rewriting and post-tool output scanning for custom runtimes, with adapters for Claude Agent SDK, Vercel AI SDK, OpenAI Agents SDK and Google ADK.
  14. Runlayer docs — sessionsTier ASessions span coding and desktop AI clients, Runlayer agent runs and imported web chats, recording MCP and local tool calls with each scanner outcome.
  15. Runlayer docs — browser extensionTier AGenerally available managed extension for Chrome, Edge and Firefox that scans prompts in 14 supported AI web chats and can mask or block them before they reach the provider; four more chats are monitor-only; response scanning is audit-only; force-install requires a managed device.
  16. Runlayer docs — agent accountsTier AAn agent account is a principal alongside users and groups, created by an admin, authenticating with client credentials or RFC 8693 token exchange for on-behalf-of; every agent account has an owner, the person accountable for it; audit rows name the agent, the user it acted for and the token used.

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 Runlayer?
Runlayer is an MCP gateway for enterprise AI use. Employee AI clients connect to managed MCP connectors through its gateway, where a proxy evaluates policy on every tool invocation and ML scanners inspect tool definitions, calls and outputs. Around that it adds shadow AI discovery through an MDM-deployed endpoint package, a browser extension for AI web chats, an agent builder backed by agent accounts, a hooks SDK for custom runtimes, and usage and spend reporting.
Does Runlayer block agent actions at runtime?
Yes, for tool calls on its path. Permission policies allow or deny each tool invocation at the proxy, approval rules add a human checkpoint, and scanners can block, mask or alert, with a published typical scan time of 50–100ms. A blocked call stops only that call unless the session kill switch is enabled. The decision point is the gateway or a hooked runtime, so an action that does not cross either is not evaluated.
How does Runlayer identify the human behind an agent?
Through whoever triggered the run. A Runlayer agent run executes as the person chatting with it, the creator of its schedule or event trigger, or the owner of the API key that called it; on-behalf-of calls record both the agent and the delegating user. Agent accounts each record an accountable owner, but an agent has one only if it was built in Runlayer or an admin registered it, and in the opt-in run-as-agent-account mode the audit log attributes the run to the account rather than to a person. Agen carries one named accountable owner on every agent, wherever it was built, and attributes each action to that human.
Can Agen.co run alongside Runlayer?
Yes. Agen does not require MCP traffic to move off an existing gateway. 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 are never routed through a gateway or enrolled on a managed device.
How is Runlayer priced?
Runlayer does not publish pricing tiers; deals are quoted. Its cloud marketplace listing pairs a twelve-month contract with a consumption-priced usage dimension, so cost follows activity. Agen is priced per governed agent with no prerequisite tier.
Where does Runlayer score better than Agen.co?
One row of fifteen outright, and five more are level. Ecosystem breadth goes to Runlayer: over 18,000 MCPs through its gateway and integrations across the major AI clients. Level with us on MCP tool governance, human-in-the-loop approval, on-behalf-of delegation, browser enforcement and deployment model, where single-tenant hosting and self-hosting are both documented.
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, enrolled or carry an SDK to be found, owner-mapped and governed. Internal and customer-facing agents run on the same policy plane across endpoint, browser, gateway and cloud.
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.

Bring your own comparison.

Send us the rows you would score differently. We will show you the evidence behind ours, and where we are wrong we will change the page.

Get the walkthroughSee the platform