Prove what agents did on your GitLab runners.
Self-managed GitLab runners execute CI/CD jobs, automation, and eligible GitLab Duo flows on infrastructure you control. Probity runs each job inside a hardware-isolated microVM and builds a tamper-evident record from outside the job's reach.
GitLab jobs inherit everything your runner can reach.
GitLab sends jobs to the runner, and the runner's executor clones source, downloads artifacts, uses job credentials, and runs the workload. GitLab Duo Agent Platform flows can use the same runner path. The job output is useful, but it is still an account produced inside the environment being observed.
CI/CD jobs can reach project secrets and internal services.
Duo flows can execute tools inside runner jobs.
Job output is not independent evidence of what ran.
Keep GitLab orchestration. Put each runner job behind an evidence boundary.
Grounded in the vendor's own documentation, not a bolt-on. GitLab's Duo and runner configuration docs ↗
Keep GitLab and Duo orchestration
GitLab continues to schedule CI/CD jobs and eligible Duo flows on your self-managed runners. Keep your projects, pipeline definitions, runner tags, and trigger paths unchanged.
Run each job in a Probity microVM
Use a Probity-backed execution path for the runner so each job runs inside a hardware-isolated microVM. Boundary and host observations remain outside the workload's control, while inside-job detail is treated as supporting context.
Ship one corroborated record per job
Probity signs the corroborated evidence into an append-only record and streams it to the SIEM and object store you already run. The model applies equally to standard CI jobs and Duo flows executed on that runner.
Your pipelines keep moving. Your security team gets evidence it can trust.
- Keep existing GitLab projects, pipelines, runner tags, and triggers.
- Run standard CI/CD jobs and eligible Duo flows on infrastructure you control.
- No new console for developers or pipeline operators.
- Outside evidence for process, file, and network activity on each job.
- Inside-job detail admitted only when outside observations corroborate it.
- One tamper-evident record in the SIEM you already operate.
Every GitLab runner job, fully recorded.
Seven classes of behavioral evidence per runner job, protected by one tamper-evident integrity chain.
Process activity
Every spawn, argument, and exit code.
File reads
Every path opened, secrets included.
File writes
Every file created or modified.
Network calls
Every outbound destination and method.
MCP tool calls
Every tool the agent invoked.
Syscall surface
The kernel calls it was allowed.
Session identity
Which scoped token, expiring per task.
One signed record per GitLab runner job, streamed to the SIEM and object store you already run.
Your GitLab job trail has to survive an incident review.
Article 12 applies to high-risk AI systems, and NYDFS Part 500 applies to covered entities. For every team, a GitLab job recorded only through its own output remains an incident and audit gap.
Private beta. Twelve deployments.
Probity is in private beta: the first cohort is limited to twelve deployments, each reviewed and onboarded by a NOFire AI founder.
Questions first? Write to contact@nofire.ai.