We already have regex checks before our agent sends. Is that enough?

Regex is the right tool for the countable half: discounts, dollar amounts, required strings. It cannot see a delivery guarantee phrased politely, an unapproved claim, or a blocked topic. If your checks have never blocked a semantic violation, that is usually because they cannot, not because none occurred.

Is buying a dependency risk for something this critical?

It is a dependency, like your email provider and your payment processor are dependencies at their own critical moments. The fair comparison is not dependency versus independence; it is a maintained external layer with audit records versus an internal script whose author may have left. Fail-open versus fail-closed behavior is configurable either way.

What does EvalLayer cost compared to building?

Authorization runs from $0.01 per check pay-as-you-go, with a Pro plan at $99 per month for 2,000 checks a day. The build-side comparison is engineering weeks up front plus permanent ownership of policy parsing, model prompts, decision logic, storage, and the audit surface.

Build vs buy: the agent authorization layer

Published 2026-07-27 · EvalLayer

Roughly a quarter of engineering teams that deploy AI agents end up hand-rolling authorization checks: the March 2026 study Before the Tool Call put it at 27.2% abandoning framework-provided controls for hardcoded logic. The build vs buy question for the authorization layer is therefore not hypothetical; building is the incumbent. This page is an honest accounting of what the build actually includes, where homegrown checks decay, and the cases where building genuinely wins.

What the hand-rolled version looks like

It starts small and reasonable: a function between the agent and the send call. A regex for discount percentages. A blocklist of phrases. An if-statement for dollar amounts. It ships in a day and it works, in the sense that the demo passes.

Then reality arrives in stages. Someone phrases 25% off as "a quarter off list." Legal wants delivery-date guarantees caught, which regex cannot see. Sales changes the discount authority and the constant lives in three services. A customer disputes what the bot said and there is no record of what was checked. The person who wrote the checks leaves. What remains is an unowned, untested policy engine on the hottest path in the product.

The real build list

A credible authorization layer, built internally, includes:

A policy model: limits and rules as structured, versioned data, not constants scattered in code. The design space is bigger than it looks; see writing commercial policies for AI agents.
Deterministic checks for everything countable: amounts, percentages, required disclaimers. This is the easy 40%.
Semantic checks for commitments, claims, and topics: model calls with a prompt that must be regression-tested every time it changes, because false positives (flagging "I will send the deck tomorrow" as a delivery guarantee) burn trust as fast as misses burn money.
A decision ladder richer than pass/fail: approve, rewrite (with re-validation of the rewrite), escalate, block, each wired into the send path.
An audit store: content hashes, the policy version applied, violations, decisions, latency. What that must contain is covered in audit trails for AI agents.
An approval surface for escalations that shows reviewers the violation, not a raw transcript.
Ongoing ownership: prompt updates as models change, policy migrations, monitoring, the 2 a.m. page when the layer itself fails.

Teams that estimate the first two bullets estimate a week. The list is why the hand-rolled 27.2% is a population of permanent part-time platform teams, not finished projects.

When building wins

Building is the right call more often than a vendor likes to admit:

Your policy logic is genuinely proprietary and inseparable from internal systems (real-time margin data, credit models, inventory).
Your actions never leave your own infrastructure and an external call is architecturally unacceptable.
You operate under constraints that forbid third-party processing of message content entirely.
Action volume is so low that a human approves everything anyway, in which case an approval rail, not a policy engine, is the need.

When buying wins

Buying wins when the layer is critical but not differentiating: your customers do not choose you for your discount-cap checker, they just leave if it fails. An external layer arrives with the parts that take longest to harden (the semantic prompts, the false-positive tuning, the rewrite re-validation, the audit surface) already exercised across deployments, and it produces something the homegrown version structurally cannot: an independent record. "Our own script approved this" and "an external policy engine approved this, here is the record" land very differently with enterprise buyers, auditors, and tribunals, a distinction the liability precedents keep sharpening.

The middle path is real too: buy the engine, keep the policy. The policy is yours, versioned in your repo, sent with each request. The engine, prompts, ladder, and audit store are somebody's full-time job that is not yours.

The fastest way to price the comparison: run your riskiest recent agent message through the live demo against a policy you write in five minutes, then estimate what shipping that decision path internally would take.