Skip to main content
Catching a prompt injection vulnerability or a jailbreak path in production is expensive — it means a live agent is already exposed. Integrating Trident’s red-team evaluations into your CI/CD pipeline moves that detection to the point where it’s cheapest to fix: before the code ships. Every pull request that touches agent logic runs your configured attack scenarios, and a failing eval blocks the deploy just like a failing unit test.

Install tridentctl

Install the Trident CLI in your CI environment before running evaluations:
npm install -g @trident/cli
If you prefer not to install globally, you can invoke it directly with npx:
npx tridentctl evals --config trident-evals.yaml

Set your project credentials

Trident authenticates eval runs using your project API keys. Add the following as secrets or environment variables in your CI system:
VariableValue
TRIDENT_PROJECT_PUBLIC_KEYYour project’s Public Key (find it at Settings → API Keys)
TRIDENT_PROJECT_SECRET_KEYYour project’s Secret Key — treat this as a password
Never hard-code these values in your repository. Use your CI system’s secrets manager to inject them at runtime.

Run evaluations

1

Create an eval configuration file

Write a YAML file (for example, trident-evals.yaml) using the promptfoo configuration format. Define the prompts, attack scenarios, and assertions you want to run. Start with high-priority attacks like prompt injection and jailbreak attempts.
2

Run the eval command

Execute the following command in your CI pipeline:
tridentctl evals --config trident-evals.yaml
Trident runs each scenario in the eval corpus against your agent and evaluates the responses using the assertions defined in your config file.
3

Interpret the exit code

The tridentctl evals command exits with a non-zero status code if any test assertion fails. Most CI systems treat a non-zero exit as a pipeline failure, which blocks the pull request or deployment automatically — no additional configuration required.
4

Use --watch for local development (optional)

During local development, pass the --watch flag to have tridentctl automatically re-run evaluations whenever your config file or prompt files change:
tridentctl evals --config trident-evals.yaml --watch

GitHub Actions example

Add the following workflow file to your repository to run Trident evals on every pull request:
.github/workflows/trident.yml
name: Trident Security Gate
on: [pull_request]

jobs:
  trident:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Trident CLI
        run: npm install -g @trident/cli

      - name: Run security evaluations
        run: tridentctl evals --config trident-evals.yaml
        env:
          TRIDENT_PROJECT_PUBLIC_KEY: ${{ secrets.TRIDENT_PROJECT_PUBLIC_KEY }}
          TRIDENT_PROJECT_SECRET_KEY: ${{ secrets.TRIDENT_PROJECT_SECRET_KEY }}
The workflow runs on every pull request. If any eval fails, the check fails and the PR cannot be merged (assuming branch protection is enabled on your default branch).

Trigger evaluations via API

If you want to trigger a full cloud-run campaign rather than running evals locally in the CI runner, you can call the Trident REST API instead: Start a campaign:
POST /api/public/trident/redteam/campaign
Authorization: Basic <base64(publicKey:secretKey)>
Content-Type: application/json

{
  "agentId": "your-agent-id",
  "configRef": "trident-evals.yaml"
}
Poll for completion:
GET /api/public/trident/redteam/campaign/{jobId}
Authorization: Basic <base64(publicKey:secretKey)>
Poll until the response status field is completed or failed, then use the passed boolean to determine whether to proceed with the deploy.
Start your CI gate with a small, focused set of high-priority attacks — prompt injection, jailbreak, and any domain-specific risks your agent faces. Once those pass consistently, expand the corpus incrementally. A gate that runs in under two minutes is far more likely to stay in place than one that takes ten.