Lakera vs Prompt Security: Runtime Guardrails or Workforce Control

Lakera and Prompt Security can both stop risky AI interactions. They receive different traffic. Check Point AI Guardrails, the current product built from Lakera, screens content submitted to its Guard API, while Prompt Security, now owned by SentinelOne, places controls in the browser and on the endpoint. It covers web AI alongside desktop or local activity. Start with the route: application code or workforce device.

TL;DR

• Choose Check Point AI Guardrails when your engineering team owns an internal application's model calls and can add runtime screening to that control flow.
• Choose Prompt Security when public AI websites, desktop tools, local assistants, and endpoint-resident agents make up the larger exposure.
• Check Point now sells a broader AI security family that also includes Workforce AI Security. Keep that separate entitlement distinct from the AI Guardrails API evaluated here.
• Run the same proof across every route, then compare actor attribution, the exact blocking point, added latency, and the evidence that leaves the vendor console.

Both names changed after acquisitions

Check Point acquired 100% of Lakera AI AG in October 2025, according to Check Point's 2025 annual filing. The live Lakera documentation now uses the name Check Point AI Guardrails and describes Guardrails as the runtime layer of AI Agent Security, available separately for teams that want screening embedded in their applications.

SentinelOne announced an agreement to acquire Prompt Security on August 5, 2025. That dated announcement described a pending transaction expected to close in SentinelOne's third fiscal quarter, while SentinelOne's subsequent quarterly filing records completion on September 5, 2025. The current Prompt Security site labels the product "Prompt Security from SentinelOne."

Those legal verbs matter. "To acquire" described the August agreement, while "Completed" describes the September closing. Lakera's old product name still carries the search demand. The current technical surface is Check Point AI Guardrails.

Check Point has also expanded the product family. Its current AI Defense Plane documentation assigns browser and endpoint use to Workforce AI Security, while AI Agent Security includes Guardrails as its runtime layer and AI Red Teaming handles pre-production testing. This article compares the standalone Guardrails runtime/API route with Prompt Security's workforce route. A Check Point quote that includes Workforce AI Security changes the comparison. Evaluate it as another deployed control.

Browser prompts favor a local interaction sensor

A prompt typed into a public assistant such as ChatGPT or Claude reaches a page's document object model before it becomes network traffic. Prompt Security's current browser and endpoint sensor guidance describes DOM-level awareness and prompt inspection, with a sensor that can redact data, guide the user at the moment of risk, and discover unapproved AI tools. Enforcement happens on the managed device. The interaction layer is the control point.

Check Point AI Guardrails sees a browser prompt only when an application or another integration submits that interaction to /v2/guard. A direct employee session on a public AI website lacks that application call, and the wider Check Point portfolio now assigns web use to Workforce AI Security Essentials or Enterprise, keeping direct browser traffic outside the Guard API's stated route.

Put two managed laptops side by side for the proof. On the first, paste a synthetic customer record into a sanctioned web assistant. On the second, use an unapproved AI site. Confirm which sensor captures each page, how it identifies the user, and where the blocking message appears. Then disable the extension on one device. Inspect the health alert.

The shadow AI monitoring tools guide gives this browser route its own evaluation criteria.

Desktop and local-agent activity favors endpoint coverage

Desktop assistants and IDE helpers can act without producing a useful request at a central model proxy. Local LLMs or MCP servers deepen that gap. Prompt Security describes a dedicated AI endpoint agent that detects agents, inspects their interactions, reads active skills or connectors, and enforces runtime policy around local behavior. This is the stronger architectural fit when the risk includes files or shells, local tool use, and on-device reasoning.

AI Guardrails can still screen a local agent interaction when developers deliberately call the Guard API, creating useful content protection inside that chosen workflow. Activity outside the integration remains outside its view. This is a deployment-coverage distinction. It says nothing about detector quality.

Test an IDE assistant that reads a harmless fixture file, followed by a local agent attempting to expose a planted secret through a tool call. Disconnect the network after policy synchronization. Repeat the local action. The record should show which user, process, agent, skill, and policy produced the outcome. Ask Prompt Security to demonstrate the supported behavior for an offline endpoint, then ask Check Point to identify the exact application hook that submits the same local interaction for screening.

Internal application calls favor Lakera's Guard API

An internal RAG service or support copilot gives the engineering team custody of the model call. This is the cleanest route for Check Point AI Guardrails. Its Guard API documentation accepts interaction inputs and outputs through /v2/guard; configured detectors run and return a flagged result, and customer code chooses the resulting block, warning, mask, or alert.

