Lakera Review: Where It Fits and What to Test

Most Lakera reviews still describe a prompt-injection API. Lakera's current product page tells a broader story: agent discovery, risk assessment, runtime enforcement, and red teaming.

The useful question is whether those controls intercept the prompts, tool calls, MCP connections, and data paths that matter in your stack. This desk review separates documented scope from untested claims and compares that control path with AgentGuard.

The short review: Lakera is broader than the old Guard story

Lakera belongs on the shortlist for teams that want one enterprise AI security program to cover visibility, risk assessment, prompt and data protections, runtime policies, and red-team work. Its current public scope is substantially broader than the prompt-injection filter many buyers still associate with Lakera Guard.

The harder part is implementation detail. A broad product page does not show which agent actions are inspected synchronously, how unsupported integrations behave, what evidence is retained after a decision, or what latency and false-positive rates your workloads will see. Those are trial questions, not details to infer from a feature list.

This review is based on current public product pages, public review pages, and documentation available without an authenticated Lakera account. We did not run a controlled detection benchmark, inspect a private console, or verify comparable contract pricing. Performance figures repeated by other review sites are therefore excluded.

AgentGuard publishes this article and appears as an alternative below. We have kept that comparison to documented control surfaces and included AgentGuard's own public coverage limit rather than treating the publisher as an automatic winner.

What Lakera covers today

The old Lakera Guard URL now redirects to Lakera's current AI Agent Security page. That matters because a Lakera Guard review built only around input and output filtering would miss much of the platform's current positioning.

Discovery and risk assessment

Lakera says it can discover agents across enterprise environments and assess them using configuration, tool access, data access, MCP connections, and autonomy. This addresses a real first step: a security team cannot evaluate an agent it does not know exists.

Discovery should still be tested against the places where teams actually build. Ask Lakera to find one registered agent, one low-code workflow, one custom service, and one unregistered or newly connected MCP server. The result should identify the asset, owner, connections, privileges, and reason for its risk rating. A dashboard count without traceable asset evidence is not enough.

Runtime enforcement

Lakera's public page describes access controls and runtime guardrails for prompt attacks, data leakage, unsafe tool use, and unauthorized agent actions. That is a wider claim than screening text before it reaches a model.

The distinction matters because prompt injection attacks become more damaging when an agent can call tools, retrieve private data, or modify a system. A trial should show where Lakera sits in that sequence. Does it inspect only model traffic, or can it stop the downstream action before the tool executes? If a connector is unsupported, does the action fail open, fail closed, or remain unobserved?

Red teaming and workforce controls

Lakera also presents automated red teaming as a separate product surface. Its public page describes system scoping, simulated interactions, vulnerability identification, and testing for security, safety, compliance, regression, and drift. That can be useful when teams need repeatable adversarial testing before release and after model or prompt changes.

Workforce AI security is another adjacent surface. It targets employee interactions with public AI tools, copilots, developer tools, and connected systems. Buyers should treat this as a separate deployment question from protecting a production agent API. The identities, data paths, policy owners, and response workflows are different even when they share a management layer.

The control path below is not Lakera's architecture. It is the minimum path a buyer should ask any agent security vendor to demonstrate.

Control-boundary test: inventory the system, exercise a real action, observe the decision, and retrieve evidence.

Where Lakera fits, and where to press for proof

Good-fit conditions

Lakera is a reasonable candidate when the buying team wants a centralized program across AI inventory, risk posture, runtime protection, and red-team testing. The current scope also makes sense for organizations that need to bring security and AI platform teams into one evaluation rather than buy a prompt filter as a developer-only utility.

It is especially worth evaluating when the estate is mixed: cloud services, custom applications, low-code agents, model gateways, and MCP-connected systems. In that environment, the potential value is not another alert stream. It is a consistent inventory and policy decision that follows the asset across those surfaces.

Questions the trial must answer

The public pages do not settle the questions that determine operating fit. Ask for evidence at the exact boundary where a risky action would occur.

Latency and false positives belong in the same trial. Use normal traffic and business-specific prompts, not only vendor demonstrations. Measure the added time at the protected path and review every block with the people who own the workflow. A security control that teams bypass after a week has failed even if its lab result looked strong.

Lakera or AgentGuard? Choose by the control path

Lakera and AgentGuard overlap around prompt risk, data exposure, runtime policy, agents, and MCP-connected systems. They are not identical products, and the useful decision is not a single feature count.

Choose Lakera when

Start with Lakera when your primary task is centralized enterprise discovery, AI risk posture, runtime enforcement across a broad application estate, or an integrated red-team program. Its current public product architecture is organized around those lifecycle questions.

That does not remove the need for a technical proof. It means the buyer's first question is enterprise coverage: which assets appear, which policies can be applied, and which action paths produce enforceable decisions and auditable evidence.

Choose AgentGuard when

AgentGuard is the closer fit when the immediate problem is inside developer and agent environments: inspect skills, plugins, MCP servers, and agent code before trust, then evaluate high-risk actions through a local-first guard. The public repository also gives teams an open-source CLI surface they can inspect and integrate without treating every control as a remote black box.

That is a concrete advantage for teams that want component review and local action decisions near coding agents. The boundary matters, too. AgentGuard's public FAQ says it cannot fully monitor or block every third-party MCP server runtime call. Supported hooks, component scans, reputation, and trust controls reduce risk, but buyers still need to map uncovered paths.

Where the products overlap

Both products can enter a shortlist for agent security, prompt risk, runtime policy, and MCP-related controls. Lakera's public story is broader at the enterprise lifecycle level. AgentGuard's documented strength is a focused local developer guard plus component inspection. The existing AgentGuard vs Lakera comparison goes deeper on that boundary.

Inspect AgentGuard's control flow against the same representative action you plan to use in a Lakera trial.

A five-test Lakera evaluation plan

The control-boundary test

1. Inventory a known asset and a surprise asset. Connect a registered agent and then introduce an unregistered workflow or MCP server. Verify that the product identifies both, records ownership and access, and updates when a connection changes.

2. Run direct and indirect injection cases. Use a direct instruction attack and an indirect payload retrieved from a document or tool response. OWASP's LLM01 guidance is a useful baseline, but add attacks tied to your application's real tools and data.

3. Trigger a consequential action. Ask the agent to read a secret, write a protected file, call an external endpoint, or invoke a privileged tool. The expected result is not simply an alert. Require an allow or block decision before execution, with the connector, policy, and reason attached.

4. Test data leakage and normal work together. Seed synthetic sensitive data, attempt extraction through prompts and tool outputs, then replay normal business tasks that use similar vocabulary. This exposes both missed detections and blocks that would interrupt legitimate work.

5. Retrieve and operate the evidence. Send the result to the system that owns response work, then repeat the test after a policy or model change. The record should show the asset, input, action, decision, policy version, timestamp, and remediation state.

If MCP is a major part of the estate, use the same cases to evaluate dedicated MCP security tools. The point is not to add another product by default. It is to find the path that neither platform can currently observe or enforce.

Score each test as observed, partially observed, or unobserved. Then add latency, false-positive review time, deployment effort, and price to the same sheet. That creates a procurement record grounded in your stack rather than a vendor demo.

Book a scoped evaluation to map one agent action across component trust, runtime policy, and audit evidence.