Named comparison
Arc vs Lakera Guard (and content-layer guardrails)
Direct answer: Lakera Guard is a security API that screens LLM inputs and outputs — prompt injection, jailbreaks, PII, content violations — in real time. Arc is an action control plane: every agent action passes a default-deny allow/ask/block policy, risky ones pause for human approval, and approved work executes only as an ES256-signed request your app verifies. Lakera guards the text; Arc guards the action. Most teams run both.
What Lakera Guard actually does
Lakera Guard is one
of the strongest content-layer tools in the space. You POST a message chain to a
single endpoint (POST https://api.lakera.ai/v2/guard), it returns a
flagged boolean plus detector breakdowns — direct and indirect
prompt injection, jailbreaks, system-prompt extraction, data leakage, content
violations, malicious links — with sub-50ms latency claims and 100+ language
support per their docs. Detector policies are configurable per project. Check Point
announced its acquisition of Lakera in 2025 (reported around $300M; the company is
being folded into Check Point's AI security stack). Pricing isn't public —
check their pricing page or talk to sales.
The same layer is served by Guardrails AI (open-source Apache 2.0 framework plus a hub of 70+ community validators — PII, toxicity, format, factuality — with a managed Guardrails Pro tier) and NVIDIA NeMo Guardrails (Colang rails on conversation flows). Different products, same job: classify or validate a string before it goes into or comes out of the model.
The gap neither layer closes alone
Here's the failure mode content screening can't reach. Your support agent reads an inbound email containing a hidden instruction. Two outcomes:
- Lakera flags it. Great — that's exactly what it's for, and its detection rates are strong (Lakera cites 98%+; treat vendor numbers as vendor numbers).
- It doesn't flag it — novel phrasing, an indirect injection through a fetched webpage, or a perfectly benign-looking request that's simply wrong (“refund order #4471 in full” when no such promise exists). The text is clean. The action is the problem.
A content classifier evaluates the string. It has no concept of “this agent has already refunded $9,400 today,” “deletes require a human,” or “this execution request wasn't signed by the policy layer.” That's a different control:
- Default-deny policy per action. Arc evaluates
issue_refundvsdraft_replyas actions with declared risk, not as token sequences. Undeclared actions don't run. - Human approval lifecycle. Ask-policy actions park in a queue with expiry and per-user scope; a person clicks approve.
- Signed execution. Approved work arrives as an ES256 JWS; your app verifies signature, timestamp, nonce, and body hash before business logic runs. Tampering between “approved” and “executed” is detectable.
- Cumulative spend caps enforced atomically, not advisory. One enterprise client reportedly ran up ~$500M on Claude in a month with no usage caps (an AI consultant's account via Axios — unconfirmed, company unnamed). No prompt screen prevents that; a cap does.
- Hash-chained, redacted audit — sha256(prev_hash + canonical_json), so post-hoc edits are detectable.
To be equally honest in the other direction: Arc does not stop prompt injection. It never sees the prompt. If your threat model includes adversarial text — and for any agent reading untrusted input, it should — you want Lakera (or equivalent) on the text. Arc's contribution is blast-radius control: an injected agent can still only attempt the actions policy allows, and the dangerous ones stop at a human.
Capability comparison
| Capability | Arc | Lakera Guard | Guardrails AI |
|---|---|---|---|
| Prompt injection / jailbreak detection | ○ not the model layer | ● core product | ◐ hub validators |
| PII / content / toxicity screening | ○ out of scope | ● | ● validator library |
| Output format / factuality validation | ○ | ◐ | ● |
| Pre-action allow / ask / block policy | ● default-deny | ○ | ○ |
| Human approval on risky actions | ● queue + expiry | ○ | ○ |
| Signed (ES256), app-verified execution | ● | ○ | ○ |
| Cumulative spend caps that enforce | ● atomic | ○ | ○ |
| Tamper-evident hash-chained audit | ● | ○ logging/flagging | ○ |
| Latency on the hot path | n/a (action path only) | sub-50ms claimed | ~10–50ms per validator claimed |
| Open source | ○ hosted; SDK on npm | ○ API, pricing on request | ● Apache 2.0 + paid Pro |
● full · ◔ partial · ○ no
Run them in series
inbound text → Lakera Guard / Guardrails AI (screen the string)
→ agent reasons, decides to act
→ Arc (allow / ask / block → approval → signed exec)
→ your app (verifies ES256 signature, runs business logic) Arc's side is a policy file (npm i @geostack/arc):
import { defineActions } from "@geostack/arc";
export const actions = defineActions({
draft_reply: { policy: "allow" },
issue_refund: {
policy: "ask", // human approves in console
limits: { maxAmount: 200, cumulativePerDay: 1_000 }, // enforced atomically
},
delete_customer: { policy: "block" },
});
// undeclared actions are denied by default If the injection gets past the screen, the worst it can do is trigger an ask — and a human sees “refund $4,000 to an address we've never shipped to” before it executes.
Pick Lakera (or a content-layer tool), not Arc, if
Your AI surface is text-in, text-out: chatbots, summarizers, RAG search, anything where the worst outcome is a bad string — leaked PII, a jailbroken response, toxic output. Arc adds nothing there; it never reads the conversation. Lakera, Guardrails AI, or NeMo Guardrails is the right tool, full stop.
You need Arc in addition once the agent holds credentials that move money, send to customers, or mutate production. These layers aren't substitutes — content tools guard the text, Arc guards the action, and the teams running autonomous agents in production generally need both.
Arc pricing is public: free Developer tier, Team $99/mo, Business $499/mo, Enterprise custom. Lakera's is not — check their pricing page.
FAQ
Is Lakera Guard enough to stop my agent from taking destructive actions?
No — and Lakera doesn't claim it is. It classifies text; it doesn't evaluate, queue, or sign business actions. A destructive action driven by clean-looking text (or by a missed injection) passes a content screen untouched. Destructive-action control needs a default-deny action layer with human approval, which is what Arc does.
Does Arc detect prompt injection like Lakera does?
No. Arc never inspects prompts or model output — it's the action layer, not the model layer. If your agent reads untrusted input, run a content screen like Lakera in front of the model and Arc in front of the action. They don't overlap.
Can I just use Guardrails AI validators instead of both?
Guardrails AI validates model output — format, PII, toxicity, factuality — in-process. It has no human approval lifecycle, no signed execution your app verifies, and no enforced cumulative spend caps. It's a model-layer tool, like Lakera; the action layer is still open.
What happens when a prompt injection gets past the content filter?
That's the scenario Arc is built for. The injected agent can only attempt declared actions; high-risk ones pause for human approval; everything that executes is ES256-signed and verified by your app; and the hash-chained audit shows exactly what was attempted, decided, and run.
How much do Lakera Guard and Arc cost?
Lakera doesn't publish pricing — contact their sales or check the pricing page, particularly post-acquisition by Check Point. Arc: free Developer tier (no credit card), Team $99/mo, Business $499/mo, Enterprise custom, metered on protected agents and guarded actions rather than seats.
Screen the string. Gate the consequence.
Put one risky agent action behind allow / ask / block, approval, and signed execution — free Developer tier, no credit card.
Last updated 2026-06-12. Competitor capabilities per their public docs at time of writing — verify current features and pricing against their sites.