What it does for each finding
Data-flow analysis: is the flagged input actually user-controlled? Does it reach the sink the rule names?
Compensating-control detection: is there upstream validation, a WAF rule, or a secure wrapper already in place that defangs the issue?
Threat-graph correlation: was this risk identified at design review? Should a specific guardrail have caught it at write time?
Deduplication: is the same root cause being reported by multiple scanners under different rule ids?
Verdict synthesis: true positive, false positive, or acceptable risk, with a confidence score and an evidence summary.
Where it runs
Customer-side, with full codebase access. The triage agent is invoked by the flowrail-triage skill or the GitHub Actions adapter; it reads the finding, the relevant code (locally), and the threat graph (via MCP), and writes its verdict back to the workspace. In this v1 design, source code stays local to the agent; only the verdict and an evidence digest leave.
{
"finding_id": "fnd_d4a1c8e2",
"verdict": "false_positive",
"confidence": 0.87,
"evidence": [
"user_input sanitized at src/api/orders.ts:38 via zod schema",
"flagged sink at line 47 receives only validated values",
"no taint flow from request body to query parameter"
],
"guardrail_escape": false
}Guardrail-escape detection
If a finding correlates to a threat that the design review predicted but no Layer 2 guardrail caught the offending write, the verdict is flagged guardrail_escape: true. This is the failure mode that matters most: pre-write verification missed something it should have caught. The feedback loop turns this into action.
The feedback loop
When an escape is confirmed, FlowRail proposes a tightened version of the guardrail that would have caught the write. Three integrity protections gate auto-merge: rate limiting (no more than N updates per workspace per day), false-positive-rate monitoring (a proposed update has to pass replay testing on historical writes), and finding-cluster attribution (a single noisy scanner cannot drive a guardrail change alone). High-confidence proposals auto-merge; everything else queues for security-team review.
↳ Triage queue fnd_d4a1c8e2 src/api/orders.ts:42 injection false positive 0.87 fnd_e9bb31f0 src/auth/reset.ts:22 weak comparison true positive 0.95 ⚠ escape fnd_2c80a7d4 src/upload.ts:14 path traversal accepted risk 0.71 → owner: priya ↳ Proposed guardrail update (queued for review) no-secrets-in-code + tighten: detect == comparison on token-shaped vars rationale: 3 escapes in last 7 days, all matching the same shape
Autonomy slider
Triage verdicts and guardrail proposals each have their own autonomy setting per workspace: autonomous (apply without review), notify (apply but ping the security team), human-approves (queue for explicit approval). Set them once on the security leader page; per-finding overrides are also available.