EvalLayer vs PolicyLayer: the tool gate and the content gate
PolicyLayer is a deterministic gate for MCP tool calls: it sits as a proxy between an agent and its tools and decides allow, require approval, or deny before any call runs. EvalLayer is a content gate: it reads the text of the intended action itself, checks it against commercial policy, and returns allow, rewrite, require_approval, or block, with a compliant rewrite when one exists. One controls whether the tool fires. The other controls what goes through it. The honest comparison is a stack diagram, not a versus.
What PolicyLayer is
PolicyLayer proxies the MCP protocol. You point your MCP client at its URL instead of the tool server's, and every tool call passes through policy first: per-tool allow and deny lists, per-action limits, daily and weekly caps, rate limits, per-identity rules, and approval requirements, written as declarative policy. Their showcase example is exactly the right one: a Stripe MCP server where create_refund is deny-by-default and financial operations require approval. Because enforcement is deterministic and lives outside the model, prompt injection cannot talk its way past it. They also publish solid research on the MCP tool ecosystem, which is how you know a vendor takes its layer seriously.
What EvalLayer is
EvalLayer's authorization API takes the intended action as content: the quote email, the customer reply, the refund message, the post, plus a commercial policy (discount authority, spend limits, forbidden commitments, approved claims, required disclaimers, blocked topics). Deterministic checks handle everything countable; one model pass handles the semantics a regex cannot see; the decision ladder returns one of four outcomes, including a re-validated compliant rewrite. Every decision is stored as an audit record.
The comparison
| Dimension | PolicyLayer | EvalLayer |
|---|---|---|
| Guards | The tool-call boundary (which call runs) | The action's content (what it says and commits) |
| Protocol | MCP proxy; MCP-speaking stacks | Plain HTTPS; any stack, MCP included |
| Decisions | Allow / require approval / deny (+ limits, rate caps) | Allow / rewrite / require_approval / block |
| Checking | Fully deterministic by design | Deterministic for numbers, one model pass for semantics |
| Can fix the action | No; it permits or stops the call | Yes; compliant rewrite, re-checked before offered |
| Sees inside free text | Parameters and metadata | Promises, claims, topics, tone in the text itself |
| Prompt-injection posture | Immune by architecture (no model in the loop) | Deterministic stage immune; semantic stage is a judge outside the agent's context |
Where each one wins
If your risk is which tools fire and how often: an agent that should never call delete, refunds that must stay under a cap, infrastructure tools that need a human: PolicyLayer's deterministic proxy is the right shape, and its no-model-in-the-loop design is a genuine virtue there.
If your risk is what the agent says while acting: the guaranteed date inside an approved email, the 25% discount inside a permitted send_message call, the unapproved claim in a compliant-looking reply: only a layer that reads the content catches it. A tool gate approves the envelope; the liability is usually in the letter.
Using both
The layers stack without touching: PolicyLayer decides the send_email call may run at all; EvalLayer decides whether this email may ship, rewrites it if it can be saved, and records the decision. Teams on MCP get defense in depth; teams elsewhere use EvalLayer's API directly at the send boundary. The broader taxonomy of these layers is in guardrails vs authorization, and the human-approval rail that catches both systems' escalations is covered in EvalLayer vs HumanLayer.