chore: import upstream snapshot with attribution
CI / Shell Format Check (push) Has been cancelled
CI / Check Ruby (3.4) (push) Has been cancelled
CI / CI Config (push) Has been cancelled
CI / Test on Node ${{ matrix.node }} and ${{ matrix.os }}${{ matrix.shard && format(' (shard {0}/3)', matrix.shard) || '' }} (push) Has been cancelled
CI / Build on Node ${{ matrix.node }} (push) Has been cancelled
CI / Style Check (push) Has been cancelled
CI / Generate Assets (push) Has been cancelled
CI / Check Python (3.14) (push) Has been cancelled
CI / Check Python (3.9) (push) Has been cancelled
CI / Build Docs (push) Has been cancelled
CI / Code Scan Action (push) Has been cancelled
CI / Site tests (push) Has been cancelled
CI / webui tests (push) Has been cancelled
CI / Run Integration Tests (push) Has been cancelled
CI / Run Smoke Tests (push) Has been cancelled
CI / Go Tests (push) Has been cancelled
CI / Share Test (push) Has been cancelled
CI / Redteam (Production API) (push) Has been cancelled
CI / Redteam (Staging API) (push) Has been cancelled
CI / GitHub Actions Lint (push) Has been cancelled
CI / Check Ruby (3.0) (push) Has been cancelled
release-please / release-please (push) Has been cancelled
release-please / build (push) Has been cancelled
release-please / publish-npm (push) Has been cancelled
release-please / publish-npm-backfill (push) Has been cancelled
release-please / docker (push) Has been cancelled
release-please / publish-code-scan-action (push) Has been cancelled
release-please / attest-code-scan-action (push) Has been cancelled
Deploy local.promptfoo.app / Deploy to Cloudflare Pages (push) Has been cancelled
Test and Publish Multi-arch Docker Image / test (push) Has been cancelled
Test and Publish Multi-arch Docker Image / build-docker-and-push-digests (map[digest-suffix:linux-amd64 platform:linux/amd64 runner:ubuntu-latest]) (push) Has been cancelled
Test and Publish Multi-arch Docker Image / build-docker-and-push-digests (map[digest-suffix:linux-arm64 platform:linux/arm64 runner:ubuntu-24.04-arm]) (push) Has been cancelled
Test and Publish Multi-arch Docker Image / merge-docker-digests (push) Has been cancelled
Test and Publish Multi-arch Docker Image / Attest Multi-arch Image (push) Has been cancelled
Validate Renovate Config / Validate Renovate Configuration (push) Has been cancelled

