Security orchestrator

Security Orchestrator

The single entry skill for security work. It locates the task on the posture × surface map — defend vs attack against code, agent-config, or live runtime — and delegates to one of six specialist spokes. The cross-cutting idea every spoke shares — the trust boundary: where untrusted, attacker-controlled input or action reaches a privileged sink, and the default-deny posture that contains it — lives in security-core; read it before triaging a finding or deciding whether something is exploitable.

Cluster map (spoke → role)

• security-review — Defensive code review. The build-time checklist: secrets management, authn/authz, input handling, API endpoints, payments, transport, plus a cloud-infrastructure-security companion. Use when writing or reviewing code that touches a sensitive surface.
• security-bounty-hunter — Offensive discovery. Hunts remotely reachable, user-controlled, exploitable vulnerabilities (SSRF, auth bypass, RCE, SQLi, path traversal) and discards noisy local-only findings. Use when the question is "does this actually pay / is this reportable?".
• security-scan — Agent-config audit. Scans a .claude/ setup (CLAUDE.md, settings.json, MCP servers, hooks, agent defs) for injection, over-permissive allowlists, and supply-chain risk via the ecc-agentshield tool. Use when securing the agent harness itself.
• repo-scan — Source-asset audit. Classifies every file as project / third-party / artifact, detects embedded (vendored) libraries and their versions, and emits four-level verdicts. Use to find outdated bundled OpenSSL/FFmpeg/etc. and unowned attack surface across a polyglot repo.
• gateguard — Pre-action fact-forcing gate. A PreToolUse hook that blocks the first Edit/Write/Bash and demands concrete investigation (importers, data schema, the user's instruction) before allowing it. Use to stop blind, guessed changes in an autonomous loop.
• safety-guard — Destructive-operation lock. Intercepts rm -rf, force-push, DROP TABLE, etc., and freezes writes to a chosen directory. Use to contain blast radius when an agent runs full-auto or on production.

Folded spokes (offensive recon, AppSec testing, threat intel)

These spokes extend the cluster beyond the original six — they cover the offensive recon → web/LLM testing pipeline and the threat-intelligence feeds that inform it. Route to them the same way (load on demand; see "Loading spokes on demand"):

• recon — Infrastructure & network reconnaissance. Passive-by-default WHOIS/DNS/cert-transparency/ASN mapping plus authorization-gated active port/service scanning. Use to map a target's attack surface (domains, IPs, netblocks, subdomains) before testing.
• osint — Open-source intelligence on people, companies, and entities/domains. Public-sources-only, authorization-first. Use for due diligence, background checks, or entity/threat-actor research; commonly hands off to recon for the technical infrastructure.
• webassessment — Web application security assessment. Builds an app narrative, threat-models it, then runs a 6-phase pentest (recon → mapping → vuln analysis → exploitation → reporting) with ffuf fuzzing. Use for "pentest / security-test this web app".
• promptinjection — LLM/AI application security testing. Direct, indirect (RAG/document), and multi-stage injection + jailbreak testing with an attack taxonomy and defense/remediation guidance. Use to test a chatbot or LLM feature for prompt injection. Authorized use only.
• secret-scanner — Leaked-secret detection. Scans files, .env, and git history for hardcoded API keys/credentials (AWS, Stripe, GitHub tokens, etc.). Use as a fast pre-push / CI credential-exposure check (complements security-review's secrets section).
• secupdates — Security news aggregation. Pulls and ranks the latest breaches, CVEs/research, and industry analysis from tl;dr sec, Krebs, THN, Schneier, etc. Use for "what's new in security / sec updates".
• annualreports — Annual security-report aggregation & analysis. Indexes 570+ industry threat/AppSec/cloud/ransomware reports and synthesizes cross-vendor trends. Use to pull or analyze the threat landscape from vendor annual reports.

Routing the additions:

• Recon / attack-surface mapping / OSINT / due diligence → recon, osint
• Web app or LLM/chatbot penetration testing → webassessment, promptinjection
• Credential-leak / secrets scan of a repo → secret-scanner
• Threat-intel & industry trends (news, CVEs, annual reports) → secupdates, annualreports

Routing rules by intent

Defend — code (build time)

• "Review this for security" / adding auth, input handling, secrets, payments → security-review
• Cloud/IaC posture (IAM, buckets, network) → security-review (cloud-infrastructure-security companion)

Attack — code (find real bugs)

• "Find exploitable vulns" / prep a Huntr/HackerOne report / triage exploitability → security-bounty-hunter

Audit — what's already there

• Audit the agent/Claude Code config → security-scan
• Audit the source tree (ownership, vendored deps, dead weight) → repo-scan

Contain — live agent runtime

• Force investigation before edits (quality + safety) → gateguard
• Block destructive commands / freeze the writable area → safety-guard

If the ask is broad ("make this secure"), default to security-review for the code path and offer security-scan for the agent config — they cover the two most common surfaces.

Sibling clusters (framework-native security)

This cluster owns cross-cutting security — review, scan, bounty — across any stack. When the concern is bound to a specific framework or domain, hand off to that cluster's own security spoke:

• Python/Django → django-security (cluster python-backend)
• PHP/Laravel → laravel-security (cluster php-laravel)
• JVM (Spring Boot / Quarkus) → springboot-security / quarkus-security (cluster jvm)
• On-chain / smart contracts → cluster blockchain-web3 (e.g. defi-amm-security)
• Desktop (Electron) → electron-security (cluster electron)

Use those for in-framework hardening; route back here for stack-agnostic code review, config/asset scanning, or exploitability triage.

Standard flow

1. Place the task on posture × surface: are we defending or attacking, and is the surface code, agent-config, or runtime?
2. If it involves judging a finding (reachable? user-controlled? meaningful sink?), pull the trust-boundary model from security-core first — exploitability is a property of the path, not the pattern.
3. Delegate to the spoke(s). Multi-surface asks fan out: e.g. "harden this agent project" → security-scan (config) + security-review (code) + safety-guard (runtime lock).
4. Return: chosen spoke(s), the surface/posture, the severity or verdict implied, and the next action.

Guardrails

See security-core. In short: default-deny — grant the narrowest permission/scope that works and treat any widening as a security change. Exploitability over theory — rank by "can attacker-controlled input reach a meaningful sink?", not by lint pattern count; drop local-only and out-of-scope noise. Contain before you trust — in autonomous runs keep safety-guard/gateguard on. Never weaken a control silently — disabling a gate, widening an allowlist, or adding a host is a stated decision, never a quiet one.

Loading spokes on demand

To keep CLI startup context lean, this cluster's spokes are not separately registered as skills — only this orchestrator and its *-core are enumerated. When you route to a spoke named above, load it on demand by reading its file:

~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md (or skills/<spoke-name>/SKILL.md inside the skill-clusters repo).