What is the actual difference between BehalfID and PolicyLayer?

The integration boundary, not the strength of enforcement. Both evaluate allow, deny or approval-required before an action executes, and both support human approval gates and audit logging. PolicyLayer is a hosted gateway between MCP clients and MCP servers, so it covers what the agent does through MCP without application changes. BehalfID checks at several boundaries — behalf.verify() inside your own executor, action-time hooks for supported coding agents, the Action Gateway, and Site Guard — so it covers actions that never take the shape of an MCP tool call.

Does PolicyLayer only advise, while BehalfID enforces?

No, and we will not claim that. PolicyLayer's published material describes deterministic policy evaluation with allow, deny and require-approval outcomes before MCP tool calls reach the real world, along with deny-by-default policies. Both products enforce. Where BehalfID has an advisory-only surface is our own MCP server, which reports permissions to an agent without intercepting other tools.

Can BehalfID enforce on MCP tool calls?

Not in a shipped, supported form today. The MCP server distributed with our CLI is advisory. An MCP interceptor package exists in our repository but is not published to npm and is not production-supported, so you should not count on it when comparing. If MCP is where your agents act, PolicyLayer covers that boundary and we currently do not.

What does an MCP gateway cover, and what sits outside it?

A gateway evaluates the calls that pass through it, so an MCP gateway covers the agent's MCP tool calls — all of them, without application changes. Actions that run inside your own service, such as a deploy function, a migration runner or a payment call behind a library, are not MCP tool calls, so covering those means putting a check in that code path. That is the main reason a team might run both. Map your highest-consequence actions to the boundary each one crosses, and confirm coverage with each vendor rather than assuming it.

Do I have to choose one?

No. If your agents are MCP-native and you also have production code paths of your own, the two cover different parts of the surface. Map your highest-consequence actions to the checkpoint each one crosses before deciding.

BehalfID vs PolicyLayer — where agent authorization gets enforced

Comparison

BehalfID vs PolicyLayer

Both products stop an agent action before it reaches the real world, and both have allow, deny and approval-required as first-class outcomes. What differs is where the checkpoint sits and how much of your agent surface it can see.

Pick PolicyLayer if your agents act through MCP and you want a hosted gateway governing tool calls, plus a shared authority system across a team of coding agents. Pick BehalfID if the actions you need to gate run inside your own code, behind coding-agent hooks, or outside MCP entirely. There is real overlap — the deciding question is which of your agents' actions pass through each product's checkpoint.

Last reviewed 11 August 2026 — competitor capabilities reviewed from publicly available PolicyLayer materials on that date. Products change; verify current capabilities with each vendor.

Sources: PolicyLayer, BehalfID capability matrix.

Side by side

Decision before executionBoth

BehalfID: Allow, deny, or approval required, evaluated before the integrated action runs. Deny-by-default: no permission means no action.
PolicyLayer: Allow, deny, or require approval, evaluated deterministically before an MCP tool call reaches the real world. Deny-by-default policies.

Human approval gatesBoth

BehalfID: An action can park and wait for a named person, who approves in the dashboard. The resulting grant covers one request and expires on its own.
PolicyLayer: Human approval gates on tool calls, with approvals and questions shared across a team's coding agents.

Audit trailBoth

BehalfID: Every authenticated decision is logged with a request ID, outcome, reason, risk level and the policy path that produced it.
PolicyLayer: Audit logging of policy decisions on tool calls.

Where it integrates

BehalfID: Several boundaries: behalf.verify() in your own executor, action-time hooks the CLI installs for supported coding agents, the Action Gateway for supported actions, and Site Guard for website routes. Covers actions that never take the shape of an MCP tool call.
PolicyLayer: A hosted gateway between MCP clients and MCP servers. Everything the agent does through MCP passes the checkpoint without changing application code.

MCP coverage

BehalfID: The shipped MCP server is advisory — it reports permissions to the agent and does not intercept other tools. An MCP interceptor package exists in our repository but is not published and not production-supported, so treat MCP as our weaker surface today.
PolicyLayer: The core of the product: a hosted MCP gateway with an MCP server and tool registry, enforcing on tool calls.

