cy0307/awesome-loop-engineering
Awesome Loop Engineering Dataset A structured dataset of 1022 papers, official docs, tools, benchmarks, patterns, critiques, and implementation guides for recurring AI-agent systems. Resource Atlas · GitHub field guide · Resource selection · Report a correction Dataset Summary Each row connects an original source to its contribution, novelty, impact, publication details, lifecycle stages, audience, evidence type, link status, and… See the full description on the dataset page: https://huggingface.co/datasets/cy0307/awesome-loop-engineering.
34.9k
1# Security Review Loop2 3## Objective4 5Continuously review scoped code changes for security risks, validate findings with evidence, and escalate sensitive decisions to humans.6 7## Trigger8 9- Schedule: before release or weekly on active branches.10- Event: security-sensitive files change, dependency advisories appear, authentication/authorization code changes, or infrastructure config changes.11- Manual bootstrap/debug command: "run a security review loop for this PR."12 13## Intake14 15- Changed files, diff, threat model, sensitive paths, dependency advisories, secrets scan output, prior security issues, and relevant policy docs.16- Repository permission boundaries and disallowed actions.17- CI security checks, static analysis, dependency audit, and test results.18 19## Agents20 21- Explorer: maps attack surfaces and sensitive changes.22- Reviewer: checks for vulnerability classes and missing controls.23- Validator: distinguishes exploitable findings from speculative concerns.24- Reporter: writes concise findings with impact, evidence, and remediation.25- Judge: decides whether to open a PR, file an issue, or escalate.26 27## Workspace And Permissions28 29- Prefer read-only mode for exploration and finding validation.30- Allow static analysis, tests, dependency audit, and local proof-of-concept only against safe fixtures.31- Disallow secret exfiltration, production access, destructive testing, public disclosure, or broad rewrites without approval.32 33## Durable State34 35- Reviewed commit SHA, sensitive paths checked, commands run, findings, false positives, unresolved questions, and human decisions.36 37## Loop Steps38 391. Discover security-relevant diffs or scheduled review targets.401. Load security policy, threat model, and prior findings.411. Delegate surface mapping, review, validation, reporting, and judgment.421. Run allowed static checks and dependency/security scans.431. Validate each finding against code paths and realistic inputs.441. Record evidence, severity, and remediation options.451. Open a narrow PR for mechanical safe fixes or escalate sensitive decisions.46 47## Verification Gates48 49- Findings cite concrete files, paths, inputs, commands, or traces.50- Static analysis or tests support the claim when possible.51- Suggested fixes do not weaken security controls or broaden permissions.52- Sensitive actions are human-approved or explicitly out of scope.53 54## Budget And Exit55 56- Max retries: 2 validation attempts per finding.57- Max runtime: 90 minutes per review target.58- Stop when high-confidence findings are reported, safe fixes are proposed, no evidence-backed issues remain, or human approval is required.59 60## Escalation61 62Escalate for production credentials, exploitability uncertainty, public disclosure, authentication/authorization design, cryptography, data retention, compliance, or severity disagreements.63 64## Loop Instruction65 66```text67Run a security review loop for <PR, branch, or release>.68Stay read-only unless a narrow mechanical fix is explicitly safe.69Map the changed attack surface, run allowed checks, validate each finding with evidence, and avoid speculative claims.70Report impact, evidence, recommended fix, residual risk, and escalation needs.71Do not access production secrets or perform destructive testing.72```73 74Example automation: trigger on PRs touching auth, permissions, infra, dependency manifests, cryptography, logging, or data-handling code.75 76## Failure Modes77 78- Producing generic vulnerability lists without repository-specific evidence.79- Treating scanner output as truth without validation.80- Attempting unsafe proof-of-concept tests.81- Fixing security issues by silently changing product behavior or permissions.82 83## References84 85- [OpenAI Agents SDK human review](https://developers.openai.com/api/docs/guides/agents/guardrails-approvals) - Human approval boundaries for sensitive operations.86- [Engineering Agentic Systems for Reliability](https://pruningmypothos.com/systems/engineering-agentic-systems-for-reliability/) - Cautions about permissions, traceability, and escalation.87 