Run a security mission

Investigate a dependency, vulnerability, or trust boundary with evidence and safe stop conditions.

Last updated August 2026Copy a starter prompt ↓

Name the security outcome

Security work needs a narrower claim than “make this secure.” Start with one advisory, one trust boundary, one abuse case, or one dependency upgrade.

Ask your coding agent

Run a Brief security mission for <finding, dependency, or trust boundary>. Establish the affected versions and reachable code path from primary evidence. Map the data and permission boundary, identify realistic abuse cases, and separate confirmed facts from hypotheses. Propose the smallest safe remediation and its rollback path before editing.

Prove the fix and the negative path

Ask your coding agent

Implement the approved security fix. Add a regression test that fails before the change, test denied and malformed inputs, check logs and errors for secret leakage, run the relevant dependency or static analysis, and review the final diff for new permissions, network access, executable hooks, or credential handling. Do not expose exploit details beyond what the team needs to verify the fix.

Stop when authority or evidence is missing

Stop before rotating or revoking production credentials without approval.
Stop before destructive data changes or widened permissions.
Escalate when exploitability cannot be established safely.
Keep sensitive findings and customer data inside the approved boundary.

Was this guide useful?Help us make Brief easier to learn.

Ready for another workflow?Choose your next mission →