Security

Security Skill

Purpose: Find and report security weaknesses in code, scripts, authorized binaries, and repo-managed prompt surfaces, with honest coverage.

Use this skill for a caller-requested security review of code, a repository scan, authorized binary assurance, dependency risk, secrets, or offline prompt-surface redteam.

Critical Constraints

• Scan only repositories, binaries, and prompt surfaces the operator owns or is explicitly authorized to assess. Why: a security review does not grant access to third-party systems or proprietary material.
• Keep collection read-only by default; do not exfiltrate secrets, execute destructive payloads, or mutate policy/baselines to manufacture green. Why: the assessment must not become the incident or erase its evidence.
• Treat missing/error scanners as a coverage gap, never a clean finding; use --require-tools when complete tool coverage is required. Why: absent evidence is not evidence of absence.
• Use the current agent and local shell; do not start another runtime or orchestration substrate unless explicitly requested. Why: repository scanning is a bounded operation, not permission to fan out.
• Report findings and coverage gaps, then stop. Remediation, risk acceptance, reruns, promotion, and any ship or merge call are caller decisions. Name each finding's remediation class in a few words; do not write the patch, a plan, an owner, or a priority.

What every review reports

Apply these to every review, scripted or manual. They are the rules most often skipped:

1. Fail-open paths. For every guard, check, timeout, and exception handler on the surface, ask what happens when it errors or hangs. A control that grants access, skips a check, or continues as success on error is a finding even when its happy path is correct.
2. Borrowed identity. Trace the effective identity at each hop (user, service, token, default, hook). A hop where identity is assumed, defaulted, or inherited instead of verified is the borrowed identity failure mode and a finding.
3. Per-class coverage ledger. Walk every applicable class in the OWASP checklist (the attack pack for prompt surfaces), plus fail-open and identity, and give each a result: finding, clean, or not assessed. An unvisited class is a gap, never a clean. Chasing one lead to the exclusion of the taxonomy is the first-scent fixation failure mode.
4. Proven versus suspected. A finding is proven only when you ran a concrete input, request, or command and observed the behavior; capture it. A finding reasoned from the code is suspected, even with a candidate input; give that input and rank it below proven findings.

target:   <paths, endpoints, or binary>; authorization: <boundary>
findings: <id> <severity> <file:line> <class>: <what>
          proven: <input run> | suspected: <candidate input, why not run>
          fix class: <a few words>
coverage: <class> -> finding <ids> | clean | not assessed (<why>)
tools:    <scanner or command> -> ran | missing | error
hunt:     converged after <n> passes | unconverged | not run

Manual hunt

Code-level review and redteam passes work in any repository, with or without AgentOps tooling. Walk the ledger against the full surface and probe fail-open behavior where that is safe. Repeat full passes until one complete pass adds no new finding and no new coverage gap; that quiet round is the stop condition. If the budget ends first, report the hunt as unconverged. The quiet-round rule applies only to the manual hunt.

Scripted scans

Each selected scan runs once per request; a rerun is a new caller decision.

• No gate script (any other repository): run the scanners the project already uses, such as a dependency audit, secret scan, or static analyzer, record each one that is absent as a coverage gap, and do the manual hunt.
• Redteam pack: the bundled attack pack targets AgentOps control surfaces. In another repository its cases fail with "no files matched target globs"; that is a pack mismatch, not a finding.
• Read the suite runbook before binary, policy, baseline, or redteam work.

This is the canonical security runbook. Suite policy gating produces machine-consumable outputs, including policy/policy-verdict.json when a policy file is supplied.