Check Point recommends screening the complete interaction after generation and before releasing it downstream. Teams can add input screening before model processing when data could leave for a third-party provider. Detect mode supports calibration before the project moves into Enforce mode. The application still owns call placement, timeout behavior, and the final mitigation.

Prompt Security's acquisition announcement says its coverage integrates across browsers, desktop applications, and APIs, which makes an API proof reasonable. The public browser-and-endpoint article provides much deeper implementation detail for workforce routes, however. For a backend procurement decision, require the same request schema, deployment model, failure posture, and performance evidence that Check Point publishes for Guardrails. A category claim falls short. Exercise the application path.

The AI gateway architecture guide helps inventory backend routes before an API proof begins.

Identity and block location determine the evidence

Check Point permits arbitrary metadata on a Guard request. Its documentation gives user_id and session_id as examples, which supports cross-referencing a detection with an application actor, but attribution depends on the application supplying trustworthy identity. A shared service credential plus an invented metadata value produces a neat record with weak provenance.

Prompt Security sits closer to the employee's managed browser or endpoint, where its placement can connect an interaction with device and session context. Its public sensor article stops short of defining the actor fields in an exported event. Treat natural-person attribution as an acceptance item. Require a sample record containing the corporate principal, device, application, policy version, event time, action, and stable event ID.

Block location differs just as much. Guardrails returns a decision to customer code, so the internal application owns the stop, while Prompt Security describes redaction or policy enforcement at the browser and endpoint interaction layer. My view is blunt. A green check beside "real-time protection" is useless unless the vendor can point to the exact instruction, process, or HTTP request that stopped.

The AI firewall, gateway, and proxy comparison explains why placement changes the meaning of a block.

Latency and exported evidence need measured proof

Check Point publishes a reference target below 150 ms for typical Guard API requests using persistent connections. Its documentation also says response time varies with content length and the number of detectors enabled, so measure your intended policy against representative prompt sizes. Capture p50, p95, timeout rate, and the user-visible delay for input screening and complete-interaction screening separately.

Prompt Security's sensor article promises real-time local control, while a comparable latency figure and test method remain unpublished there. Measure time added between the user's action and the local disposition on managed browser and desktop routes, including cold start, disconnected sensor, policy refresh, and a large paste in the run.

Evidence should leave the console. Check Point documents a Guard logs API that can return up to 1,000 records per page and includes request metadata while omitting unflagged detections from message-level results. Access is limited to select organizations. That limitation belongs in the proof. Prompt Security's public sensor article leaves the export schema unpublished, so require SentinelOne to export the corresponding allowed and denied events into the buyer's SIEM, then retrieve them by stable ID after the live session has ended.

One route-by-route acceptance test settles the choice

Build a corpus with allowed text and a synthetic secret. Add direct prompt injection plus an instruction hidden in a retrieved document. Use the same content on a public AI website and through a desktop assistant, then repeat it with a local agent and an internal application. Record the expected action before running the test. This prevents a visually impressive console from shifting the goalposts afterward.

For the browser route, verify sanctioned and unapproved sites on a managed device, then repeat with the extension disabled. The desktop run should include a local model and one tool action. The internal application must screen input and output independently, with a correlation ID that survives into the exported record. Each run needs the corporate actor, device or workload, destination, policy version, content classification, decision, and timestamp.

Force failure next. Disconnect the Guard API during an internal application call and document the application's fail-open or fail-closed behavior. Stop the endpoint sensor, allow its health state to age, and observe the administrative alert. Push a policy change while both products are active. Measure propagation. Finally, retrieve every allowed and denied event through an API or SIEM export, without relying on screenshots. The winner is the product that passes the routes you actually operate.

DeepInspect

DeepInspect governs authenticated HTTP traffic deliberately routed between users or agents and LLM endpoints. It evaluates application-supplied identity and role context with data classification, model destination, and a versioned policy before forwarding an allowed request. Each outcome produces an independent per-decision audit record outside the calling application's write path.

That boundary complements the two products in this comparison. DeepInspect leaves browser-only sessions, local models, endpoint file access, and STDIO tools to workforce or endpoint controls. It fits the internal HTTP route where a reviewer must prove why a named person or agent was allowed to send a specific data class to a model destination.

Book a technical deep dive at deepinspect.ai.