Automating bug bounty triage usually ends in a disaster of

I’ve been looking closely at how teams try to scale security operations, and there is a massive automation trap that almost everyone falls into. The temptation is to build a script that takes an incoming bug report, runs three automated scans, and spits out a "Duplicate" or "Informative" response. It feels efficient, but it’s not actually triage. Real triage requires judgment—knowing if a target is actually in scope, understanding the nuance of a reproduction step, and deciding when a human needs to intervene before a model says something embarrassing to a researcher.

I've been analyzing a setup called BountyDesk, which attempts to solve this by using an LLM agent to do the heavy lifting while keeping a human strictly in the loop for the final verdict. It’s built on the TrueForge agent harness, and the core philosophy is that the agent can draft the response, but it physically cannot publish it without a manual sign-off.

The Workflow Logic

The system doesn't just "chat" with a bug report. It follows a very specific, hardened data path to ensure that an AI hallucination doesn't accidentally close a critical vulnerability report. Here is how the pipeline actually moves:

GitHub issue
 -> signed intake
 -> durable worker
 -> TrueForge agent session
 -> sandbox investigation
 -> approval-gated verdict draft
 -> reviewer approval
 -> idempotent GitHub comment

The "approval-gated" part is the most important bit for anyone running a production security program. The agent performs the investigation inside an isolated sandbox (using Daytona) to see if the bug is actually reproducible. It then drafts a verdict. That verdict sits in a queue until a human reviews the exact wording. Only after that approval does the system post the comment back to GitHub.

Architecture and Deployment

The design philosophy here is about separation of concerns. You have three distinct layers: the control plane (BountyDesk), the agent runtime (TrueForge), and the target runtime (Daytona). By splitting these, the system ensures that the web interface never has direct access to sensitive GitHub installation tokens or the sandbox environment.

If you are looking at the technical implementation, the stack is surprisingly lean, which is great for a reliable deployment:

• Application Layer: Next.js App Router, React, and TypeScript.
• Database & State: Postgres on Supabase using Drizzle ORM.
• Job Queue: Instead of using a heavy external broker, it uses Postgres with SELECT ... FOR UPDATE SKIP LOCKED for durable job management.
• Agent Intelligence: TrueForge handles the sessions, sub-agents, and tool calling.
• Sandbox Environment: Daytona provides the runtime where the actual "investigation" happens.
• Integration: GitHub App webhooks for intake and short-lived installation tokens for delivery.

One thing that stood out to me during my deep dive is the use of Postgres as the queue. In a high-volume triage environment, you need real row locks to prevent multiple workers from grabbing the same bug report. Using a durable Postgres job table with worker leases is a much more robust way to handle webhooks than a simple in-memory queue.

It's a practical tutorial in how to build an AI workflow that actually works in a professional setting. You aren't just letting an LLM loose on your GitHub issues; you are giving it a specialized sandbox, a set of MCP tools, and a very short leash.