Conditions on arguments

BehalfID: Permissions carry constraints — maximum amount and allowed vendors — plus allowed and blocked action lists, resource matching and expiry. No rate or spend-over-time limits.
PolicyLayer: Argument conditions on tool calls, plus rate and spend limits.

Team authority model

BehalfID: Workspaces, memberships and roles, with managed profiles that put coding-agent CLIs behind a workspace policy checkpoint in unmanaged, managed or required mode.
PolicyLayer: Positioned as a system of record for AI agent authority, with signed team playbooks and approvals shared across a team's coding agents.

Maturity

BehalfID: Early. CLI and SDK are on npm; hooks and managed profiles are pilot. No SOC 2, no external security audit, no named public customers.
PolicyLayer: Check their current material for maturity, compliance posture and customer references — we do not characterise those here.

Pricing

BehalfID: Free tier, then $20/month self-serve. Enterprise by contact.
PolicyLayer: See their pricing page for current figures.

BehalfID compared with PolicyLayer across integration, approvals, outage behaviour and pricing
Dimension	BehalfID	PolicyLayer
Decision before executionBoth	Allow, deny, or approval required, evaluated before the integrated action runs. Deny-by-default: no permission means no action.	Allow, deny, or require approval, evaluated deterministically before an MCP tool call reaches the real world. Deny-by-default policies.
Human approval gatesBoth	An action can park and wait for a named person, who approves in the dashboard. The resulting grant covers one request and expires on its own.	Human approval gates on tool calls, with approvals and questions shared across a team's coding agents.
Audit trailBoth	Every authenticated decision is logged with a request ID, outcome, reason, risk level and the policy path that produced it.	Audit logging of policy decisions on tool calls.
Where it integrates	Several boundaries: behalf.verify() in your own executor, action-time hooks the CLI installs for supported coding agents, the Action Gateway for supported actions, and Site Guard for website routes. Covers actions that never take the shape of an MCP tool call.	A hosted gateway between MCP clients and MCP servers. Everything the agent does through MCP passes the checkpoint without changing application code.
MCP coverage	The shipped MCP server is advisory — it reports permissions to the agent and does not intercept other tools. An MCP interceptor package exists in our repository but is not published and not production-supported, so treat MCP as our weaker surface today.	The core of the product: a hosted MCP gateway with an MCP server and tool registry, enforcing on tool calls.
Conditions on arguments	Permissions carry constraints — maximum amount and allowed vendors — plus allowed and blocked action lists, resource matching and expiry. No rate or spend-over-time limits.	Argument conditions on tool calls, plus rate and spend limits.
Team authority model	Workspaces, memberships and roles, with managed profiles that put coding-agent CLIs behind a workspace policy checkpoint in unmanaged, managed or required mode.	Positioned as a system of record for AI agent authority, with signed team playbooks and approvals shared across a team's coding agents.
Maturity	Early. CLI and SDK are on npm; hooks and managed profiles are pilot. No SOC 2, no external security audit, no named public customers.	Check their current material for maturity, compliance posture and customer references — we do not characterise those here.
Pricing	Free tier, then $20/month self-serve. Enterprise by contact.	See their pricing page for current figures.

The overlap is real, so start with coverage

It would be convenient for us to claim that BehalfID intercepts and PolicyLayer only advises. That is not true. PolicyLayer's published material describes deterministic policy evaluation before MCP tool calls reach the real world, with allow, deny and require-approval outcomes, deny-by-default policies, argument conditions and audit logging. On the questions most buyers ask first — does it stop the action, can a human approve, is there a record — both products answer yes.

So the useful question is not whose enforcement is more real. It is which of your agents' actions actually reach each product's checkpoint. Write down the five actions that would ruin a week and trace how each one happens.

If they happen as MCP tool calls, a gateway covers all of them with no application changes, and that is the stronger position. If they happen inside your own service — a deploy function, a migration runner, a refund call behind a library — the action is not an MCP tool call, so covering it means putting a check in that code path. Many teams have both kinds, and the scope each product covers is worth confirming with the vendor rather than inferring.