This commit is contained in:
wehub-resource-sync
2026-07-13 13:24:08 +08:00
commit 0d3cb498a3
5438 changed files with 1316560 additions and 0 deletions
+5
View File
@@ -0,0 +1,5 @@
{
"position": 5,
"label": "Promptfoo Enterprise",
"collapsed": false
}
+247
View File
@@ -0,0 +1,247 @@
---
title: Audit Logging
description: Track administrative operations in promptfoo Enterprise with comprehensive audit logs for security, compliance, and forensic analysis.
sidebar_label: Audit Logging
keywords: [audit, logging, security, compliance, enterprise, forensics, admin operations]
---
# Audit Logging
Audit Logging is a feature of [Promptfoo Enterprise](/docs/enterprise/) that provides forensic access information at the organization level, user level, team level, and service account level.
Audit Logging answers "who, when, and what" questions about promptfoo resources. These answers can help you evaluate the security of your organization, and they can provide information that you need to satisfy audit and compliance requirements.
## Which events are supported by Audit Logging?
Audit Logging captures administrative operations within the promptfoo platform. The system tracks changes to users, teams, roles, permissions, and service accounts within your organization.
Please note that Audit Logging captures operations in the promptfoo control plane and administrative actions. Evaluation runs, prompt testing, and other data plane operations are tracked separately.
## Admin Operation events
The following list specifies the supported events and their corresponding actions:
### Authentication
- **User Login**: `login` - Tracks when users successfully authenticate to the platform
### User Management
- **User Added**: `user_added` - Records when new users are invited or added to the organization
- **User Removed**: `user_removed` - Logs when users are removed from the organization
### Role Management
- **Role Created**: `role_created` - Captures creation of new custom roles
- **Role Updated**: `role_updated` - Records changes to existing role permissions
- **Role Deleted**: `role_deleted` - Logs deletion of custom roles
### Team Management
- **Team Created**: `team_created` - Records creation of new teams
- **Team Deleted**: `team_deleted` - Logs team deletion
- **User Added to Team**: `user_added_to_team` - Tracks when users join teams
- **User Removed from Team**: `user_removed_from_team` - Records when users leave teams
- **User Role Changed in Team**: `user_role_changed_in_team` - Logs role changes within teams
### Permission Management
- **System Admin Added**: `org_admin_added` - Records when system admin permissions are granted
- **System Admin Removed**: `org_admin_removed` - Logs when system admin permissions are revoked
### Service Account Management
- **Service Account Created**: `service_account_created` - Tracks creation of API service accounts
- **Service Account Deleted**: `service_account_deleted` - Records deletion of service accounts
## Audit Log format
The audit log entries are stored in JSON format with the following structure:
```json
{
"id": "unique-log-entry-id",
"description": "Human-readable description of the action",
"actorId": "ID of the user who performed the action",
"actorName": "Name of the user who performed the action",
"actorEmail": "Email of the user who performed the action",
"action": "Machine-readable action identifier",
"actionDisplayName": "Human-readable action name",
"target": "Type of resource that was affected",
"targetId": "ID of the specific resource that was affected",
"metadata": {
// Additional context-specific information
},
"organizationId": "ID of the organization where the action occurred",
"teamId": "ID of the team (if applicable)",
"createdAt": "ISO timestamp when the action was recorded"
}
```
### Audit Log Targets
The system tracks changes to the following resource types:
- `USER` - User accounts and profiles
- `ROLE` - Custom roles and permissions
- `TEAM` - Team structures and memberships
- `SERVICE_ACCOUNT` - API service accounts
- `ORGANIZATION` - Organization-level settings
## Example Audit Log Entries
The following examples show the contents of various audit log entries:
### User Login
```json
{
"id": "550e8400-e29b-41d4-a716-446655440000",
"description": "john.doe@example.com logged in",
"actorId": "user-123",
"actorName": "John Doe",
"actorEmail": "john.doe@example.com",
"action": "login",
"actionDisplayName": "User Login",
"target": "USER",
"targetId": "user-123",
"metadata": null,
"organizationId": "org-456",
"teamId": null,
"createdAt": "2023-11-08T08:06:40Z"
}
```
### Team Creation
```json
{
"id": "550e8400-e29b-41d4-a716-446655440001",
"description": "jane.smith@example.com created team Engineering",
"actorId": "user-789",
"actorName": "Jane Smith",
"actorEmail": "jane.smith@example.com",
"action": "team_created",
"actionDisplayName": "Team Created",
"target": "TEAM",
"targetId": "team-101",
"metadata": null,
"organizationId": "org-456",
"teamId": "team-101",
"createdAt": "2023-11-08T09:15:22Z"
}
```
### Role Update
```json
{
"id": "550e8400-e29b-41d4-a716-446655440002",
"description": "admin@example.com updated role Developer",
"actorId": "user-456",
"actorName": "Admin User",
"actorEmail": "admin@example.com",
"action": "role_updated",
"actionDisplayName": "Role Updated",
"target": "ROLE",
"targetId": "role-202",
"metadata": {
"input": {
"permissions": ["read", "write"],
"description": "Updated developer permissions"
}
},
"organizationId": "org-456",
"teamId": null,
"createdAt": "2023-11-08T10:30:15Z"
}
```
## Accessing Audit Logs
Audit logs are accessible through the promptfoo API. For complete API documentation, see the [API Reference](https://www.promptfoo.dev/docs/api-reference/#tag/audit-logs).
### API Endpoint
```
GET /api/v1/audit-logs
```
### Query Parameters
- `limit` (optional): Number of logs to return (1-100, default: 20)
- `offset` (optional): Number of logs to skip for pagination (default: 0)
- `createdAtGte` (optional): Filter logs created after this ISO timestamp
- `createdAtLte` (optional): Filter logs created before this ISO timestamp
- `action` (optional): Filter by specific action type
- `target` (optional): Filter by specific target type
- `actorId` (optional): Filter by specific user who performed the action
### Authentication
Audit log access requires:
- Valid authentication token
- Organization administrator privileges
### Example API Request
```bash
curl -X GET \
"https://your-promptfoo-domain.com/api/v1/audit-logs?limit=50&action=login" \
-H "Authorization: Bearer YOUR_API_TOKEN"
```
### Example API Response
```json
{
"total": 150,
"limit": 50,
"offset": 0,
"logs": [
{
"id": "550e8400-e29b-41d4-a716-446655440000",
"description": "john.doe@example.com logged in",
"actorId": "user-123",
"actorName": "John Doe",
"actorEmail": "john.doe@example.com",
"action": "login",
"actionDisplayName": "User Login",
"target": "USER",
"targetId": "user-123",
"metadata": null,
"organizationId": "org-456",
"teamId": null,
"createdAt": "2023-11-08T08:06:40Z"
}
// ... more log entries
]
}
```
## Compliance Usage
Audit logs in promptfoo can help meet various compliance requirements:
- **SOC 2**: Provides detailed access logs and administrative change tracking
- **ISO 27001**: Supports access control monitoring and change management requirements
- **Data protection reviews**: Helps track data access and user management activities
- **HIPAA**: Provides audit trails for access to systems containing protected health information
## Troubleshooting
If you experience issues accessing audit logs:
1. Verify you have organization administrator privileges
2. Check that your API token is valid and has not expired
3. Ensure your query parameters are properly formatted
For additional support, contact the promptfoo support team with details about your specific use case and any error messages received.
## See Also
- [Service Accounts](service-accounts.md) - Create API tokens for accessing audit logs
- [Teams](teams.md) - Learn about team management and permissions
- [Authentication](authentication.md) - Enterprise authentication and security features
- [API Reference](https://www.promptfoo.dev/docs/api-reference/#tag/audit-logs) - Complete audit logs API documentation
+72
View File
@@ -0,0 +1,72 @@
---
sidebar_label: Authentication
sidebar_position: 10
title: Authenticating into Promptfoo Enterprise
description: Configure enterprise authentication with SSO providers, API keys, service accounts, and CLI access for secure team collaboration
keywords: [authentication, login, logout, promptfoo enterprise, promptfoo app, sso, saml, oidc]
---
# Authentication
## Setting Up SSO
[Promptfoo Enterprise](/docs/enterprise/) supports both basic authentication and SSO through SAML 2.0 and OIDC. To configure SSO with Promptfoo Enterprise, reach out to the support team with your IdP information and the Promptfoo team will configure it. The authentication endpoint is `auth.promptfoo.app`.
## Basic Authentication
Promptfoo Enterprise supports basic authentication into the application through `auth.promptfoo.app`. When an organization is created, the global admin will receive an email from Promptfoo Enterprise to log in. Users, teams, and roles will be created in the Organization Settings of the Promptfoo Enterprise application, which is detailed further in the [Teams documentation](./teams.md).
You can also authenticate into the application using a magic link. To do this, navigate to `auth.promptfoo.app` and click the "Login with a magic link" button. You will receive an email with a link to log in. If you do not receive an email, please be sure to check your spam folder.
## Authenticating Into the CLI
You may wish to authenticate into the CLI when using Promptfoo Enterprise. Follow these steps to connect Promptfoo Enterprise to the CLI.
1. Install the Promptfoo CLI. Read [getting started](/docs/getting-started/) for help installing the CLI.
2. In the Promptfoo Enterprise app, select the "CLI Login Information" underneath your profile.
![CLI Login Information](/img/enterprise-docs/CLI-login-setting.png)
3. Copy the first command and run in your CLI. Your CLI will then be authenticated to Promptfoo Enterprise, allowing you to share eval results run locally.
![CLI Login Command](/img/enterprise-docs/CLI-login-key.png)
4. Once authenticated, you can run `promptfoo eval --share` or `promptfoo share` to share eval results to your Promptfoo Enterprise organization.
:::tip
All of your evals are stored locally until you share them. If you were previously an open-source user, you can share your local evals to your Promptfoo Enterprise organization by running `promptfoo share`.
:::
Authenticating with your organization's account enables [team-based sharing](/docs/usage/sharing#enterprise-sharing), ensuring your evaluation results are only visible to members of your organization rather than being publicly accessible.
## Working with Multiple Teams
If your organization has multiple teams, you can manage which team context you're operating in:
### Viewing Your Teams
```sh
# List all teams you have access to
promptfoo auth teams list
```
This shows all available teams with a marker (●) next to your current team.
### Switching Teams
```sh
# Switch to a different team
promptfoo auth teams set "Data Science"
```
You can use the team name, slug, or ID. Your selection persists across CLI sessions.
### Checking Current Team
```sh
# View your active team
promptfoo auth teams current
```
All operations (evaluations, red team scans, etc.) will use this team context until you switch to a different team.
+90
View File
@@ -0,0 +1,90 @@
---
sidebar_label: Findings and Reports
sidebar_position: 50
title: Findings and Reports in Promptfoo Enterprise
description: Analyze vulnerability findings with severity scoring, remediation tracking, and compliance reporting in Promptfoo Enterprise
keywords:
[findings, security reports, llm vulnerabilities, red team results, vulnerability management]
---
# Findings and Reports
[Promptfoo Enterprise](/docs/enterprise/) allows you to review findings and reports from scans within the Promptfoo Enterprise application.
## How Grading Works
Grading is the process of evaluating the success of a red team attack. Promptfoo grades results based on the application context that is provided when creating a target. These results are subsequently compiled in the dashboard, vulnerabilities view, reports, and evaluations sections.
## Reviewing the Dashboard
The dashboard is the main page for reviewing findings and reports in a centralized view. It displays a summary of all the scans that have been run, including the number of findings and reports generated.
![Promptfoo Cloud Dashboard](/img/enterprise-docs/promptfoo-dashboard.png)
## Viewing Vulnerabilities
The "Vulnerabilities" section displays a list of all the vulnerabilities that have been found. You can filter based on the target, severity level, status of finding, risk category, or type of vulnerability.
Selecting a vulnerability will open a finding that shows you the details of the vulnerability, including details about the types of strategies that were used to exploit the vulnerability, records of the probes that were used, the instances when the vulnerability was identified during scans, and remediation recommendations.
You can modify the status of the finding as either "Marked as Fixed", "False Positive", or "Ignore". You can also add comments to the finding to provide additional context about the vulnerability, as well as change the severity level of the vulnerability based on your company's risk assessment.
### Exporting Vulnerabilities
From the Vulnerabilities page, you can export findings in several formats:
- **Export as CSV**: Export vulnerability data as a CSV file with details about each finding, severity, and remediation recommendations.
- **Export as SARIF**: Export vulnerabilities in [SARIF format](https://sarifweb.azurewebsites.net/) (Static Analysis Results Interchange Format) for integration with security tools like GitHub Security, SonarQube, and other DevOps platforms. SARIF is an industry-standard format for representing static analysis results.
- **Export as Colang v1**: Export vulnerabilities as Colang 1.0 guardrails for integration with [NVIDIA NeMo Guardrails](https://github.com/NVIDIA/NeMo-Guardrails). This format allows you to implement defensive guardrails based on the vulnerabilities discovered during red team testing.
- **Export as Colang v2**: Export vulnerabilities as Colang 2.x guardrails, supporting the latest Colang format for NeMo Guardrails.
## Viewing Reports
Reports are point-in-time scans of your target that are generated when you run a scan. These reports can be used to review the findings from a specific scan.
![Vulnerability report view](/img/enterprise-docs/view-report.png)
Reports will tell you which strategies were the most successful in exploiting the target, as well as what the most critical vulnerabilities were. By selecting the "View Logs" button, you will be directed to the evals section where you can view the logs for the specific scan.
![View logs interface](/img/enterprise-docs/view-logs.png)
The evals section will display all the test cases that were run during the scan, as well as the results. You can filter the results based on whether the test passed or failed, whether there was an error, or the type of plugin. Selecting a specific test case will show you the adversarial probe that was used, the response from the target, and the reason for grading it.
![Example evaluation response](/img/enterprise-docs/eval-example.png)
You can modify the status of the finding as either a pass or failure, provide comments on the finding, view the vulnerability report associated with the eval result, and copy the eval result to your clipboard.
When reviewing an eval, there are also multiple ways that you can export the results, including:
- **Export to CSV**: Export the eval results as a CSV file.
- **Export to JSON**: Export the eval results as a JSON file.
- **Download Burp Suite Payloads**: Download the adversarial probes as payloads that can be imported into Burp Suite.
- **Download DPO JSON**: Download the eval results as a DPO JSON file.
- **Download Human Eval Test YAML**: Evaluate the eval results for performance in code-related tasks.
- **Download the failed test config**: Download a configuration file containing only the failed tests to focus on fixing just the tests that need attention.
![Export options demonstration](/img/enterprise-docs/export-results.gif)
## Filtering and Sorting Findings
The "Evals" section will display all of the evaluations and let you filter and sort through them based on the eval ID, date the scan was created, author, description, plugin, strategy, pass rate, or number of tests. You can then download the evals as a CSV file.
![Filtering evaluations interface](/img/enterprise-docs/filter-evals.png)
You can also search for findings [using Promptfoo's API](https://www.promptfoo.dev/docs/api-reference/#tag/default/GET/api/v1/results).
## Sharing Findings
There are several ways to share findings outside of the Promptfoo application:
- **Export Vulnerabilities**: Export vulnerability data as CSV, SARIF, or Colang format from the "Vulnerabilities" section. See [Exporting Vulnerabilities](#exporting-vulnerabilities) above for format details.
- **Export Eval Results**: Export eval results as CSV or JSON from the "Evals" section.
- **Download Vulnerability Reports**: Download point-in-time vulnerability reports for each scan in the "Reports" section. These reports are exported as a PDF.
- **Use the Promptfoo API**: Use the [Promptfoo API](https://www.promptfoo.dev/docs/api-reference/) to export findings, reports, and eval results.
- **Share via URL**: Generate shareable URLs for your evaluation results using the `promptfoo share` command. [Learn more about sharing options](/docs/usage/sharing.md).
## See Also
- [Running Red Teams](./red-teams.md)
- [Service Accounts](./service-accounts.md)
- [Authentication](./authentication.md)
+249
View File
@@ -0,0 +1,249 @@
---
sidebar_label: Guardrails
sidebar_position: 55
title: Adaptive Guardrails in Promptfoo Enterprise
description: Automatically turn red team vulnerabilities into context-aware filters that intercept adversarial prompts before they reach LLM endpoints
keywords: [guardrails, adaptive guardrails, llm security, prompt filtering, red team defense]
---
# Adaptive Guardrails
## What are Adaptive Guardrails?
Adaptive guardrails close the loop between red teaming and production defense by automatically turning identified vulnerabilities into context-aware filters that intercept adversarial prompts before they reach LLM endpoints.
## What Makes Them Adaptive?
Each guardrail is tied to a specific red teaming target, allowing us to leverage information about your AI application, like key features, target use case, and user personas, to strengthen defenses. As new vulnerabilities are discovered, guardrail policies automatically evolve, transforming red team failures into production-grade blocking rules and creating a living defense layer that grows stronger with each test cycle.
## How It Works
### Continuous Evolution
<div style={{ textAlign: 'center' }}>
<img src="/img/docs/guardrail-feedback-loop.jpg" alt="guardrails feedback loop" style={{ width: '70%' }} />
</div>
1. Red team tests generate attacks to test the AI application in risk areas configured via red team plugins and custom policies in Promptfoo
2. Vulnerabilities are discovered which are recorded for use in defenses
3. Guardrail policies are created or updated to ensure vulnerabilities are addressed
4. We block new attacks using the updated policies based on captured vulnerabilities
As you run more tests and discover new vulnerabilities, regenerating the guardrail automatically incorporates these findings while preserving your manual policy additions.
### Policy Management
- **Automated Policies**: Generated from red team test failures and updated on regeneration.
- **Manual Policies**: Added by you, never removed during regeneration.
You can add, edit, or remove policies at any time through the UI or API. Manual policies are persisted across regenerations, allowing you to maintain custom business logic while automated policies evolve based on new scan data.
## Getting Started
### Generate Guardrail
Navigate to the **Guardrails** page by clicking **Guardrails (Navbar) > Guardrails** in the top bar. Then, click on **Create New Guardrail** to begin the guardrail creation process. On this menu, you'll be able to choose between adaptive guardrails, along with third-party guardrails that do not adapt to your red team scans.
<div style={{ textAlign: 'center' }}>
<img src="/img/docs/guardrail-creation-form.jpg" alt="guardrail creation form" style={{ width: '55%' }} />
</div>
Select **Adaptive** to continue with adaptive guardrails. Then, you'll be asked to select your target from the list of targets that you have configured. Once you have created your guardrail, you should find yourself on the home page for your guardrail.
On the guardrail page, you'll be able to configure the filters and policies of your guardrail, as well as set severity thresholds that allow you to tune the strictness of your guardrail.
**Fast filters** is a great place to start, since this will be the first filter that is run on your prompts. Here you can set regular expressions that will check for sensitive text such as credit card numbers, addresses, and SSNs.
### Generating Policies
Policies is the next stop for the prompt. Each policy is a set of criteria that defines what content should be blocked, warned or allowed. These policies can be generated automatically from the vulnerabilities found in your red-team scans, or added manually using simple descriptions.
For adaptive guardrails, you'll want to generate the policies from your vulnerabilities, since this will directly take outputs from your scans that have successfully attacked your target, and shape your policy around them.
Once you generate your policies, you'll be able to test them directly on the generation page.
<div style={{ textAlign: 'center' }}>
<img src="/img/docs/guardrail-generation-page.jpg" alt="guardrail generation page" style={{ width: '75%' }} />
</div>
Once you are satisfied with your policy's abilities, save them, they'll be added to your guardrail. You can then navigate back to your guardrail's page and view all the fast filters and policies.
### Testing the Guardrail
This is the point where you may want to test out your guardrails. Take a close look at the score you get for your prompts.
<div style={{ textAlign: 'center' }}>
<img src="/img/docs/guardrail-test-page.jpg" alt="guardrail test page" style={{ width: '55%' }} />
</div>
As you can see, this prompt gets a severity of only 0.30 (on a 0.0-1.0 scale). This means that some level of hate speech is being detected, but it isn't enough for blocking the prompt or returning a warning.
If we want to configure our guardrails such that hate speech is more strictly prohibited, we can edit our action thresholds, and set them slightly lower. Try setting the **block** dial down to 0.7 and see if there are things that now get blocked that weren't earlier. The best way to find the right setting is to experiment with different prompts on the **Test Guardrail** menu.
### Integrate the Guardrail
To integrate the guardrail into your application, select **Guardrails > Targets**. Once you select the target that you've attached your adaptive guardrail to, you should see an integrate option right under the name of your target.
<div style={{ textAlign: 'center' }}>
<img src="/img/docs/guardrails-integrate.jpg" alt="guardrails integrate" style={{ width: '75%' }} />
</div>
Here, you'll find different ways of integrating your guardrail into your application. Initially, we suggest integrating it at the input and output steps of your application. At the bottom of this page you'll find the different placement options that you need to add to your requests. For your first integration, we suggest just setting up input and output calls, and integrating tool call input/output calls later.
```javascript
const response = await fetch('http://localhost:3200/api/v1/guardrails/YOUR_GUARDRAIL_ID/evaluate', {
method: 'POST',
headers: {
Authorization: `Bearer ${process.env.PROMPTFOO_API_KEY}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({
placement: 'INPUT', // this can also be OUTPUT, TOOL_CALL_INPUT, and TOOL_CALL_OUTPUT
messages: [{ role: 'user', content: 'Your user message here' }],
identityContext: { sub: 'user-123', metadata: { role: 'admin' } }, // optional
}),
});
const result = await response.json();
```
### Parallel Execution
The great thing about guardrails is that you can choose when you want to run them. If you want to ensure that no malicious input ever hits your target, you'd want to run your guardrail as a check before you ever send the request to your AI app. But if you want to minimize your Time to First Token (TTFT), you could run the query to your model, as well as the guardrail at the same time.
This approach prioritizes UX by ensuring non-malicious queries see zero added latency. However, it incurs the cost of the LLM call even for adversarial prompts that are ultimately blocked.
<div style={{ textAlign: 'center' }}>
<img src="/img/docs/guardrails-speed-comparison.jpg" alt="guardrails speed comparison" style={{ width: '75%' }} />
</div>
### Analytics
Once you've integrated this into your application, open **Guardrails > Dashboard**. On this page you'll be able to track all your targets on one dashboard. If you'd like to view a separate dashboard for each target, you can go back to the **Targets** page.
To review requests one-by-one, go over to **Guardrails > Requests**. You can sort through each request here. We suggest reviewing some requests in each range (e.g., block, warn, log) to ensure that they all are labeled as expected.
## Advanced Configuration
### Tool Calls
The next step to securing your application is expanding your guardrail to work on tool call inputs and outputs. Tool call guardrails aren't automatically generated from your red team scans, but they can manually be added to your list of policies.
To add a tool call guardrail, select **+ Add Manual** from your policies menu.
<div style={{ textAlign: 'center' }}>
<img src="/img/docs/guardrails-policies.jpg" alt="guardrails policies" style={{ width: '75%' }} />
</div>
This will allow you to manually configure a new policy where you can select **Tool Call Input** or **Tool Call Output** for the placement of your policy. Once you create policies with these placements, they will automatically be selected and invoked when you send a request to your guardrail with the placement set to `TOOL_CALL_INPUT`.
<div style={{ textAlign: 'center' }}>
<img src="/img/docs/guardrails-flow.jpg" alt="guardrails flow" style={{ width: '75%' }} />
</div>
Tool call guardrails allow you to validate structured arguments before they reach external functions. For example, applying a PII filter to `TOOL_CALL_INPUT` prevents sensitive user data from being exfiltrated to 3rd-party APIs or logged in external systems.
## Technical Specifications
### Input Example Limits
| Stage | Limit | Notes |
| -------------------------------------------------- | ----- | ---------------------------------------------------------- |
| Policy generation (max examples per vulnerability) | 500 | Raw input fed into the policy generation pipeline |
| Guardrail content generation (jailbreak examples) | 300 | Used to build guardrail context during creation |
| Testing a policy against examples | 50 | Max examples used when validating a policy's effectiveness |
| Issue attack examples (returned for display) | 20 | Shown in the UI for review |
| Guardrail test examples | 10 | Available in the test guardrail interface |
### LLM Prompt Limits
| Context | Examples | Notes |
| ------------------------------------------- | -------- | --------------------------------------------------------------- |
| Policy generation prompt | 5 | Sampled from vulnerability examples to guide policy creation |
| Judgement phase prompt | 5 | Used to evaluate candidate policies |
| Known violations in guardrail system prompt | 3 | Included as few-shot examples for pattern matching |
| Runtime validation | 0 | Only policy text is sent — no raw examples, keeping latency low |
### Scaling Behavior
| Metric | Value | Notes |
| ------------------------- | ------------ | ----------------------------------------------------------------- |
| Scaled pipeline threshold | >20 examples | Automatically switches to map-reduce processing |
| Batch size (map-reduce) | 25 | Examples are processed in batches, then policies are consolidated |
### Policies
| Constraint | Behavior | Notes |
| ------------------------------- | -------------------------- | ------------------------------------------------------ |
| Policies per guardrail | Unlimited | No schema cap on the number of policies |
| Policy consolidation | LLM-enforced deduplication | Redundant policies are merged automatically |
| Manual policies on regeneration | Preserved | Only automated policies are replaced when regenerating |
## Troubleshooting
### Guardrail not blocking expected patterns
If legitimate jailbreak attempts are passing through:
1. **Verify the pattern was discovered during red team testing.** Guardrails can only block patterns similar to known vulnerabilities.
2. **Add a manual example.** If the pattern is new, you can add examples directly through the API — manual examples override automated extraction from red team results.
3. **Regenerate the guardrail** after running additional red team tests to incorporate new findings.
4. **Check if the policy was consolidated.** During generation, semantically overlapping policies are merged. Review your policies to ensure the relevant rule wasn't folded into a broader one.
### High false positive rate
If the guardrail is blocking legitimate user inputs:
1. **Review automated policies for overly broad rules.** Open the policies list and look for rules that may be too general.
2. **Remove or refine problematic policies.** You can delete or edit individual policies through the UI or API.
3. **Adjust your action thresholds.** Raise the block and warn thresholds on the guardrail page to require higher severity scores before taking action.
### Policies not updating after new red team tests
If new vulnerabilities aren't reflected in your guardrail:
1. **Trigger regeneration with force.** Cached guardrails are returned by default — you must explicitly regenerate to incorporate new findings.
2. **Verify vulnerabilities are associated with the correct target.** Policies are generated from vulnerabilities linked to the guardrail's target ID, so confirm your red team results are tied to the right target.
3. **Check permissions.** Regeneration requires guardrail creation permissions. Verify your account has the appropriate access.
## FAQ
### Can I use adaptive guardrails without red team data?
Yes. You can create a guardrail with only manual policies and no red team scan results. However, the real power of adaptive guardrails comes from automatically generating policies from your red team findings. Manual-only guardrails are useful as a starting point or for custom business rules.
### How often should I regenerate policies?
Regenerate after each red team testing cycle that discovers new vulnerabilities. There is no required schedule — regeneration is triggered manually when you're ready to incorporate new findings. Manual policies are always preserved during regeneration.
### Can I export guardrail policies?
Yes. Policies are available via the API through the `GET /guardrails` endpoint in JSON format. You can use this to integrate policies into other security systems or documentation.
### Do guardrails replace red team testing?
No. Red team testing discovers vulnerabilities; guardrails protect against them. The two work together in a feedback loop — continue running red team scans to find new vulnerabilities, then regenerate guardrails to defend against them.
### Do adaptive guardrails only validate inputs?
No. Adaptive guardrails support four placement types: `INPUT`, `OUTPUT`, `TOOL_CALL_INPUT`, and `TOOL_CALL_OUTPUT`. By default, guardrails are applied to both `INPUT` and `OUTPUT`. You can configure tool call placements for additional coverage.
### Can I use multiple guardrails on the same target?
Yes. When multiple guardrails are active for a target, they are evaluated in parallel. A single guardrail can also be attached to multiple targets.
### How are fast filters and policies evaluated?
Fast filters (regex rules) run first as a pre-filter. If a fast filter triggers, the request is handled immediately without calling the LLM. If no fast filter matches, the request proceeds to LLM-based policy evaluation.
### Can I disable specific automated policies?
Yes. You can delete individual policies through the UI or API without triggering a full regeneration. The deleted policies will not reappear until you explicitly regenerate.
### How does the guardrail handle new attack types?
It blocks patterns similar to discovered vulnerabilities. Entirely new attack types require additional red team testing to be detected. This is why the feedback loop between testing and guardrail generation is important.
### Does Promptfoo support third-party guardrails?
Yes. In addition to adaptive guardrails, Promptfoo supports OpenAI Moderation, Microsoft Presidio, Azure AI Content Safety, and AWS Bedrock Guardrails. You can select the guardrail type during creation.
+79
View File
@@ -0,0 +1,79 @@
---
sidebar_label: Overview
title: Promptfoo Enterprise - Secure LLM Application Testing
description: 'Deploy Promptfoo Enterprise for scalable LLM security testing with cloud hosting, on-premises options, and team collaboration'
keywords:
[
promptfoo enterprise,
promptfoo enterprise on-prem,
llm security,
llm testing,
llm red teaming,
llm scanning,
]
---
# Promptfoo Enterprise
Promptfoo offers two deployment options to meet your security needs:
**Promptfoo Enterprise** is our hosted SaaS solution that lets you securely scan your LLM applications without managing infrastructure.
**Promptfoo Enterprise On-Prem** is our on-premises solution that includes a dedicated runner for deployments behind your firewall.
Both solutions offer a suite of tools to help you secure your LLM applications, including:
- Robust RBAC controls to manage multiple users and teams
- Teams-based configurability for customizing targets, plugins, and scan configurations
- Detailed reporting and analytics to monitor the security of your LLM applications
- Remediation suggestions to help you fix vulnerabilities
- Advanced filtering to find and sort through evals
- Sharing and exporting functions to integrate Promptfoo with your existing tools
Our platform works with any LLM application, agent, or foundation model that is live and ready for inference.
![Promptfoo Dashboard (Enterprise interface shown)](/img/enterprise-docs/promptfoo-dashboard.png)
## Deployment Options
We offer two deployment models:
- **Promptfoo Enterprise**: Our fully-managed SaaS solution maintained by Promptfoo, allowing you to get started immediately with no infrastructure requirements.
- **Promptfoo Enterprise On-Prem**: Our self-hosted solution that can be deployed on any cloud provider, including AWS, Azure, and GCP. Includes a dedicated runner component for executing scans within your network perimeter.
![Basic red team architecture](/img/docs/red-team-basic-architecture.png)
## Product Comparison
| Feature | Community | Promptfoo Enterprise | Promptfoo Enterprise On-Prem |
| --------------------------------------------------- | ------------------------------- | -------------------------------------------- | -------------------------------------------- |
| Deployment | Command line tool | Fully-managed SaaS | Self-hosted, on-premises |
| Infrastructure | Local | Managed by Promptfoo | Managed by your team |
| Dedicated Runner | ❌ | ❌ | ✅ |
| Network Isolation | ❌ | ❌ | ✅ |
| Model & Application Evals | ✅ | ✅ | ✅ |
| Vulnerability Detection | ✅ | ✅ | ✅ |
| Red Teaming | <span title="Limited">⚠️</span> | ✅ | ✅ |
| Remediations | <span title="Limited">⚠️</span> | ✅ | ✅ |
| Result Sharing | <span title="Limited">⚠️</span> | ✅ | ✅ |
| API Access | <span title="Limited">⚠️</span> | [](/docs/api-reference) | [](/docs/api-reference) |
| Team Management | ❌ | ✅ | ✅ |
| RBAC | ❌ | ✅ | ✅ |
| External Integrations (SIEMs, Issue trackers, etc.) | ❌ | ✅ | ✅ |
| SLA | ❌ | ✅ | ✅ |
| Support | Community Chat + Github Issues | Full Professional Services + Dedicated Slack | Full Professional Services + Dedicated Slack |
<p>
<small>⚠️ indicates limited quantity in Community version. [Contact us](/contact/) for more information.</small>
</p>
Both Enterprise products support [sharing results](/docs/usage/sharing) through shareable URLs, with privacy controls that match your deployment model. Enterprise users can share within their organization, while Enterprise On-Prem users can configure self-hosted sharing for complete control over data.
## Connection with Open-Source
Both Promptfoo Enterprise and Promptfoo Enterprise On-Prem are fully compatible with the open-source version of Promptfoo. This means that you can use your existing open-source Promptfoo results with either solution.
## Learn more
If you are interested in learning more about Promptfoo Enterprise, please [contact us](/contact/).
+84
View File
@@ -0,0 +1,84 @@
---
sidebar_label: Running Red Teams
sidebar_position: 40
title: Running Red Teams in Promptfoo Enterprise
description: Configure enterprise-grade red team assessments with custom plugins, scheduling, and compliance reporting for production LLMs
keywords:
[red teams, red teaming, llm security testing, adversarial attacks, llm vulnerability scanning]
---
# Running Red Teams
[Promptfoo Enterprise](/docs/enterprise/) allows you to configure targets, plugin collections, and scan configurations that can be shared among your team.
## Connecting to Promptfoo
Promptfoo requires access to [\*.promptfoo.app](https://promptfoo.app) to function.
If you are using a proxy or VPN, you may need to add these domains to your whitelist before you can generate red teams.
## Creating Targets
Targets are the LLM entities that are being tested. They can be a web application, agent, foundation model, or any other LLM entity. When you create a target, this target can be accessed by other users in your team to run scans.
You can create a target by navigating to the "Targets" tab and clicking "Create Target".
The "General Settings" section is where you identify the type of target you are testing and provide the technical details to connect to the target, pass probes, and parse responses.
The "Context" section is where you provide any additional information about the target that will help Promptfoo generate adversarial probes. This is where you provide context about the target's primary objective and any rules it should follow, as well as what type of user the red team should impersonate.
The more information you provide, the better the red team attacks and grading will be.
### Accessing External Systems
If your target has RAG orchestration or is an agent, you can select the "Accessing External Systems" option to provide additional details about the target's connection to external systems. Providing additional context about the target's access to external systems will help Promptfoo generate more accurate red team attacks and grading.
If your target is an agent, you can provide additional context about the agent's access to tools and functions in the question "What external systems are connected to this application?" This will help Promptfoo ascertain whether it was able to successfully enumerate tools and functions when running the [tool discovery plugin](/docs/red-team/plugins/tool-discovery/).
## Creating Plugin Collections
You can create plugin collections to share among your team. These plugin collections allow you to create specific presets to run tests against your targets, including establishing custom policies and prompts.
To create a plugin collection, navigate to the "Plugin Collections" tab under the "Red team" navigation header and click "Create Plugin Collection".
![Creating a new plugin collection](/img/enterprise-docs/create-plugin-collection.gif)
## Configuring Scans
When you want to run a new red team scan, navigate to the "Red team" navigation header and click on "Scan Configurations". You will see a list of all the scan configurations that your team has created. Click on "New Scan" to create a new scan.
![Create Scan Configuration interface](/img/enterprise-docs/create-scan.png)
If you have already created a scan configuration from the open-source version of Promptfoo or local usage, you can import the YAML file to use it in Promptfoo Enterprise.
Click on "Create Scan" to configure a new scan. You will then be prompted to select a target. Alternatively, you can create a new target.
![Select Target screen](/img/enterprise-docs/select-target.png)
Once you have selected a target, you will be prompted to select a plugin collection. If you do not have a plugin collection, you can create a new one.
![Select Plugin Collection screen](/img/enterprise-docs/choose-plugins.png)
Once you have selected a plugin collection, you will be prompted to select the strategies. [Promptfoo strategies](/docs/red-team/strategies/) are the ways in which adversarial probes are delivered to maximize attack success rates.
![Select Strategies screen](/img/enterprise-docs/select-strategies.png)
## Running a Scan
Once you have configured a scan by selecting a target, plugin collection, and strategies, you can generate a red team scan by navigating to the "Review" section. Click on "Save Configuration" for Promptfoo to generate a CLI command. You will need to [authenticate](./authentication.md) into the CLI to run the scan and share the results.
![Run Scan configuration screen](/img/enterprise-docs/run-scan.png)
Alternatively, you can download the Promptfoo YAML file and run the scan locally.
When you enter the command into your terminal, Promptfoo will generate the adversarial probes and write the test cases locally.
![Running scan in CLI](/img/enterprise-docs/run-scan-cli.png)
Once generated, Promptfoo will execute the test cases against your target and upload the results to Promptfoo Enterprise. You can review the results by clicking on the evaluation link that is generated in the terminal or by navigating to Promptfoo Enterprise.
## See Also
- [Findings and Reports](./findings.md)
- [Authentication](./authentication.md)
- [Service Accounts](./service-accounts.md)
+202
View File
@@ -0,0 +1,202 @@
---
sidebar_label: Remediation Reports
sidebar_position: 55
title: Remediation Reports in Promptfoo Enterprise
description: AI-generated remediation reports with prioritized action items, implementation guidance, and vulnerability-to-fix mappings for LLM security issues
keywords:
[
remediation reports,
security fixes,
vulnerability remediation,
llm security,
action items,
implementation guide,
]
---
# Remediation Reports
[Promptfoo Enterprise](/docs/enterprise/) automatically generates remediation reports after each red team scan. These reports provide actionable security recommendations with implementation guidance.
## Overview
Remediation reports analyze your scan results and provide:
- **Executive Summary**: High-level assessment of your security posture with top concerns
- **Vulnerability-to-Remediation Mapping**: Quick reference showing which fixes address which vulnerabilities
- **Prioritized Action Items**: Step-by-step implementation guidance ordered by impact and effort
- **Code Examples**: Ready-to-use code snippets and configuration changes
- **Attack Context**: Real examples from your scan showing how vulnerabilities were exploited
## Accessing Remediation Reports
Remediation reports are automatically generated when:
1. A red team scan completes in the Promptfoo Enterprise UI
2. A CLI scan is uploaded to the server using `promptfoo share`
To access a remediation report:
1. Navigate to the **Reports** section in Promptfoo Enterprise
2. Select the evaluation you want to review
3. Click on the **Remediation** tab to view the remediation report
![Remediation Report view](/img/enterprise-docs/remediation-report-top.png)
Alternatively, you can access remediation reports directly from the vulnerabilities view by clicking on a specific finding.
## Report Structure
### Executive Summary
The executive summary provides a high-level overview of your security posture, including:
- **Overall Risk Level**: Critical, High, Medium, or Low classification
- **Top Concerns**: The most significant security issues identified in your scan
- **Security Posture**: Narrative summary of your application's current security state
This section helps stakeholders quickly understand the severity of issues without diving into technical details.
### Vulnerability-to-Remediation Mapping
A quick-reference table showing:
- Vulnerability category and plugin ID
- Number of failed test cases
- Risk score and severity level
- Which remediation actions address each vulnerability
This mapping helps you understand the relationship between vulnerabilities and fixes, making it easier to prioritize work that addresses multiple issues.
### Prioritized Action Items
Each action item includes:
- **Priority Number**: Actions are ranked by impact and feasibility
- **Action Type**: Category of fix (e.g., System Prompt Hardening, Input Validation, Output Filtering)
- **Title and Description**: Clear explanation of what needs to be changed
- **Impact Level**: Expected security improvement (High, Medium, Low)
- **Effort Level**: Implementation difficulty (High, Medium, Low)
- **Implementation Details**: Step-by-step instructions with code examples
- **Estimated Timeframe**: How long implementation should take
- **Vulnerabilities Addressed**: Which security issues this action will fix
![Prioritized Action Item with Implementation Details](/img/enterprise-docs/remediation-report-recommendation.png)
#### Action Types
Common remediation action types include:
- **System Prompt Hardening**: Strengthening your system prompts with better guardrails
- **Input Validation**: Adding validation to user inputs before processing
- **Output Filtering**: Implementing filters to sanitize model responses
- **Configuration Changes**: Adjusting model parameters or API settings
- **Architecture Changes**: Modifying your application's structure for better security
### Attack Examples
For each vulnerability addressed by a remediation action, the report shows:
- The actual adversarial probes that succeeded during your scan
- The model's vulnerable responses
- Why the test was marked as a failure
This context helps you understand the real-world exploitation of each vulnerability and verify your fixes are effective.
## Using Report Features
### Regenerating Reports
If your scan data has changed or you want fresh recommendations:
1. Click the **Regenerate** button in the report header
2. The report status will change to "Generating"
3. The page will automatically poll and update when generation completes
Report generation typically takes 1-3 minutes depending on the size of your scan.
### Downloading Reports
To share reports with your team or stakeholders:
1. Click the **Download PDF** button in the report header
2. The report will be formatted for printing and opened in a print dialog
3. Save as PDF or print directly
The PDF format is optimized for sharing with technical and non-technical audiences.
### System Prompt Hardening
For system prompt vulnerabilities, use the **Harden Prompt** feature:
1. Click the **Harden Prompt** button in the report header
2. Review the AI-generated hardened prompt that addresses identified vulnerabilities
3. Test the hardened prompt against your scan results
4. Copy and implement the improved prompt in your application
![System Prompt Hardening Dialog](/img/enterprise-docs/remediation-report-harden.png)
This feature provides immediate, actionable improvements to your system prompts based on the specific vulnerabilities found in your scan.
## Report Statuses
Remediation reports can be in different states:
- **Pending**: Report generation has been queued but not started
- **Generating**: The AI is currently analyzing your scan and creating recommendations
- **Completed**: Report is ready to view
- **Failed**: Generation encountered an error (use Regenerate to retry)
The report page automatically polls for updates while a report is generating, so you don't need to refresh manually.
## Outdated Reports
If you run a new scan after a remediation report has been generated, the report will be marked as **Outdated**. An alert will appear prompting you to regenerate the report to include the most recent results.
Regenerating ensures your remediation recommendations reflect your current security posture.
## Best Practices
### Implementation Workflow
1. **Review Executive Summary**: Understand overall risk and top concerns
2. **Check Vulnerability Mapping**: Identify which fixes provide the most coverage
3. **Start with High Impact, Low Effort**: Address quick wins first
4. **Implement Changes Incrementally**: Fix one action item at a time
5. **Re-scan After Each Fix**: Verify your remediation was effective
6. **Track Progress**: Use the vulnerabilities page to mark findings as fixed
### Prioritization Strategy
Consider both impact and effort when prioritizing:
- **High Impact, Low Effort**: Implement these first for immediate security gains
- **High Impact, High Effort**: Plan these as longer-term initiatives
- **Low Impact, Low Effort**: Good candidates when you have spare capacity
- **Low Impact, High Effort**: Deprioritize unless required for compliance
### Verification
After implementing remediation actions:
1. Run a new scan with the same configuration
2. Compare the new report to the previous one
3. Verify that addressed vulnerabilities no longer appear
4. Check if the overall risk level has improved
5. Generate a new remediation report to identify remaining issues
## Integration with Findings Workflow
Remediation reports complement the vulnerabilities workflow:
- **Vulnerabilities Page**: Track individual findings across scans
- **Remediation Reports**: Get implementation guidance for fixes
- **Reports Page**: Review point-in-time scan results
Use remediation reports to understand _how_ to fix issues, then track your progress in the vulnerabilities page.
## See Also
- [Findings and Reports](./findings.md)
- [Running Red Teams](./red-teams.md)
- [API Reference](https://www.promptfoo.dev/docs/api-reference/)
+42
View File
@@ -0,0 +1,42 @@
---
sidebar_label: Service Accounts
sidebar_position: 30
title: Creating and Managing Service Accounts in Promptfoo Enterprise
description: Manage service accounts and API keys for automated CI/CD integration and programmatic access to Promptfoo Enterprise features
keywords: [service accounts, api keys, programmatic access, ci/cd integration, automation]
---
# Service Accounts
Service accounts allow you to create API keys for programmatic access to [Promptfoo Enterprise](/docs/enterprise/). These are useful for CI/CD pipelines and automated testing.
:::note
Only global system admins can create and assign service accounts.
:::
To create a service account:
1. Navigate to your Organization Settings page
2. Click on the "Users" tab and then select "Create Service Account"
<div style={{ textAlign: 'center' }}>
<img src="/img/enterprise-docs/create-service-account.png" alt="Create Service Account screen" style={{ width: '80%' }} />
</div>
3. Enter a name for your service account and save the API key in a secure location.
<div style={{ textAlign: 'center' }}>
<img src="/img/enterprise-docs/service-account-api-key.png" alt="Service Account API key" style={{ width: '80%' }} />
</div>
:::warning
Make sure to copy your API key when it's first created. For security reasons, you won't be able to view it again after closing the dialog.
:::
4. Determine if you want to assign the API key with global admin privileges. This will provision the API key with access to everything that can be done in the organization settings page, such as managing teams, roles, users, and webhooks.
5. Assign the API key to a team by navigating to the "Teams" tab and selecting the team you want to assign the API key to in the "Service Accounts" section. Service account API keys will not have programmatic access to Promptfoo Enterprise unless assigned to a team and role.
<div style={{ textAlign: 'center' }}>
<img src="/img/enterprise-docs/assign-service-account.png" alt="Assign Service Account to team" style={{ width: '80%' }} />
</div>
6. Select the predefined role for the service account for that team.
## See Also
- [Managing Roles and Teams](./teams.md)
- [Authentication](./authentication.md)
+84
View File
@@ -0,0 +1,84 @@
---
sidebar_label: Managing Roles and Teams
sidebar_position: 20
title: Managing Roles and Teams in Promptfoo Enterprise
description: Implement team collaboration with role-based access control, project permissions, and audit logging in Promptfoo Enterprise
keywords: [roles, teams, permissions, users, organizations, rbac, access control]
---
# Managing Roles and Teams
[Promptfoo Enterprise](/docs/enterprise/) supports a flexible role-based access control (RBAC) system that allows you to manage user access to your organization's resources.
## Creating Teams
Promptfoo Enterprise supports multiple teams within an organization. To create a team, navigate to the "Teams" tab in the sidebar and click the "New Team" button.
![New Team](/img/enterprise-docs/create-team.png)
You can add users to a team by editing the team and clicking the "Add team members" button. This will also allow you to set the role of the user in the team.
![Add Team Members](/img/enterprise-docs/add-team-members.png)
You can also create service accounts at the team level, which will allow you to create API keys for programmatic access to Promptfoo Enterprise. These are useful for CI/CD pipelines and automated testing.
:::note
Only system admins can create service accounts.
:::
## CLI Team Context
When using the Promptfoo CLI with multiple teams, you can control which team context your operations use:
### Setting Your Active Team
After logging in, set your active team using:
```sh
promptfoo auth teams set "Your Team Name"
```
All subsequent CLI operations (evaluations, sharing results, etc.) will use this team context.
### Verifying Team Context
Before running important operations, verify your active team:
```sh
promptfoo auth whoami
```
This displays your current organization and team.
### Team Isolation
- **API keys are organization-scoped**: Your API key determines which organization you're logged into
- **Team selections are isolated per organization**: If you have access to multiple organizations, each organization remembers its own team selection independently
- **Resources are team-scoped**: Evaluations, configurations, and results are associated with your active team
:::tip
Always verify your team context with `promptfoo auth whoami` before sharing evaluation results or running scans to ensure they go to the correct team.
:::
## Creating Roles
Promptfoo allows you to create custom roles to manage user access to your organization's resources. To create a role, navigate to the "Roles" tab in the sidebar and click the "New Role" button.
![New Role](/img/enterprise-docs/create-new-role.png)
### Permissions
Promptfoo Enterprise supports the following permissions:
- **Administrator**: Full access to everything in the team
- **View Configurations**: View configurations, targets, and plugin collections
- **Run Scans**: Run scans and view results
- **Manage Configurations**: Create, edit, and delete configurations and plugin collections
- **Manage Targets**: Create, edit, and delete targets
- **View Results**: View issues and evaluations
- **Manage Results**: Edit and delete evaluations and issues
## See Also
- [Authentication](./authentication.md)
- [Service Accounts](./service-accounts.md)
+162
View File
@@ -0,0 +1,162 @@
---
sidebar_label: Webhook Integration
description: Integrate real-time issue notifications with external systems using Promptfoo's webhook API. Configure event types, manage endpoints, and verify signatures securely.
---
# Webhook Integration
[Promptfoo Enterprise](/docs/enterprise/) provides webhooks to notify external systems when security vulnerabilities (issues) are created or updated.
## What is an Issue?
An "issue" in Promptfoo Enterprise refers to a **security vulnerability** or weakness detected during AI security testing. Issues are created when red team plugins identify potential security risks such as prompt injections, data leaks, harmful content generation, or other AI-specific vulnerabilities.
## Event Types
The following webhook event types are available:
- `issue.created`: Triggered when a new security vulnerability is detected and created
- `issue.updated`: Triggered when a vulnerability is updated (such as when multiple attributes change at once)
- `issue.status_changed`: Triggered when a vulnerability's status changes (e.g., from open to fixed)
- `issue.severity_changed`: Triggered when a vulnerability's severity level changes
- `issue.comment_added`: Triggered when a comment is added to a vulnerability
> Note: When multiple properties of a vulnerability are updated simultaneously (for example, both status and severity), a single issue.updated event will be sent rather than separate issue.status_changed and issue.severity_changed events. This helps prevent webhook consumers from receiving multiple notifications for what is logically a single update operation.
## Managing Webhooks
Webhooks can be managed via the API. Each webhook is associated with an organization and can be configured to listen for specific event types.
### Creating a Webhook
```
POST /api/webhooks
Content-Type: application/json
Authorization: Bearer YOUR_API_TOKEN
{
"url": "<https://your-webhook-endpoint.com/callback>",
"name": "My SIEM Integration",
"events": ["issue.created", "issue.status_changed"],
"teamId": "optional-team-id",
"enabled": true
}
```
Upon creation, a secret is generated for the webhook. This secret is used to sign webhook payloads and should be stored securely.
### Webhook Payload Structure
Webhook payloads are sent as JSON and have the following structure:
```json
{
"event": "issue.created",
"timestamp": "2025-03-14T12:34:56Z",
"data": {
"issue": {
"id": "issue-uuid",
"pluginId": "plugin-id",
"status": "open",
"severity": "high",
"organizationId": "org-id",
"targetId": "target-id",
"providerId": "provider-id",
"createdAt": "2025-03-14T12:30:00Z",
"updatedAt": "2025-03-14T12:30:00Z",
"weakness": "display-name-of-plugin",
"history": [...]
},
"eventData": {
// Additional data specific to the event type
}
}
}
```
For `issue.updated` events, the `eventData` field includes information about what changed:
```json
{
"event": "issue.updated",
"timestamp": "2025-03-14T14:22:33Z",
"data": {
"issue": {
// Complete issue data with the current state
},
"eventData": {
"changes": ["status changed to fixed", "severity changed to low"]
},
"userId": "user-123" // If the update was performed by a user
}
}
```
This structure allows you to:
1. See the complete current state of the issue
2. Understand what specific attributes changed
3. Track who made the change (if applicable)
## Verifying Webhook Signatures
To verify that a webhook is coming from Promptfoo Enterprise, the payload is signed using HMAC SHA-256. The signature is included in the `X-Promptfoo-Signature` header.
Here's an example of how to verify signatures in Node.js:
```jsx
const crypto = require('crypto');
function verifyWebhookSignature(payload, signature, secret) {
const expectedSignature = crypto
.createHmac('sha256', secret)
.update(JSON.stringify(payload))
.digest('hex');
return crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expectedSignature));
}
// In your webhook handler:
app.post('/webhook-endpoint', (req, res) => {
const payload = req.body;
const signature = req.headers['x-promptfoo-signature'];
const webhookSecret = 'your-webhook-secret';
if (!verifyWebhookSignature(payload, signature, webhookSecret)) {
return res.status(401).send('Invalid signature');
}
// Process the webhook
console.log(`Received ${payload.event} event`);
res.status(200).send('Webhook received');
});
```
## Example Integration Scenarios
### SIEM Integration
When integrating with a SIEM system, you might want to listen for `issue.created` and `issue.updated` events. This allows your security team to be notified of new security vulnerabilities detected by Promptfoo Enterprise and track their resolution. The complete vulnerability state provided with each webhook makes it easy to keep your SIEM system synchronized.
### Task Tracking Integration
For task tracking systems like JIRA, you can:
- Listen for `issue.created` to create new tickets for vulnerabilities
- Listen for `issue.updated` to update tickets when any vulnerability properties change
- Listen for `issue.status_changed` if you only care about vulnerability status transitions
- Listen for `issue.comment_added` to sync comments between systems
The `changes` array included with `issue.updated` events makes it easy to add appropriate comments to your task tracking system (e.g., "Vulnerability status changed from open to fixed").
### Custom Notification System
You could build a custom notification system that:
1. Creates different notification channels based on event types
2. Routes notifications to different teams based on severity levels
3. Uses the `changes` information in `issue.updated` events to craft appropriately detailed messages
4. Filters out specific types of changes that aren't relevant to particular teams