Skip to main content

CI/CD Security Gate

The CI/CD security gate moves Beak AI Security left, into the build. Where Red Teaming tells you an agent is unsafe and the Threat Dashboard tells you a request was blocked in production, the gate stops an unsafe agent from reaching production at all. A pipeline posts what it knows about the build, and the gate answers with a pass or fail and the findings behind it.

Unlike every other Beak AI Security capability, the gate has no screen of its own — it is an API called from a build pipeline.

Endpoint​

POST /aisecurity/cicd/evaluate

The request is authenticated exactly like the rest of the AI Security API, with a bearer token for the tenant. It is not permission-gated: a pipeline has no interactive Beak user to attach a role to, so the gate is classed as a machine endpoint and no authz permission is checked.

The response status is the gate result, which is what makes it usable directly as a build step:

  • 200 — The gate passed.
  • 422 — The gate failed. A pipeline that fails the build on a non-2xx response needs no result parsing at all.

Checks​

Four checks are available. Each one runs only if its key is present in the request body, so a pipeline can adopt the gate incrementally and add checks as the surrounding evidence becomes available.

Hardcoded Secrets in Prompt Templates​

  • Key — prompt_templates (list of strings)
  • Severity — critical

Scans every supplied prompt template for credentials that have been pasted into a prompt. Seven patterns are recognised: generic API-key assignments, generic secret, password or token assignments, OpenAI-style sk- keys, bearer tokens, PEM private key blocks, GitHub personal access tokens (ghp_), and AWS access key IDs (AKIA).

Any match fails the gate. The finding names the index of the offending template and how many matches it contained, so the pipeline log points at the exact prompt without reprinting the secret.

Red Team Pass Rate​

  • Keys — redteam_pass_rate (0–1), and optionally redteam_min_pass_rate (default 0.8)
  • Severity — high on failure

Compares the pass rate from the most recent red team campaign against the minimum the build requires. Supplying redteam_pass_rate without redteam_min_pass_rate enforces the 0.8 default.

AIBOM Validity​

  • Key — aibom_valid (boolean)
  • Severity — medium on failure

Fails the gate when the AIBOM is missing or out of date, so a deployment cannot ship with an inventory that no longer describes what is being deployed.

Container CVEs​

  • Keys — container_cves (list of CVE IDs), and optionally max_critical_cves (default 0)
  • Severity — critical on failure

Fails when the number of CVEs found in the container image exceeds the allowance. The default allowance of 0 means any CVE fails the gate. The finding echoes the CVE list back so the build log records exactly what was found.

Request​

{
  "prompt_templates": ["You are a support agent. Use api_key=..."],
  "redteam_pass_rate": 0.92,
  "redteam_min_pass_rate": 0.85,
  "aibom_valid": true,
  "container_cves": ["CVE-2025-1234"],
  "max_critical_cves": 0
}

Response​

The result is returned in the standard Beak API envelope, with the gate outcome in data:

{
  "status": "success",
  "message": "Gate evaluation complete",
  "data": {
    "gate_passed": false,
    "checks_run": 4,
    "checks_passed": 3,
    "checks_failed": 1,
    "findings": [
      {
        "check": "container_cves",
        "severity": "critical",
        "passed": false,
        "description": "1 CVE(s) found in container (max allowed: 0)",
        "cves": ["CVE-2025-1234"]
      }
    ]
  }
}
  • gate_passed — false if any check failed. Mirrors the HTTP status.
  • checks_run, checks_passed, checks_failed — Counts over the findings actually produced. checks_run counts only the checks whose keys were supplied.
  • findings — One entry per check that ran, each carrying check, severity, passed, and a human-readable description, plus check-specific detail.

Note: Passing checks are also reported, at severity info. The findings list is the full record of what was evaluated, not just what went wrong.

What a Skipped Check Looks Like​

A check that is not supplied is skipped silently — it produces no finding and does not fail the gate. Two cases are easy to misread as a pass:

  • Omitting a key entirely. A body with only aibom_valid runs one check, and checks_run reports 1.
  • Supplying an empty prompt_templates or container_cves list. An empty list skips the check rather than passing it, so a scanner that produced no output and a scanner that failed to run are indistinguishable to the gate.

Compare checks_run against the number of checks the pipeline intended to submit. A gate that passed because nothing was checked is the failure mode worth guarding against.

Best Practices​

  • Fail the build on the HTTP status — Treat any non-200 as a stop. It needs no result parsing and cannot be defeated by a change to the response body.
  • Assert on checks_run — A green gate means nothing if the evidence never arrived. Verify the count matches what the pipeline meant to send.
  • Feed the gate real scanner output — Wire container_cves to the image scan and redteam_pass_rate to the most recent campaign rather than to hardcoded values, or the gate only ever confirms its own defaults.
  • Set max_critical_cves to 0 and keep it there — The allowance exists for staged adoption on an existing estate; raising it permanently converts the check into a formality.
  • Run the gate before publishing the image, not after — The gate is only a control if a failure prevents the artifact from becoming available to deploy.
  • Red Teaming — Produces the campaign pass rate the gate enforces.
  • AIBOM — The inventory whose validity the gate checks.
  • Atlas Browser — Maps findings to adversarial techniques for pre-deployment review.
  • Threat Dashboard — Runtime protection for what does reach production.
  • Overview — High-level product overview for Beak AI Security.