Where each one is stronger

PolicyLayer is stronger on MCP. It is a hosted gateway for MCP traffic with a server and tool registry, argument conditions, rate and spend limits, and a shared team authority model built around playbooks. If your agents are MCP-native, that is a shorter path to coverage than integrating a check in several places yourself.

BehalfID is stronger on breadth of integration boundary. The same decision engine answers a behalf.verify() call inside your own executor, an action-time hook the CLI installs for a supported coding agent, an Action Gateway request, and a Site Guard check on a website route. Agents get explicit identities with scoped permissions, and approvals are single-use and expiring.

BehalfID is weaker on MCP specifically, and we would rather say so here than have you discover it in a trial. Our shipped MCP server is advisory: it tells an agent what it is allowed to do and does not intercept other tools. An MCP interceptor does exist in our repository, but it is not published to npm and not production-supported, so it should not weigh in a buying decision today.

Running both

These are not mutually exclusive, and for a team with MCP-native agents plus production code paths of its own, running both is a reasonable answer.

The thing to avoid is assuming one checkpoint covers everything. Whichever you choose, attempt a high-consequence action by a route that bypasses the checkpoint and confirm what happens. Every product in this category has such a route.

Where this page is biased

We wrote it, so read it that way. These are the things that cut against us.

PolicyLayer enforces before execution. Any framing that casts it as advisory-only, or as unable to hold an action for a human, would be wrong — both products do those things.
PolicyLayer covers MCP tool calls more completely than we do. Our shipped MCP integration is advisory, and our MCP interceptor is unpublished and not production-supported.
BehalfID is early. CLI and SDK are published; coding-agent hooks and managed profiles are pilot, not production-supported. No SOC 2 or ISO 27001, no formal external security audit, and no named public customers.
BehalfID is not universally fail-closed. Outage behaviour differs per integration and is documented per path.
We do not characterise PolicyLayer's maturity, compliance posture or customer base. We have no basis for it and it is not ours to summarise.

Questions

What is the actual difference between BehalfID and PolicyLayer?: The integration boundary, not the strength of enforcement. Both evaluate allow, deny or approval-required before an action executes, and both support human approval gates and audit logging. PolicyLayer is a hosted gateway between MCP clients and MCP servers, so it covers what the agent does through MCP without application changes. BehalfID checks at several boundaries — behalf.verify() inside your own executor, action-time hooks for supported coding agents, the Action Gateway, and Site Guard — so it covers actions that never take the shape of an MCP tool call.
Does PolicyLayer only advise, while BehalfID enforces?: No, and we will not claim that. PolicyLayer's published material describes deterministic policy evaluation with allow, deny and require-approval outcomes before MCP tool calls reach the real world, along with deny-by-default policies. Both products enforce. Where BehalfID has an advisory-only surface is our own MCP server, which reports permissions to an agent without intercepting other tools.
Can BehalfID enforce on MCP tool calls?: Not in a shipped, supported form today. The MCP server distributed with our CLI is advisory. An MCP interceptor package exists in our repository but is not published to npm and is not production-supported, so you should not count on it when comparing. If MCP is where your agents act, PolicyLayer covers that boundary and we currently do not.
What does an MCP gateway cover, and what sits outside it?: A gateway evaluates the calls that pass through it, so an MCP gateway covers the agent's MCP tool calls — all of them, without application changes. Actions that run inside your own service, such as a deploy function, a migration runner or a payment call behind a library, are not MCP tool calls, so covering those means putting a check in that code path. That is the main reason a team might run both. Map your highest-consequence actions to the boundary each one crosses, and confirm coverage with each vendor rather than assuming it.
Do I have to choose one?: No. If your agents are MCP-native and you also have production code paths of your own, the two cover different parts of the surface. Map your highest-consequence actions to the checkpoint each one crosses before deciding.

Try it against your own agents.

Free tier, no sales call. The fastest honest test is to point a coding agent at a production deploy and watch it stop.

Start building Read the deploy-approval guide

Fail-closed at the integration point. TLS everywhere, keys stored as hashes, we never sell or train on your data. How enforcement and data handling work.