Inspiration
In digital forensics the evidence is the case. If a tool quietly stops noticing that a disk image changed under it, tampered evidence walks straight into a report, and from there into court. So when we built Fossick to run investigations on its own, the failure that scared us wasn't a missed finding — it was the tool fooling itself. "Life After Code" got us thinking about the part of that we could hand to agents: reviewing every change to the codebase against the one rule forensics can't break, and only shipping once a person has signed off.
What it does
Fossick is an autonomous DFIR platform. It takes a disk or memory image and runs a multi-agent investigation across the artifacts, producing findings with sources, flagged contradictions, and a chain-of-custody record.
Around the app we built a supervised security gate on the GitLab Duo Agent Platform, run by three agents:
- Scout reads a merge request and the code around it and reports what it sees. Read-only. It doesn't judge or decide.
- Counsel takes Scout's findings and weighs each against Fossick's one non-negotiable rule — the SHA-256 evidence integrity and chain of custody can never be weakened — assigns severity, and posts a single verdict.
- Shipper takes an approved change all the way to a running service, but only after a person approves at the gate.
The flow, Fossick Security Gate, reviews a merge request, posts its verdict, then stops and waits for a human. Nothing merges until someone decides. We showed both sides of that on real merge requests. One that quietly made the spoliation check non-fatal got blocked as a critical chain-of-custody regression — rejected at the gate, main left untouched. A genuinely good change, a new chain-of-custody attestation endpoint, got reviewed, cleared, approved, and shipped. The gate even caught a real bug in our own attestation code on the first pass — it could call a chain "intact" with no verified checkpoint — which we fixed before it cleared. That's the point: it isn't a rubber stamp.
How we built it
The agent side is three custom agents and one flow (flow-registry v1), published public to the AI Catalog, running on Claude Sonnet via Vertex. Counsel is the supervisor over Scout, and a human-input gate sits between the review and the Shipper, so a person has to approve before anything ships.
The app is Path B: we imported our existing MIT-licensed DFIR project into GitLab and deployed it live — a FastAPI backend, a forensic MCP server, and a React/Vite frontend, in one container on Cloud Run.
The pipeline is a GitLab CI run: tests, SAST and secret detection, a container build with kaniko to the Container Registry, a tagged Release with an auto-collected evidence file, the Cloud Run deploy, and a smoke test against the live URL. On approval, the Shipper drives it and reads the real job traces.
Every GitLab surface Fossick uses
- AI → Agents: Scout, Counsel, Shipper, each with a scoped GitLab toolset.
- AI → Flows: Fossick Security Gate — supervised, with a human approval gate between Counsel's verdict and the Shipper.
- AI → Catalog: all four items public and reusable.
- AI → Triggers & Sessions: a service account, triggered by a mention or a new MR; every run is a Session with a full tool-call log.
- Secure: Semgrep SAST and Secret Detection in CI — and the gate itself is a security review that blocks changes which weaken the evidence invariants.
- Build: the container is built with kaniko and pushed to the Container Registry.
- Releases: a tagged Release is cut with an auto-collected evidence file of what shipped.
- Deploy to Cloud Run:
gcloud run deployships the service; the verify stage smoke-tests the live URL. - Operate → Environments: the production environment and its history are populated by the flow's own service account on approval.
- Code → Merge Requests: the whole gate runs off a real MR; the Shipper merges with git.
- MCP: Fossick's forensic tools live behind their own MCP server (
mcp_server/, "fossick-sift") in the app, so the AI-tooling layer is part of the product.
Challenges we ran into
The flow's token can push but can't merge through the API (403 insufficient_scope), so the Shipper merges with git. Counsel once blocked a clean change over a pre-existing issue, so we scoped it to judge only what the diff introduces or worsens. And we worked hard to keep Counsel honest — it drops any finding it can't reproduce in the diff and says so. The best proof it works: it caught a genuine flaw in our own attestation endpoint, and we fixed the code rather than the verdict.
Accomplishments we're proud of
The gate has teeth — it blocked a planted chain-of-custody regression and found a real bug in our own code. The human sign-off is a real approval step, not decoration. And an approved change ships live to Cloud Run with a release-evidence trail behind it.
What we learned
For a forensic tool, "autonomous" has a ceiling. A person has to own the call that could let bad evidence through. Supervised was the right posture here, and the platform made the gate simple to wire — the same platform that ships DevFlow hands-off also lets Fossick stop and ask.
What's next
- The low-severity hardening Counsel suggested: normalize digest case before comparing, handle malformed log entries.
- Re-hash the evidence at attestation time instead of trusting stored flags.
- More gates for Fossick's other invariants (no injection into the forensic subprocess, no silent CORS widening).
Log in or sign up for Devpost to join the conversation.