Lakera

Lakera connects to agent platforms to discover agents and assess their risk, and it screens traffic through the Guard API. For red teaming it reaches customer agents through custom API wrappers, and it exports logs to SIEMs. All of this brings traffic in for screening and testing; no connector lets an agent take authenticated action in an outside system through Lakera.

SourceLakera (Check Point), docs.lakera.ai llms.txt (connecting agent platforms, integration guide, Red custom API formats)read 2026-09-25

The customer's agents run in their own frameworks, which own the steps and handoffs; Lakera screens and tests those agents without running their work. Red team scans are attack runs against a target, not agent work in several steps that the customer builds, and no workflow model is documented.

SourceLakera (Check Point), docs.lakera.ai llms.txtread 2026-09-25

Retrieved documents are screened for threats, but none of the customer's documents are indexed for an agent to ground its answers on, so there is no retrieval structure over the customer's corpus.

SourceLakera (Check Point), docs.lakera.ai llms.txtread 2026-09-25

AI Guardrails screens prompts, responses and agent conversations inline against guardrails the customer sets in policies for each project: prompt defense, content moderation, data leakage prevention, malicious link detection, agent behavior defense and audio defense. Custom guardrails and allow and deny lists sit alongside them, and the policies come with a linter and a health check. These guardrails stop an input or output outright; no human approval step is documented.

SourceLakera (Check Point), docs.lakera.ai llms.txt (defenses, policies, projects, Guard API, policies linter)read 2026-09-25

The access surface is deep. Enterprise plans get organization SSO, role based access control and organization settings that only admins can change. AI Red Teaming adds two layers of roles, organization roles (admin, member) and folder roles (viewer, member, admin), with a table of what each can do, plus API keys scoped to a folder that members create and admins revoke. Admins can switch prompt logging and data retention on or off, and PII is masked before logging.

No attestation appears. The docs' security link, lakera.ai/security, now redirects to Check Point's AI security page, which names no certification, and the Lakera pages show no trust center link.

SourceLakera (Check Point), docs.lakera.ai/docs/platform.md and /docs/red/folder-roles.md, and lakera.ai/security; docs.lakera.ai/docs/platformread 2026-09-25

Every screening request is logged on the AI Guardrails dashboard with the exact content screened: prompts, responses and agent conversations with their roles. Each entry also shows the checks run, the project mode and the detection results, a Threats view and analytics by project and time range sit on top, and the Platform API returns logs and analytics. Admins control prompt logging and data retention, Enterprise customers export logs to a SIEM, and AI Red Teaming keeps a separate audit trail through its management API. So the record holds the agent's own traffic, not only security events.

SourceLakera (Check Point), docs.lakera.ai/docs/platform.md and llms.txt (logs, analytics, Red audit trail, screening agent conversations); docs.lakera.ai/docs/platformread 2026-09-25

Screening logs and red team target profiles describe the customer's agents; they are not memory for them, and the agent never reads them as context to decide. No memory layer is documented.

SourceLakera (Check Point), docs.lakera.ai llms.txtread 2026-09-25

Customers pick where screening runs by choosing an endpoint, a US endpoint across several regions, US East, US West, EU Ireland or Asia Singapore. They also set where logs are stored when the organization is created, with the EU as the default. AI Guardrails can be self hosted on premises or in a private cloud, through a Helm chart for any Kubernetes cluster, plain Docker or a fully air gapped install.

SourceLakera (Check Point), docs.lakera.ai/docs/data-regions.md and /docs/selfhosting.md; docs.lakera.ai/docs/data-regionsread 2026-09-25

Prebuilt detectors for prompt defense, content moderation, data leakage prevention, malicious links, agent behavior and audio are ready for the customer to assemble into policies, and evaluation datasets support proof of value testing. They are libraries the customer puts together, not packaged agents or workflows a buyer adopts as working units.

SourceLakera (Check Point), docs.lakera.ai llms.txt (defenses, datasets)read 2026-09-25

Lakera does not start agents. Screening runs when the customer's code calls the Guard API, and red team scans start on demand or from the customer's own CI/CD pipeline, a gate the customer already owns. No schedule, webhook or event of Lakera's own wakes work.

SourceLakera (Check Point), docs.lakera.ai/docs/red/sdk-how-tos/run-scans-in-ci-cd.md and llms.txt; docs.lakera.ai/docs/red/sdk-how-tos/run-scans-in-ci-cdread 2026-09-25

Screening runs through Lakera's own detection models, and the customer's model calls are not proxied or routed: the application calls the Guard API alongside whatever model it already uses. Red Teaming targets are the customer's models under test, not a choice of models inside Lakera, and no model or provider for Lakera's own AI can be selected.

SourceLakera (Check Point), docs.lakera.ai llms.txt (integration guide, Guard API, Red targets)read 2026-09-25

A published API covers the platform, with an OpenAPI 3.1 specification. The Guard API screens content and returns detailed results, and it also lints policies and checks their health. The Platform API manages policies and projects end to end and returns logs and analytics. AI Red Teaming adds a versioned SDK and a management API for folders, members and API keys, along with the audit trail. The MCP server on docs.lakera.ai serves the documentation, not the product.

SourceLakera (Check Point), docs.lakera.ai llms.txt (API docs, OpenAPI spec, Red SDK and management API)read 2026-09-25

AI Red Teaming tests the customer's own models and agents. Targets connect to a model or a custom agent API, scans run attack objectives against them, and each result carries an attack success score from 0 to 5, an indicator and an explanation, with a pass or fail verdict. A documented CI/CD gate script runs a scan on each release and fails closed, blocking on failed, errored or unscored results, with custom pass and fail criteria. Tool tracing covers agent tool calls during scans. Testing AI systems is what Lakera sells, and the artifact under test is the customer's.

SourceLakera (Check Point), docs.lakera.ai/docs/red/sdk-how-tos/run-scans-in-ci-cd.md and llms.txt (red quickstart, interpreting results, trace agent tools); docs.lakera.ai/docs/red/sdk-how-tos/run-scans-in-ci-cdread 2026-09-25

Lakera screens and tests AI traffic and does not operate a browser or a computer; no capability of that kind is documented.

SourceLakera (Check Point), docs.lakera.ai llms.txt and lakera.airead 2026-09-25