Observed Behavior
The Security Auditor agent file (.github/agents/security-auditor.agent.md) explicitly states that the role "informs, doesn't block." There is no mechanism for a security finding — regardless of severity — to prevent a workflow from advancing to the approval gate. The orchestrator treats all security findings as informational annotations on the handoff artifact.
Why It Matters
For startups handling user data, financial transactions, or PII, a CRITICAL severity finding (e.g., hardcoded credentials, SQL injection, broken authentication) must stop the release pipeline. The current design makes it structurally impossible to enforce this without human vigilance on every single PR — which is exactly the manual overhead Teamwork is meant to eliminate.
The advisory-only model is safe for informational findings (low/info severity) but insufficient for high-impact vulnerabilities. Teams can't configure a policy; they can only hope the human reviewer notices the security findings before approving.
v2 Target
Security findings should map to structured severity levels: info / low / medium / high / critical.
A configurable quality gate in config.yaml should control blocking behavior:
quality_gates:
security:
blocking_severity: high # findings at this level or above block workflow advancementDefault: blocking_severity: high — consistent with most enterprise security policies. Teams can tune to critical-only or medium-and-above as needed.
The Security Auditor handoff artifact should include a structured findings section with severity tags that the workflow engine can evaluate at gate time, without requiring the human to manually parse prose.
Observed Behavior
The Security Auditor agent file (
.github/agents/security-auditor.agent.md) explicitly states that the role "informs, doesn't block." There is no mechanism for a security finding — regardless of severity — to prevent a workflow from advancing to the approval gate. The orchestrator treats all security findings as informational annotations on the handoff artifact.Why It Matters
For startups handling user data, financial transactions, or PII, a CRITICAL severity finding (e.g., hardcoded credentials, SQL injection, broken authentication) must stop the release pipeline. The current design makes it structurally impossible to enforce this without human vigilance on every single PR — which is exactly the manual overhead Teamwork is meant to eliminate.
The advisory-only model is safe for informational findings (low/info severity) but insufficient for high-impact vulnerabilities. Teams can't configure a policy; they can only hope the human reviewer notices the security findings before approving.
v2 Target
Security findings should map to structured severity levels:
info/low/medium/high/critical.A configurable quality gate in
config.yamlshould control blocking behavior:Default:
blocking_severity: high— consistent with most enterprise security policies. Teams can tune tocritical-only ormedium-and-above as needed.The Security Auditor handoff artifact should include a structured findings section with severity tags that the workflow engine can evaluate at gate time, without requiring the human to manually parse prose.