What Inspired Me

I've seen it happen on every team I've worked with: a CI pipeline flags a dozen security vulnerabilities, and they sit unresolved for days — sometimes weeks — not because developers don't care, but because the gap between detected and fixed is filled with tedious manual work. Read the raw scanner output. Figure out which findings actually matter. Locate the vulnerable code. Research the right fix. Write it. Open a PR. Document it. That's 30–45 minutes per finding, and most teams have dozens per week.

The moment I saw the GitLab Duo Agent Platform, I thought: this is exactly the right environment to close that loop. Not a chatbot that answers questions about security — but an autonomous system that actually does the work.

What I Built

SecSent AI is a four-agent autonomous security automation system built natively on the GitLab Duo Agent Platform, powered by Anthropic Claude. When triggered on a merge request — by a single mention or reviewer assignment — four specialized agents execute in sequence:

  1. Triage Agent — reads the MR diff, scans changed files, checks existing pipeline SAST findings, and uses grep to hunt for dangerous patterns across the full codebase. It classifies every finding by severity and flags which ones are safe to auto-fix.

  2. Fix Agent — fetches the vulnerable source files, uses Claude to generate minimal, targeted patches, runs the project's test suite to verify nothing breaks, and commits everything to a new fix branch.

  3. PR Agent — opens a fully documented merge request with a structured findings table, per-finding diff comments with confidence scores, and formally links the vulnerability records to the fix MR in GitLab's security tracking system.

  4. Verify Agent — checks the real CI pipeline status on the fix branch, then posts a clear plain-English summary back to the original MR with the fix MR link and a breakdown of what was fixed versus what needs manual attention.

The entire flow runs on GitLab's compute. No external infrastructure, no Python servers, no API keys to manage. Two YAML files — agent.yml and flow.yml — are the entire codebase.

How I Built It

The build process was an exercise in learning a brand-new platform from scratch under time pressure. I started by deeply reading the Flow Registry v1 documentation and the official tool catalog, then designed the four-agent architecture on paper before writing a single line of YAML.

The most important design decision was choosing AgentComponent for all four agents rather than OneOffComponent. Each step requires multi-turn iterative reasoning — the Fix Agent needs to read a file, think about the vulnerability, generate the patch, validate it, then commit. OneOffComponent would have been too limited for that.

The data pipeline between agents was the trickiest part. Since the platform passes data as plain strings through context:agent_name.final_answer, I designed structured text delimiters (TRIAGE_REPORT_START...END, FIX_MANIFEST_START...END) in the prompts so each downstream agent could reliably parse the previous agent's output without needing a formal schema registry.

I also ran into a real schema validator issue during CI: the ai-catalog-sync validator (v0.0.10) doesn't correctly handle the tool options object syntax (- "tool_name": { key: value }) on AgentComponent. The validator falls through to a DeterministicStepComponent schema check and fails with a misleading tool_name is missing error. The fix was to move the internal: true instruction into the prompt itself — Claude follows it reliably, and the validator passes cleanly.

What I Learned

  • The GitLab Duo Agent Platform is genuinely powerful but requires you to fully internalize its mental model. The biggest shift is accepting that you don't write code — you write instructions, and Claude executes them with real tools against real repositories.
  • Prompt engineering for agents is fundamentally different from prompt engineering for chatbots. System prompts need to define a numbered process, strict output formats, and explicit rules for edge cases — otherwise multi-agent handoffs break silently.
  • The official tool catalog name matters exactly. create_file doesn't exist — create_file_with_contents does. One character difference causes a cryptic schema validation failure.
  • Building within constraints forces better decisions. Having no external infrastructure forced a cleaner, more portable design.

Challenges

The biggest challenge was the lack of a local development environment. There's no way to run a flow locally — every test requires a full commit-push-trigger cycle on GitLab, which makes iteration slow. I worked around this by writing extremely explicit prompts with structured output formats, so I could read the flow logs and understand exactly where Claude deviated from the expected behavior without needing to re-run everything.

The second challenge was the schema validator strictness, described above. It took careful reading of the CI error output to trace exactly which tool name was causing the failure.

It is also worth noting the critical security vulnerability disclosed in March 2025 affecting Next.js middleware — tracked as CVE-2025-29927 — which allowed attackers to completely bypass authentication and authorization checks by manipulating a single internal request header. This meant that in affected applications, a malicious actor could gain unauthorized access to protected routes and sensitive server-side resources without ever providing valid credentials, effectively achieving remote access to parts of the application that should have been fully secured. The vulnerability underscored a fundamental truth: even the most widely adopted frameworks in the ecosystem are not immune to critical security flaws, and the gap between a vulnerability being introduced and a team actually patching it is where the real damage happens. SecSent AI is built precisely for that gap.

Built With

  • claude
  • gitlab
Share this project:

Updates