Projects
Developers often use multiple GenAI-powered applications for different use cases, each with multiple components using LLMs for different purposes. Lakera Guard is designed to operate on every part of your application that uses GenAI.
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, or individual app components, or even a mixture.
Projects allow you to:
- Tailor and fine-tune your defenses for each of your use cases via mapping to a policy
- Monitor your external customer-facing GenAI applications separately from your internal GenAI tools
- Compare performance between development environments and production
- Isolate which part of your application is currently being exploited
For example you could have a project for your production customer support chatbot and a separate one for your internal employee knowledge base Q&A tool. Or you could have two projects for each of those apps, for the test and production environments, to track and compare them separately.
Managing Projects in Guard
Customers that are self-hosting Lakera Guard need to set up their projects via a policy file. Please see the details here.
SaaS customers can manage their projects within the Lakera Guard platform user interface or via the projects API endpoint. The Projects page allows you to create new projects and lists each of your existing projects along with its details.
Every project is assigned a unique project ID and can be labeled with tags, including custom tags. Any screening request made passing this project ID in the API will be identified as part of that particular project and will carry the associated metadata tags. For details, please refer to the metadata documentation.
For instructions on how to include the project ID in API requests, please refer to the API documentation.
Each project must be assigned to a policy, which defines the defense configuration that Guard will use when running screening requests for that project. If a screening request is submitted without a project ID then the Lakera Guard Default Policy, which runs all Guard defenses, will be used.
If you wish for your application to use different policies depending on the situation then you will need to create multiple projects, one for each policy, with the relevant metadata tag for grouping in analysis. Then set the application to pass the relevant project ID depending on the required policy.
Creating a project
For enterprise customers, projects can only be created by admins.
Initially, there won’t be any projects created for you. Admins can create a new project by clicking on the + New project button.
The only required field is the Project Name.
You can optionally add tags to the project. Tags allow you to apply your own metadata. We offer the optional tags Application and Model, but you can also create your own custom tags by specifying the tag name and value. Tag names are matched across projects for analysis and comparison.
For example, you could use the Application tag to compare model performance across all your apps, or create your own “Environment” tag and use it to monitor only production projects.
Next, assign the policy for the project using the dropdown. If you need to define a new custom policy for the project this must be done via the policies page in SaaS deployments and in the policy file for self-hosting deployments.
After a project is created, a unique Project ID will be generated automatically. This Project ID needs to be passed in all API requests for this project. See the API documentation for details.
Once you’ve started making API requests using the Project ID, you can filter the Dashboard and Requests pages to only display data from that specific Project.
Editing projects
Policies can only be edited or deleted by admins.
Click on the three dots near the Project’s name to view details, edit or delete it.
Changing assigned policy
You can change the policy used by the project at any time. Note that once changes to the assigned policy are saved, they will take immediate effect. This enables you to respond quickly, but means you should be careful when changing policy in order not to accidentally negatively impact your GenAI application or users.
Editing metadata tags
Note that modifying Project metadata tags will affect past logs associated with the same Project ID. To give an example, if a project has the tag Model with the value gpt-3.5 to begin with and after a period of time the application switches to using GPT 4, if the project tag is updated then all the previous requests that were made to GPT 3.5 will incorrectly show as using gpt-4 in Guard.
To keep historic request logs unaffected when project attributes change, create a new project with updated metadata and switch to using the new Project ID in requests.
Deleting projects
Make sure to update your application to use a new project ID before deleting a project, as API requests will fail if they use a project ID from a deleted project.
Admins can click on the three dots near the Project’s name to see the option to delete it. After clicking on this, confirm the deletion in the pop up.
Please note that deleting projects is irreversible. When a project is deleted, historic requests that used that Project ID will no longer be associated with any project, which means they will no longer include the deleted Project’s metadata tags or use the Project’s assigned policy. This will not affect any request-specific metadata, e.g. session ID or user ID, which will remain attached to the request.