Token Observe vs Lakera
Lakera tells your application the content is an attack. Token Observe is the thing that refuses to send it.
2 September 2026
- Lakera docs — Guard API endpoint
- Lakera docs — policies
- Lakera docs — projects
- Lakera docs — AI Guardrails integration guide
- Lakera docs — Agent Behavior Defense
- Lakera docs — Prompt Defense
- Lakera docs — AI Guardrails
- Lakera docs — AI Agent Security overview
- Lakera docs — AI Guardrails Dashboard
- Lakera docs — self-hosting AI Guardrails
- Lakera docs — API overview
- Lakera docs — data regions
- Check Point — press release: Check Point Acquires Lakera
Their claims, not our testing. Verify anything that decides it for you.
On this page
On prompt-injection defence itself — the category this page sits in — Lakera is the better purchase, and it is not close
Detection is their product and it is not Token Observe’s, so start with what they publish. Prompt Defense screens for prompt attacks across 100-plus global languages and scripts, and their documentation groups the guardrails into five defence categories — Prompt Defense, Content Moderation, Data Leakage Prevention, Malicious Links and Agent Behavior Defense — described as managed guardrails combining machine learning and language models with rule-based filters, updated on a daily basis to incorporate defences against new attacks and reduce false positives. Flagging sensitivity is set per policy across four confidence levels from L1 lenient to L4 paranoid, which their documentation states are in line with the OWASP Core Rule Set paranoia levels, and a Policy Impact Simulator in the dashboard compares flagging rates across all of those levels against your own historical traffic. Custom guardrails, in beta, let you describe what to detect in plain language and compile that into a detection policy combining pattern rules with semantic rules. Against nine weighted regular expressions with a 64 KB scan cap, a maintained detection product ought to win, and Token Observe’s own documentation concedes the point rather than arguing it: the heuristics have false negatives, the residual risk is on the register with the CISO named as the required acceptor, and injection findings are treated as one policy input among seven trigger kinds rather than as the control.
The agent-specific work is real too, and it is the part a reader in this category most needs to know about. Agent Behavior Defense adds a Dangerous Deviation detector that judges each tool call against the conversation history rather than against a fixed rule, flagging only when both the action is dangerous — their three named danger types are data leakage, access and privilege escalation, and system destruction — and nothing in the trusted `user` and `system` messages warrants it, with instructions arriving in `tool` responses explicitly never counting as warrant. Their worked example is a `get_order_status` call that serves the user’s request, an `export_customer_records` call with an external destination that does not, and a `load_branding_theme` call that is off-topic but not dangerous and so is not detected. Alongside it sits a Tool Allow/Deny List whose outcome their documentation describes as deterministic, detecting a denied tool call regardless of content and naming the tool and the list in the reason text. Their integration guide tells you to screen tool definitions before exposing them to the model, such as during the initial MCP handshake and whenever they change, and to pass tool results as `tool` role messages so they are screened as untrusted content. Above the runtime layer, AI Agent Security — an early access release on their own description — connects the platforms where agents run to build a continuously updated inventory of agents, their tools and their connected MCP servers, with a per-agent risk rating. None of that is territory Token Observe competes for.
There is a procurement and deployment advantage as well, and it decides real purchases. Self-hosting is documented for Kubernetes via a Helm chart, for Docker, and air-gapped with containers exported and loaded without internet access, on stateless containers with GPU-accelerated inference through Triton Inference Server — requiring a valid AI Guardrails Enterprise licence and container registry credentials provided by Check Point. Their SaaS runs in five named processing regions with a separate storage region for logs. Their dashboard documentation states SOC 2 Type II certification and that all data processed or stored is encrypted at rest and in transit. Token Observe holds none of that: no SOC 2, no ISO 27001, no ISO 42001, no independent penetration-test result, no availability SLA, and a licence that is a template pending review by counsel rather than an executed grant. Ask Lakera directly which certifications they hold, for what scope and to what date, because that is the only version of the answer worth having and this page does not hold it for them. Every claim in these three paragraphs is taken from their published pages on 2 September 2026, is vendor-authored, and has not been independently tested; where a row below reads as an absence in their product, treat it as a question for them in writing rather than as a finding.
Token Observe and Lakera, capability by capability
The Lakera column paraphrases Check Point’s own published material as it stood on 2 September 2026. None of it has been independently tested here, products in this category ship quickly, and a capability that is absent from a vendor’s documentation is not the same thing as a capability the product lacks. Check anything that decides it for you against their own current documentation.
Where it sits
An API your application calls. Their docs describe `POST https://api.lakera.ai/v2/guard` carrying the messages and a `project_id`, and their integration guide recommends screening the complete interaction after the LLM response has been generated but before it is returned to the user or downstream.
A gateway the traffic passes through. Eleven ordered steps run in one process — authenticate, resolve agent, open trace, sanitise, scan, govern, enact, route, call upstream, govern the response, meter and record.
Both are inline. The difference is that theirs is a call your code makes and Token Observe is the hop the call already goes through.
An HTTP request from any language, or from a gateway. Their integration guide sets out four architecture patterns — chat, document and RAG processing, AI gateway, and agent workflow — and the gateway pattern describes applying it centrally so application teams do no development work.
One environment variable. For supported OpenAI-compatible, Anthropic and Gemini ingress a base-URL change is normally the whole integration, plus one Streamable HTTP endpoint for MCP.
The messages you pass, by role. Their docs state that the most recent `user` content is screened as input and the most recent `assistant` content as output, `tool` messages are screened as untrusted content, and the `tool_calls` on an assistant message are screened as the agent’s actions — while `system` and `developer` messages are treated as trusted context and are not screened. Tool definitions go in a top-level `tools` array and can be sent on their own. AI Guardrails screens the last interaction; earlier messages provide context but are not re-screened.
The payload it is already holding: the system prompt, every message block, tool results, tool-call arguments, tool definitions and their JSON schemas, and vendor passthrough fields, because a prompt smuggled into an unknown top-level field is read by the model exactly like one in the messages array.
A screening API you call rather than a hop your model call travels through: their docs describe posting the messages to `api.lakera.ai/v2/guard` and receiving a flagging response, which is why it can be placed in front of any model. Routing calls to model providers, holding provider credentials or normalising provider usage is not described in their published documentation as of 2 September 2026.
First-class upstreams: OpenAI, Anthropic, Gemini, OpenRouter, Bedrock and Azure OpenAI, with identical policy, redaction, budgets and tracing enforced by a table-driven test over every provider kind.
Not a like-for-like row. Being provider-agnostic is why their screening works anywhere; being provider-aware is why Token Observe can price a call and refuse it before egress.
Their integration guide says to screen tool definitions before exposing them to the model, such as during the initial MCP handshake and whenever they change. Agent discovery builds an inventory of agents, their tools and their connected MCP servers, described as an early access release.
One endpoint in front of every registered upstream server, tools namespaced and filtered to the agent’s grants, each call re-authorised at execution, and each descriptor hashed at approval so an upstream rewrite quarantines the tool.
What it enforces
Your application. Their integration guide states that AI Guardrails provides a boolean `flagged` response and an optional detailed breakdown, and your application determines the appropriate action — block the input, block the output, ask the user to confirm, or log it and do nothing.
Token Observe. On a block verdict the payload never leaves the network, the caller receives a typed `ACP_POLICY_BLOCKED` error, and the trace closes as blocked with the rule that fired named on it.
This is the row the page exists for. Their design is deliberate and their docs say so — flexible detection with the response logic left to the customer.
Project mode, set per project. Their docs describe Detect mode forcing the top-level `flagged` field to false while detector results still appear in the breakdown and the dashboard, and Enforce mode returning `flagged: true` when any configured guardrail triggers — switchable from the dashboard without touching the integration.
Shadow mode, set per rule. A shadow rule is evaluated exactly as an enforcing one and then its match is recorded and skipped, on both the request and response legs and on both transports; a new policy created in the console defaults to shadow.
Two different granularities. Theirs turns a whole integration passive in one click; Token Observe stages one rule at a time while the rest keep enforcing.
A policy selects which guardrails run and at what flagging sensitivity — L1 lenient to L4 paranoid, L4 being their default — and each project is assigned to exactly one policy, while multiple projects may share one. A request with no `project_id` falls back to the AI Guardrails Default Policy, which their docs describe as running all Check Point managed guardrails at the strictest L4 sensitivity so applications are secure by default.
A trigger, an action and a scope. Seven trigger kinds — tool and argument values, model and estimated size, spend, rate, detected data classes, injection score and source, hour of day — resolved to one verdict in which a block beats an approval and an approval beats a redaction.
Prompt Defense, described as detecting direct and indirect prompt attacks including jailbreaks and prompt injections, screening 100-plus global languages and scripts, and built as managed guardrails combining machine learning and language models with rule-based filters, updated on a daily basis. Custom guardrails, in beta, compile a plain-language description into pattern and semantic rules.
Nine weighted regular expressions over Unicode-sanitised text, summed, multiplied by 1.25 when the source is a tool result, capped at 1, and not scanned past 64 KB. A phrasing nobody wrote a pattern for scores zero.
Detection quality is their product. If it is your requirement, this row decides the purchase in their favour.
The Dangerous Deviation detector, which judges a tool call against the conversation history and flags only when the action is dangerous and nothing in the trusted `user` and `system` messages warrants it, and the Tool Allow/Deny List, which their docs describe as deterministic at the moment of tool invocation. Their docs state both surface as detections in the Guard API response, in the logs and analytics, and can be exported to a SIEM.
Deny-by-default action-level permissions resolved before egress — an action no role names is refused, an explicit deny beats every allow, and a delegation chain intersects rather than unions, so a low-privileged agent gains nothing by asking a higher-privileged one to act for it.
Different questions: theirs asks whether this call fits the conversation, Token Observe asks whether this agent was ever allowed to make it.
Their integration guide lists triggering a confirmation with the user as one application-side response pattern to a flag. A built-in approval workflow with a named approver, a recorded rationale and an expiry is not described in their published documentation as of 2 September 2026.
A 403 carrying an approval id, bound to the SHA-256 of the canonical action plus its execution context, single-use through a compare-and-set, expiring at 60 minutes by default and configurable from one minute to seven days.
The Policy Impact Simulator compares flagging rates across all sensitivity levels using your historical traffic, and their integration guide recommends starting in Detect mode, says around 6,000 representative data points typically suffices for calibration, and offers collaborative detector tuning with their team.
A backtest replays a candidate rule against up to 20,000 recorded traces over a 30-day default window and reports the break rate. Where a deployment turns the gate on, no rule may begin enforcing until a named person has acknowledged that backtest, and the acknowledgement is single-use.
What it records
A Logs page listing each individual `guard` screening request with the checks performed, the detection results, the project identifier, the latency and the processing region, plus a Threats tab that shows detections regardless of project mode, with the mode configured at screening time on every row.
One trace per governed request, carrying the tool calls, results, usage and policy decisions, searchable in plain English through a validated filter object over fourteen allow-listed fields — never SQL — with the interpreted filter shown back as editable chips.
By default all prompts and model outputs from the screening request are recorded for display and analysis, and an admin can disable prompt logging, after which the input content is not stored and is not available for later inspection. PII is masked before logging regardless of detector configuration and displayed as its entity type.
Content is redacted before storage, secrets are never tokenised reversibly, and the full-text index is built over redacted content only. Default trace retention is keep-forever, so how long you keep it is a decision you make rather than one made for you.
Their dashboard documentation states SOC 2 Type II certification and that all data processed or stored is encrypted at rest and in transit. A hash-chained, checkpointed or otherwise tamper-evident log structure is not described in their published documentation as of 2 September 2026.
A hash-chained audit log whose rows each cover the previous row’s hash, a MAC checkpoint sealing the head at every boot, and an optional Ed25519 anchor published off-box on a schedule. Tamper-evident, not tamper-proof.
Automatic log export to an S3 bucket, listed as an Enterprise feature, delivering regular JSONL dumps under an hourly path for SIEM ingestion or local analysis, and supporting any storage that speaks the S3 protocol. Admins are emailed if the credentials stop working.
A compliance export containing the traces, the approvals with approver identity and rationale, the audit entries and a chain verification result naming the sequence number of any break, sealed with a SHA-256 digest. The bundle is digest-sealed and not itself signed.
Three dashboard roles — User, Admin and No access — with RBAC configuration listed among the features available to Enterprise customers, and every member shown with a unique user id for auditing.
Reads of the trace list, search, detail and export are themselves attributable, and spend figures and recertification evidence are gated on the reader’s team scopes as well as their role; surfaces that join records with no trustworthy team key return 403 rather than a misleading partial view.
Data retention control is listed among the features available to Enterprise customers. The specific retention periods available are not described in their published documentation as of 2 September 2026 — ask them.
Retention is yours because the database is yours. The published default is keep-forever, which is a choice you should make deliberately rather than inherit.
How it deploys
A fully managed SaaS at api.lakera.ai, or self-hosted on-premises or in a private cloud through a Helm chart, a Docker container, or an air-gapped deployment with containers exported and loaded without internet access.
Self-hosted only. One Node process, one SQLite file, five surfaces, bring-your-own-key, and no phone-home: the vendor receives no product telemetry, prompts, keys or trace database.
On SaaS, to whichever regional endpoint you send it to — US multi-region, us-east-1, us-west-2, eu-west-1 or ap-southeast-1. Their docs are explicit that requests are processed wherever they are sent and that choosing the endpoint is your responsibility. Self-hosting keeps all data within your own infrastructure.
Governed payloads leave your network only for the model and tool providers you configure, after policy and redaction. There is no vendor tier to send them to.
A storage region separate from the processing region, defaulting to EU, set when the organisation is created and not changeable afterwards — their docs say to use separate organisations if you need logs in more than one region. An `allowed_processing_regions` setting rejects requests sent to other regions with a 4xx.
The logs are rows in a SQLite file on a host you chose, so residency is wherever you put the host.
The screening service, an API gateway for request routing and prompt chunking, Triton Inference Server for GPU-accelerated text classifiers and Triton TensorRT-LLM for Audio Guard, on stateless containers that scale horizontally, with autoscaling, TLS, health probes and Kubernetes startup, readiness and liveness endpoints.
One process with no GPU requirement, where `packages/core` holds the entire governance domain as pure functions with zero runtime dependencies, so what allow means is reviewable without standing up any infrastructure.
Guardrails are configured through policy files, with `/policies/health` and `/policies/lint` endpoints to check one, and their docs state the dashboard is not currently available to self-hosting customers and that self-hosted deployments of the Guard API do not use authorization so do not need API keys.
The same control API, registry, approvals queue, flight recorder and SPA run in the self-hosted deployment, because it is the only deployment. Every caller authenticates: agent tokens are SHA-256’d, compared timing-safely, revocable and expiring.
Different assumptions about the trust boundary rather than a better and a worse one — theirs is a service placed inside your network, and Token Observe expects to be reachable by agents it does not trust.
SaaS deployed globally across data centres to reduce network latency, and self-hosted containers described as stateless with horizontal scaling and autoscaling support. What their SaaS commits to contractually is not described in their published documentation as of 2 September 2026 — ask them for the SLA.
A single-writer SQLite process on one host at this target scale. No replica, no clustering, no vendor-operated uptime SLA, and fail-closed: if it stops, governed agents cannot call models.
What it costs
Their dashboard documentation describes Community customers as restricted to 10,000 screening requests a month, and lists a flexible package of API requests per month, up to 1 MB of context per request, dashboard RBAC, SIEM integration and data retention control as available to Enterprise customers, arranged through their sales team.
No published price list. Self-hosted and bring-your-own-key, so provider spend goes to the providers on your own contracts and Token Observe meters it rather than reselling it.
Self-hosting requires a valid AI Guardrails Enterprise licence and container registry credentials provided by Check Point, and access to the self-hosted documentation portal is provided to customers on request.
Commercial source-available: use, modify and self-host under a licence, with redistribution and offering it as a competing hosted service not permitted. That licence is a template pending review by counsel rather than an executed grant.
Their dashboard documentation states SOC 2 Type II certification and encryption at rest and in transit. Ask them which certifications are held, for what scope and to what date, because that is the only version of the answer worth having.
None held: no SOC 2, no ISO 27001, no ISO 42001, no independent penetration test. What exists instead is a published residual-risk register, a published defect list naming the attacks that still work, and a licence that expressly permits security research and publication of results.
A Community tier you can sign up for, a playground in the dashboard, and a documented rollout that starts in Detect mode, calibrates on roughly 6,000 representative data points, enforces high-confidence detections first, and expands as policies are refined.
A 30-day evaluation written so your security team can read, run and attack the software before a purchase order is raised, with no gag clause and no pre-approval of results, running fully offline against a built-in mock provider with no API keys needed.
The verdict and the refusal are two different artefacts
Lakera’s Guard API answers a question about content and hands the answer back. Their integration guide is unusually direct about this being a design decision rather than an omission: AI Guardrails is deliberately designed to provide flexible threat detection while allowing customers to implement their own response logic, it provides a boolean flagged response and an optional detailed breakdown, and your application determines the appropriate action. The response patterns they suggest are worth reading because they are good advice — block without revealing to a bad actor that detection happened, offer a confirmation for policy violations rather than a hard stop, warn on sensitive data found in inputs and prevent egress of it in outputs. All of those are things your application does.
Token Observe is not answering a question, it is holding the request. The scan at step 5 of the eleven-step path produces an injection score and a set of detected data classes, and those become inputs to `evaluateGovernance()` at step 6 alongside the agent’s permissions, the delegation chain, the accumulated spend, the rate windows and the kill switches. Step 6 returns one verdict — allow, block, redact or require approval — and step 7 enacts it. There is no interval in which a positive detection exists and the payload is still travelling, because the same process holds both.
The practical consequence is what happens in the gap between the two systems in an estate that runs one of them. If the Guard API says flagged and the calling code has a bug, an unhandled exception path, a timeout fallback that proceeds, or simply an engineer who wired the response into a log line rather than a branch, the interaction continues. That is not a criticism of their product — it is the boundary their documentation draws, and drawing it explicitly is better than blurring it — but it is the reason a security team that has bought detection sometimes discovers it has not bought enforcement. The question to ask of your own codebase is narrow and checkable: for every place the Guard API is called, what does the code do on flagged, and what does it do when the call itself fails?
The mirror-image cost belongs on the same page. Being in the path makes Token Observe’s own availability a governance property of your environment. It fails closed, so if it stops, governed agents cannot call models, and the product’s support documentation asks you to decide before you need to what happens then. A detection API called from your application does not have that failure mode, and for an estate whose agents draft text a human reads before anything happens, that alone may be the right reason to choose differently.
- Their flag
- `"flagged": true`, with an `action` field carrying `"enforce"` in their worked example, and, with `"breakdown": true`, the guardrails that ran, whether each detected, and the confidence of each result.
- Token Observe’s refusal
- A typed `ACP_POLICY_BLOCKED` error, the trace closed as blocked with the rule named on it, and the trace id returned in `x-acp-trace-id` on every response including that one.
- The streaming case
- A stream cannot answer 403 because the status line is spent on the first byte, so response-side policy is resolved before the first byte from the policies that could apply, and a blocking class ends the stream with an in-band frame the instant it is seen.
What bounds an injection that both products miss
Assume the detector missed it, because sometimes it will and both vendors say so in their own way. Lakera’s Dangerous Deviation detector ships, in their words, in a conservative configuration that favours a low false-positive rate over catching every marginal case, and they recommend running it in Detect mode first. Token Observe’s nine heuristics have false negatives recorded on a residual-risk register requiring a named CISO’s dated written acceptance. Neither product should be bought on the assumption that nothing gets through, and the more useful question is what a hijacked agent can actually do once one does.
Token Observe’s answer is that a hijacked agent inherits the authority it already had and nothing more. Permissions are action-level and deny-by-default: a support agent may `Read: Customer Account` and `Update: Shipping Address` while `Delete: Account` is simply absent and therefore denied. An explicit deny beats every allow wherever it is written. A delegation chain intersects rather than unions across every hop, so an agent that has been talked into asking a higher-privileged agent for help gains nothing by asking. None of that depends on recognising the attack, which is the point: it is the same refusal whether the instruction came from a customer, a poisoned ticket body or nobody at all.
Above the permission layer sit three gates with the same property. A policy can require a human approval, and that approval is bound to the SHA-256 of the canonical action plus the execution context it was proposed in, is single-use through a compare-and-set, and expires — so a retry with one argument changed is refused as a mismatch rather than allowed as near enough. Hard USD ceilings per request, per rolling hour, per UTC day and per UTC month are projected and reserved before egress in one per-agent transaction, and an unpriced resolved target is refused rather than guessed at. A kill switch scoped to one agent, one team or everything is checked first in the pipeline. An injection that persuades an agent to do something expensive runs into the ceiling; one that persuades it to do something consequential runs into the approval; one that persuades it to do something it was never permitted runs into the permission set.
The honest boundary on all of it is that Token Observe can only refuse a proposal it is shown. Tool calls the model proposes are evaluated against policy on the way back, which is why a rule about refunds over a threshold binds even when the agent executes the tool itself, but an agent that never routes any traffic through the gateway is caught by the shadow-AI radar if you have fed the radar, and not at all if you have not.
A screening log and an evidence chain are read by different people
Their Logs page is built for the security engineer investigating an attack, and it is well shaped for that: each screening request with the checks performed and their results, a Threats tab that shows detections regardless of project mode so you can analyse traffic while Enforce is off, latency and processing region on every row, and project tags for slicing production against test or external against internal. PII is masked before it is written, so a name arrives in the store as `<NAME>`, and an admin can turn prompt logging off entirely, after which the content is not stored and is not available for later inspection. Export to an S3-compatible bucket delivers hourly JSONL for your SIEM.
Token Observe’s record is built for a different reader and carries different obligations because of it. The audit log is hash-chained, each row’s hash covering its canonical content plus the previous row’s, so an edit or a deletion breaks verification at a known sequence number rather than disappearing. Appends take the chain tip inside the same transaction, so concurrent writers cannot fork it. A checkpoint MACs the head at every boot, and an optional Ed25519 anchor publishes the head to a sink you site outside the database administrator’s control — which buys exactly one thing, stated narrowly: any copy you kept off-box beats any rewrite made after you took it. The anchoring code refuses more often than it signs, declining to anchor a chain that does not verify or a head that has moved backwards, because signing over a rewrite would launder it under a key auditors trust.
Reads are attributable for the same reason. A compliance officer opening a trace, running a search or generating an export leaves a record of having done so, and spend figures and recertification evidence are gated on the reader’s team scopes as well as their role. Search is deliberately constrained to a validated filter object over fourteen allow-listed fields and never becomes SQL, because trace content is attacker-influenced by construction; the cost of that design is stated in the same breath, which is that the filter cannot group, count or correlate across traces.
Neither record replaces the other, and an estate running both ends up with two logs that answer different questions — which is fine, and worth planning for rather than discovering. Their log tells you what the detectors saw across every application that calls the Guard API, including the ones that never touch a gateway. Token Observe’s chain tells you what was authorised, by whom, against which budget, and whether the head you are being shown is the head. If you want them in one place, their S3 export is the seam: Token Observe’s shadow-AI radar has a generic receiver shape that reads its own field names for any tool able to export on a timer, so mapping their JSONL onto it is integration work you would be doing rather than a connector that ships.
- What a compliance export contains
- The traces and events for the period, the approvals with approver identity and rationale, the audit entries covering every governance-plane change, a chain verification result naming the sequence number of any break, and a SHA-256 digest of the bundle generated at a recorded time. The bundle is sealed, not signed.
- What happens if the chain fails to verify
- The boot walk latches readiness and audit writes unavailable and governed requests receive a 503 carrying `ACP_AUDIT_UNAVAILABLE`. There is intentionally no online clear, so recovery means restoring a database whose chain and independently retained head verify.
- What neither product evidences
- Agents that route around both. Their coverage is the applications that call the Guard API; Token Observe’s is the agents that present a credential to its gateway. Absence of evidence is not evidence of absence, and both products’ documentation says so in their own terms.
Where each one is the right answer
Choose Lakera when
- Detection quality is the requirement. A maintained detector suite screening 100-plus languages, updated daily, tuned across four sensitivity levels and calibrated against your own traffic is their product and it is not Token Observe’s nine published heuristics.
- You need to screen applications that will never route through a gateway — a RAG ingestion pipeline, a knowledge-base upload, a batch document scan, a copilot embedded somewhere no proxy sits — because the Guard API is a call you can make from anywhere.
- Your procurement gate is a certification. Their documentation states SOC 2 Type II; Token Observe has no SOC 2, no ISO 27001, no ISO 42001 and no independent penetration-test result, and will tell you so on the first call.
- You want audio screening, content moderation or malicious-link detection alongside prompt defence — their published material describes all three, and Audio Guard has its own inference server in the self-hosted package. Token Observe does none of them, and its roadmap names a generic prompt scanner or red-team platform as a strategic non-goal.
- You cannot accept a fail-closed dependency in the request path, which is a legitimate position and one a detection API called from your own code does not impose on you.
Choose Token Observe when
- The refusal itself has to happen outside the application, because the application is what you are worried about — an agent written by another team, or one nobody has re-read since it was generated.
- The decision you need is about authority rather than content: whether this agent may issue this refund at all, who approved this exact payload, and whether the budget survives it.
- You need a human decision bound to one exact payload rather than to an action type, single-use and expiring, with the approver’s identity and rationale recorded against the trace.
- Someone will eventually ask who says the head you are showing me is the head, and a screening log with encryption at rest is not an answer to that question.
When you would run both
Running both is the normal answer, and Token Observe’s own strategy document reaches it independently: a generic AI firewall or prompt scanner is a named non-goal, and the instruction is to consume threat and identity signals from vendors including Lakera rather than reproduce them. The arrangement that follows is Lakera doing detection and Token Observe doing authority. Their Guard API screens the interaction — user turns, model outputs, tool results, tool calls and tool definitions — with detectors maintained by people whose whole job that is, and Detect mode lets you roll it out across every application including the ones no gateway sees. Token Observe governs the agents that take consequential actions: deny-by-default permissions, payload-bound approvals, hard spend ceilings, a kill switch, and a hash-chained record of every verdict. Where the two meet in practice today is your integration code — the Guard API call sits in the application or at your gateway, and Token Observe’s own injection heuristics stay as the compensating control they are documented to be rather than as a second opinion you rely on. Be clear-eyed that a purpose-built connector between them is not something the repository ships: the shadow-AI radar has a generic receiver that reads Token Observe’s own field names for any tool able to export on a timer, and pointing Lakera’s S3 log export at it is mapping work you would own. Start with detection where the risk is content, add enforcement where the risk is action, and do not let either product’s documentation persuade you that it covers the other half.
The category argument sits above this one: Token Observe and ai security platforms covers what the whole category does and does not do, which is the better page to read if you have not yet shortlisted a product.
The others in the same slot
Keycard
Keycard decides whether the agent gets a credential. Token Observe decides the call and then proves what the call actually did.
Palo Alto Prisma AIRS
Prisma AIRS decides whether the content is malicious. Token Observe decides whether the agent that sent it was allowed to.
Cisco AI Defense
AI Defense attaches a policy to an application’s connection and inspects what crosses it. Token Observe attaches permissions to an agent and decides what it may do.
Zenity
Zenity gets into the path the agents are already on. Token Observe is the path the agents are pointed at.
Noma Security
Noma decides from what the agent appears to be doing. Token Observe decides from what the agent was allowed to do, before anything is scored.
WitnessAI
WitnessAI stands in front of the interaction and classifies the intent. Token Observe stands in front of the API call and decides the action, its cost and its evidence.
Does Token Observe replace Lakera?
No, and on the capability this page is categorised under it should not be asked to. Lakera’s published material describes a maintained prompt-attack detector screening 100-plus languages and scripts, updated daily, with four sensitivity levels, a simulator that compares flagging rates against your historical traffic, and custom guardrails compiled from a plain-language description. Token Observe’s injection scoring is nine weighted regular expressions over Unicode-sanitised text, multiplied by 1.25 when the source is a tool result, capped at 1 and not scanned past 64 KB — documented as a compensating control rather than as the customer’s only defence, with the false negatives on a residual-risk register requiring a named CISO’s written acceptance. What Token Observe adds is the layer that does not depend on recognising the attack: what the agent was permitted to do, who approved the exact payload, what the spend ceiling allowed, and what the audit chain says afterwards.
Lakera has an Enforce mode. Is that not the same as blocking?
Not quite, and their documentation is precise about the difference. In Enforce mode the Guard API returns `"flagged": true` when any guardrail in the project’s policy detects a threat; in Detect mode that field is forced to false while the detector results still appear in the breakdown and the dashboard. Their integration guide then says that you decide within your applications what to do with a flagged response — block the input, block the output, ask the user to confirm, or log it and do nothing. So Enforce mode governs what the API tells you, and your application governs what happens next. Their reason for that split is a good one, and they state it: it means you can switch a project to passive from the dashboard without touching the integration. The consequence a buyer should plan for is that the enforcement path lives in code your team maintains, so it is worth checking what every call site does on a flag and on a failed call.
Can we self-host both?
Yes, on their published material. Lakera documents self-hosting through a Helm chart on any Kubernetes cluster, through Docker or an OCI-compatible runtime, and air-gapped with containers exported and loaded without internet access, keeping all data within your own infrastructure — requiring a valid AI Guardrails Enterprise licence and container registry credentials provided by Check Point, and with GPU-accelerated inference through Triton Inference Server. Two differences are worth knowing before you plan the deployment: their documentation says the dashboard is not currently available to self-hosting customers and that self-hosted projects and policies are configured through a policy file, and that self-hosted deployments of the Guard API do not use authorization so do not need API keys. Token Observe is self-hosted only, runs as one process with one SQLite file and no GPU requirement, ships the same dashboard and control API in every deployment because there is only one deployment, and authenticates every caller.
Which one sees indirect prompt injection in tool results?
Both, by design, and both say why. Lakera’s documentation states that prompt attacks do not only arrive through user messages, that for AI agents the same attacks can be embedded in a poisoned tool response, a compromised page retrieved by a tool or an instruction hidden in a tool’s description, and that you should pass tool results as `tool` role messages and screen tool descriptions as content when a new tool or MCP server is added. Token Observe scans each fragment under its own source and multiplies a tool result’s score by 1.25, so a directive scoring 0.4 from a user scores 0.5 from a tool and a rule set at a minimum confidence of 0.5 fires on the ticket body without blocking the person typing into your support console. The difference is not whether the channel is covered but what happens next: their screening returns a detection, and Token Observe’s returns a refusal or an approval request on the same request.
Have you tested Lakera against Token Observe?
No. Everything on this page about their product is taken from their own published documentation read on 2 September 2026 — the Guard API endpoint, policies, projects, integration guide, Agent Behavior Defense, Prompt Defense, the guardrails overview, the AI Agent Security overview, the dashboard, self-hosting, the API overview and data regions, plus Check Point’s own press release announcing the acquisition of Lakera, which is why the vendor company on this page reads Check Point — and none of it has been independently tested. There has been no witnessed bake-off, and one is named in Token Observe’s own launch gates as evidence that does not yet exist. Nor should the absence of a capability from this page be read as its absence from their product: their documentation states that AI Agent Security is an early access release that develops quickly, so the accurate account of it on any given day is the one you get from them. Where a cell here says a capability is not described in their published documentation, that is a question to put to them in writing rather than a finding.
Prefer to ask a person? Write to us →
Tell us which one you are already running.
If Lakera is already in your stack, the useful question is not which to buy but what each is for, and where the seam between them sits. Say what you have and you will get a straight answer — including when the answer is that you do not need a second thing.
no form · no qualification step · no sales desk · the other three ways in