Lakera Guard

@lakera-guard screen the user's last message for prompt injection and jailbreak attempts before we process their request

Lakera Guard screened the latest user message against your project's policy. Result: **flagged** for prompt injection (confidence: 0.92). The policy's detect-or-flag action is set to 'flag', so the interaction was logged but not blocked. Categories triggered: prompt_injection. No jailbreak patterns detected. This example illustrates a typical runtime screening workflow—your application would read the flagged status and decide whether to halt processing or log the event for review.

Screen Content is Lakera's core runtime tool. It evaluates only the most recent message; earlier conversation turns provide context but aren't individually scored. You must configure a project and assign a policy before screening. The MCP returns a binary flag plus per-detector confidence scores—your code enforces the block.

@lakera-guard create a new policy called 'customer-support-v2' that detects prompt injection, PII leakage, and toxic language, then assign it to our support chatbot project

Policy 'customer-support-v2' created with detectors: prompt_injection, pii, toxicity. **Note:** Lakera's API does not return the new policy ID in the creation response, so the MCP cannot automatically assign it to your project in a single step. You'll need to retrieve the policy by name or list all policies, locate the ID, then call Update Project separately to assign it. This example shows the two-step workflow required when Lakera omits generated IDs.

Create Policy and Create Project both suffer from Lakera's missing-ID response design. The MCP can build the policy, but you must manually retrieve the ID before assignment. This is a known API limitation, not an MCP bug. Plan for a follow-up Get Policy or List Policies call in your workflow.

@lakera-guard evaluate the last five user messages against our PII and toxicity detectors without logging them, then summarize which messages would have triggered a block

Evaluated five messages using Evaluate Detectors (analysis mode—no Guard logs created). Results: Message 3 triggered PII (confidence: 0.88, detected email address). Message 5 triggered toxicity (confidence: 0.76, profanity detected). Messages 1, 2, and 4 passed both detectors. This mode is useful for tuning thresholds or auditing historical conversations without polluting your production screening logs. The MCP returned raw per-detector scores; I synthesized the block/pass decision based on typical 0.5 thresholds.

Evaluate Detectors runs offline analysis—it does not produce allow/block decisions or write to Guard's request history. Use this for policy tuning, not runtime enforcement. You must interpret the confidence scores yourself (Lakera doesn't define universal thresholds). Requires API key auth; no project assignment needed for evaluation-only calls.

When Lakera Guard catches prompt injection before your chatbot ships

A three-person support team is launching a public-facing chatbot that answers billing and account questions. They need to block prompt injection, PII leakage, and toxic output before the bot goes live. Lakera Guard is the right call here: use Create Project to spin up a screening pipeline, assign a policy with the prompt-injection and PII detectors, then pipe every user message through Screen Content. The policy returns a block/allow decision in under 200ms, so you gate the LLM call in your backend. The trade-off: you're adding a third-party API hop and a monthly seat cost. If your support volume is under 10k messages a month and you lack in-house ML, the safety ROI justifies the dependency. Set it up in an afternoon and sleep better at launch.

Use Evaluate Detectors when you need audit trails, not runtime blocks

A five-person compliance team at a fintech is auditing an internal agent that drafts loan-denial letters. They want to flag any output that leaks customer SSNs or uses prohibited language, but they can't block the agent mid-flight because the workflow is async and human-reviewed anyway. Lakera Guard's Evaluate Detectors tool is built for this: it runs the same PII and toxicity checks as Screen Content but skips the policy decision and logs confidence scores instead. You batch-process a week of agent outputs, export the flagged cases, and hand them to legal. The boundary: if you need real-time blocking, Evaluate Detectors won't help—it's analysis-only. For post-hoc audits where you're building evidence, it's faster than rolling your own detector stack.

When Create Policy scales per-customer safety rules without forking your codebase

A ten-person SaaS team is white-labeling an AI writing assistant for three enterprise customers, each with different content policies: one blocks profanity, another blocks competitor mentions, a third blocks medical advice. Lakera Guard's Create Policy and Get Policy tools let you define a policy per tenant, assign it to a project via Create Project, then route each tenant's requests to their project ID at runtime. You avoid hardcoding rules in your app logic, and customers can request policy tweaks without a deploy. The catch: you're managing policy IDs externally because Lakera sometimes omits them in the response, so you need a lookup table in your DB. If you have fewer than five tenants or identical policies across all, the orchestration overhead outweighs the flexibility. Above five, it's the cleanest way to keep guardrails tenant-specific.