Guard API Endpoint
The guard API endpoint is the integration point for GenAI applications using Lakera Guard. It allows you to call on all of Lakera Guard’s defenses with a single API call.
Using guard, you can submit the text content of an LLM interaction to Lakera Guard. The configured detectors will screen the interaction, and a flagging response will indicate whether any threats were detected, in line with your policy.
Your application can then be programmed to take mitigating action based on the flagging response, such as blocking the interaction, warning the end user, or generating an internal security alert.
Integration Point
It is recommended to call guard for screening every LLM interaction at runtime. The guard screening request should be integrated into the program flow after the LLM response has been generated but before it’s been returned to the end user or the rest of the application. This ensures there are no bad outcomes or damage caused and minimizes added latency.
Optionally, guard can additionally be called before sending the input to the LLM if there are risks of data leakage to third party LLM providers.
In a RAG context, guard can also be used for pre-processing documents and content to screen for data poisoning and indirect prompt attacks when added to the reference knowledge base.
It is strongly recommended to pass the whole interaction, conversation history and system prompt in guard requests to get the highest accuracy and prevent multi-step attacks.
API Endpoint
Flagging Logic
When the detectors specified in the policy are run during a screening request, they will be marked as “flagged” if they detect a threat. If any of the detectors flag then the guard request returns flagged equals true. If none of the detectors flag then the guard request returns flagged equals false.
You can decide within your applications what mitigating action to take to handle flagged responses.
For example, you could choose to block the LLM response being shown to the user and instead return “I’m sorry I can’t help with that”. You could trigger a confirmation with the user whether they want to proceed. You could also choose to log the response for analysis and monitoring afterwards.
Optionally, a breakdown of the flagging decision can be returned in the response. This will list the detectors that were run, as defined in the policy, and whether each of them detected something or not.
Policies and Projects
The configuration of the detectors that will be used to screen the contents, the flagging logic, and their strictness are all controlled via an assigned policy within Lakera Guard.
You can set up multiple custom policies to tailor and fine-tune the defenses for each integration into Lakera Guard. For more information and guides, please refer to the Policies documentation.
We use the flexible concept of a project to set, configure, track, understand, and compare the security and threat profiles of each GenAI application and component.
A project is any deployment or integration of Lakera Guard, or collection of integrations, that you want to track performance and configure a single defense policy configuration for.
Your projects could correspond to different applications, environments, individual app components, or even end users. For more information and guides, please see the Projects documentation
Each project has one policy assigned. The same policy can be assigned to multiple projects.
By passing a project_id in a guard request, this specifies the relevant project and determines the policy that will be used for screening that request.
If no project_id is passed in the guard request, then the Lakera Guard Default Policy will be used. The Guard Default Policy screens any content passed with all of Guard’s defense categories and detectors (Prompt defense, Content Moderation, Data Leakage Prevention, Unknown Links).
Masking using payloads
guard can optionally return a payload listing the string location and type of any PII, profanity, or custom regular expression matches detected. This can then be used by your application to mask sensitive contents before passing to the LLM or returning to the end user.
To do this, pass "payload": true in the request body (see below).
Latency considerations
The latency of the guard API response depends on the length of the content passed for screening, as well as the detectors run according to the policy.
Note that making changes to a policy may have an impact on the latency experienced by your application. If you need help aligning your policies to meet strict latency requirements please reach out to support@lakera.ai.
Setting up Lakera Guard
The following diagram gives a high level overview of the process of setting up Lakera Guard and performing screening requests.
