Set up the airgapped triage agent

Connect your forked VDP triage repo to Kit through a guided stepper — fork the example repo, wire the pipeline trigger, and verify with a real round-trip.

Why It Matters

Code-Aware AI Triage runs an AI security agent in your CI on every incoming report. This page walks you through connecting your fork of the example repo to Kit. The setup is a guided, Vanta-style stepper in your CSiRT settings — it doesn’t mark a step done until it’s verified, and the final step only turns green when a real triage round-trip completes.

You’ll need a self-managed GitLab Runner (gitlab.com SaaS shared runners can’t be host-network-isolated, which the airgap requires — see How the airgap works).

What You Need

A Kit account with the VDP Add-on enabled and an active CSiRT program
A GitLab account that can fork a repo and create a self-managed runner
A model endpoint your runner can reach through the egress proxy — DeepSeek by default (https://api.deepseek.com/anthropic), or any Anthropic-compatible endpoint
Your GitLab project’s pipeline trigger token (you’ll create this in step 2)

The Stepper

Navigate to VDP > Settings > Code-Aware Triage. Forking the example repo is a one-time prerequisite; after that the stepper has two live steps — connect the pipeline, then test it — and each verified step locks in before the next opens.

Fork the Example Repo

Fork the reference implementation:

https://gitlab.com/startupkit/vdp-ai-triage-example

The stepper gives you a Fork on GitLab button that opens the repo. Fork it into a GitLab project you own and control — you own the model, prompts, and network policy, and Kit never sees your code. Before going further, run the pipeline once in --dry-run mode against the bundled examples/sample-report fixture — it should go green and produce a canned triage with no Kit connection and no model key. That confirms the contract works before you wire anything live.

Step 1 — Connect Your Pipeline

Kit needs to fire your pipeline when a report arrives. In your forked GitLab project:

Go to Settings > CI/CD > Pipeline trigger tokens and Add new token.
Copy the generated trigger token and your project’s trigger URL.

Paste both into the stepper’s Connect your pipeline form — the GitLab pipeline trigger URL and the pipeline trigger token. Saving them activates the connection. The trigger token is stored encrypted and shown masked with a Change token link.

Kit then calls the GitLab pipeline trigger API on report submit, passing three per-run CI variables:

POST https://gitlab.com/api/v4/projects/<project_id>/trigger/pipeline
  --form token=<trigger_token>
  --form ref=main
  --form "variables[KIT_REPORT_ID]=rpt_..."
  --form "variables[KIT_TRIAGE_TOKEN]=<scoped, short-lived>"
  --form "variables[KIT_MCP_URL]=https://..."

Note

Kit passes the report ID, a short-lived scoped triage token, and the MCP callback URL as CI variables on the trigger call — not as anything you paste into your repo. CI variables have the highest precedence in GitLab and arrive per-run, so the scoped token and the callback URL are never stored in your repo or your project’s variable settings.

How Your Agent Calls Back

There is nothing to configure by hand here — no callback URL to paste, no signing secret. Your agent reads the report and posts the triage back through a scoped, single-report MCP endpoint. The example repo’s agent/mcp.json reads the KIT_MCP_URL and KIT_TRIAGE_TOKEN CI variables that Kit injected on the trigger call, so the connection is wired automatically for each run.

The KIT_TRIAGE_TOKEN is a bearer token the agent sends on its MCP calls back to Kit. Kit resolves it to exactly one report — it is the only authorization the endpoint needs.

Important

The scoped token grants access to one report, for one hour. It is not an account-wide API key. A new token is minted for every report and expires after an hour. This is what keeps a compromised CI job from reaching any report but the one it’s triaging.

Step 2 — Test It Now

The stepper’s Send test report button fires a real round-trip using a sample report: Kit triggers your pipeline, your agent reads the report through the scoped MCP token, runs, and posts a triage back.

This step turns green only when a real triage actually arrives back in Kit — not when the trigger merely fires. If your pipeline errors, times out, or posts an invalid blob, the stepper surfaces the last error on this step so you can re-run once it’s fixed.

Tip

If the test hangs in “running,” check that your self-managed runner is online and picking up jobs, and that your egress proxy actually allows the two permitted destinations (your model endpoint and Kit’s MCP host). A deny-all that’s too aggressive blocks the MCP callback too — see How the airgap works.

Done

Once the test round-trip lands, the stepper confirms your agent is wired up. From here, every new report fires your pipeline automatically.

Where the Card Lives

Once connected, a Code-Aware Triage card appears on your Integrations dashboard under Incident Response, next to Vanta and PagerDuty. It shows connected / disconnected status and the time of your last triage, and links back to this stepper.

Quick Checklist

VDP Add-on enabled and CSiRT program active
Fork vdp-ai-triage-example and run it in --dry-run against the sample report (green, no Kit, no key)
Set up a self-managed GitLab Runner — SaaS shared runners can’t be airgapped
Create a pipeline trigger token and paste the trigger URL + token into the stepper
Run Test it now and confirm it greens on a real arriving triage
Open a recent report and confirm the Code-Aware Triage panel renders

Next Steps

How the airgap works — set up the egress boundary correctly before going live
Customizing the triage prompt and model — point the agent at your model and tune the prompt
Code-Aware AI Triage — what the panel shows and how the loop works