Security skills for your agent: install the ones that state their limits

Hand an agent a security task and let it work from general knowledge, and the first thing it loses is not skill — it is judgment about when the technique is allowed to run at all. It will fuzz a live host without asking whose host it is. It will fire a kernel privilege-escalation exploit that can panic the machine, on a box someone else depends on. It will pick one of two skills that share a name and never notice the other exists. The commands are usually fine; the missing part is the sentence that says only under these conditions.

Reading through the security skills people have published for agents, the sharpest signal of a good one turned out to be exactly that sentence. The keepers state the conditions their advice depends on — authorization, scope, prerequisites, and what breaks if you are wrong — right next to the commands. The throwaways are a bare command dump with the guardrail deleted. That single distinction sorts this space better than any feature list, and it even splits two skills that carry the identical name.

Top picks

Recon that will not start without a scope

recon-dir-scan wraps the four directory-fuzzing tools an agent would otherwise reach for at random — ffuf, gobuster, feroxbuster, and dirsearch — behind a single decision. Its very first section is an "Authorization Warning" that asks for written permission from the target owner and a defined scope before any command appears, and it is blunt about why: scanning "without proper authorization may be detected as intrusion attempts." What makes it usable rather than preachy is that the rest is genuinely practical — a tool-selection table that tells you when ffuf's filtering beats gobuster's simplicity, status-code filtering to cut false positives, and rate-limiting guidance so a scan does not hammer a target. It teaches the agent to slow down and to verify interesting results by hand, not just to spray a wordlist. Apache-2.0, and the safety framing is load-bearing, not decoration.

Privilege escalation: install the copy that admits it can crash the box

Two published skills are both named linux-privilege-escalation, both MIT, both walk the same ground — SUID binaries, sudo misconfigurations, capabilities, cron abuse, NFS. The one worth handing your agent is zebbern's, and the reason is entirely in what it says around the techniques. It opens with a "Required Access" block spelling out the shell foothold it assumes, and it closes with a "Legal and Ethical Requirements" section that is explicit — "Written authorization required before testing" within "defined scope boundaries" — where its counterpart states neither. It also warns where the other stays silent: "Failed kernel exploits may crash the system," so "Verify kernel exploits in test environment before production use." That is the prerequisite whose second half supplies the remedy — the thing an agent running on autopilot most needs to hear. The alternative, yaklang's, is not weak — its escalation decision tree and per-capability risk table are excellent, and it routes cleanly to sibling skills for container escape and lateral movement. But its entire framing is "Use when you have low-privilege shell access"; there is no authorization line, no scope boundary, no note that a failed exploit can take the host down. Reach for yaklang as a reference once scope is already settled; hand zebbern's to the agent that has not settled it yet.

Triage before you exploit

A common way an agent wastes a security task is diving into deep analysis of a binary it has not yet understood. binary-triage exists to stop that. It drives an eight-step survey through ReVa's tools — map the memory sections, page through strings, categorize imports by risk (it calls out the exact API families that matter, from VirtualAlloc to IsDebuggerPresent), then decompile only the entry point and one or two suspicious functions. Its discipline is the whole point: "This is an initial survey, not deep analysis," and it repeats "Do not do deep analysis yet" so the agent produces a prioritized to-do list of what to investigate next instead of burning the session on the first function it sees. It ends by emitting that list in a fixed output format. This is the skill that makes understanding what a binary does first an actual procedure rather than advice. Apache-2.0.

CTF exploitation that knows what it is not for

ctf-pwn is a binary-exploitation reference scoped tightly to capture-the-flag work, and its scoping is unusually explicit. The description states when not to load it — "use reverse engineering first" if you do not yet understand the binary, and not at all for "pure web bugs, disk or packet forensics, or standalone crypto/math challenges" — and a "When to Pivot" section hands the agent off to the right sibling skill instead of flailing. It declares its prerequisites plainly (a filesystem agent with bash, Python 3, and internet access), then gets concrete: a protection-to-strategy table that reads checksec output and tells the agent that partial RELRO with no PIE means a GOT overwrite while full RELRO forces a different target, plus the tool trio it drives — ROPgadget, ropper, one_gadget — through pwntools. Its same-named neighbor, cyberkaida's ctf-pwn, takes the opposite tack: it presents itself as a "generic exploitation framework" built around a seven-question reasoning sequence and the same ReVa toolset as binary-triage, with no prerequisites block and no line telling you when not to load it. Pick ljagiello's when you want an agent that stays in its lane; pick cyberkaida's when you want one that reasons from first principles about an unfamiliar bug. MIT and Apache-2.0 respectively.

The defensive side of the same knowledge

Every skill above targets a protection that some other skill is trying to stand up, and binary-hardening is the one standing them up. It walks an agent from reading a binary's current posture with checksec to a full hardened build — the RELRO, PIE, stack-canary, and FORTIFY_SOURCE flag set, Clang CFI, seccomp-bpf syscall filtering, and the hardware defenses (Intel CET, ARM PAC and MTE). What lifts it above a flag cheat-sheet is that it states conditions the same way the offensive picks do: FORTIFY_SOURCE=3 needs a recent GCC or Clang, CET requires hardware CET support, and the seccomp filter is "irreversible after this point" — the kind of caveat that stops an agent from shipping a build that either will not compile or silently drops its own protection. MIT, and the natural counterweight to hand over alongside any of the offensive skills here.

Telling two same-named skills apart

Twice in these picks the deciding factor was that two different skills carry one name: linux-privilege-escalation ships from both zebbern and yaklang, and ctf-pwn ships from both ljagiello and cyberkaida. This is not a quirk to route around — it is how community-published skills work. Names are not namespaced, so the same name routinely covers different documents, and occasionally different intentions entirely. A name tells you the topic; it does not tell you which document you are holding.

The check is quick. The publisher and the body are a skill's identity — open the actual instructions and read for the parts that do not appear in a card: does it state who may run it and within what scope, does it list prerequisites, does it tell you what fails and how badly? Between the two linux-privilege-escalation skills, that read is decisive in about a minute. Never trust the name alone to tell you what you installed.

What to check before you install a security skill

Run four questions over any security skill's body before you let an agent use it, because the good ones answer all four in writing and the rest answer none:

• Authorization and scope. Does the document say testing needs written permission and a defined scope? recon-dir-scan leads with it; metasploit-framework makes it a prerequisite ("Written authorization for testing," "Only use on systems you own or have written authorization to test") and even lists the engagement's expected deliverables. A skill that goes straight to commands has quietly made that decision for you.
• Prerequisites. Does it name the tools, versions, and access it assumes? binary-hardening's version gates and ctf-pwn's runtime requirements are the difference between a run that works and one that fails on the first command.
• What breaks. Does it warn where a technique is destructive or one-way? zebbern's kernel-crash caveat and binary-hardening's "irreversible after this point" are exactly the sentences an autopilot agent will otherwise skip.
• License. Check the repository record, not just a card. Every pick here declares MIT or Apache-2.0 in both places; when the two disagree or a skill declares nothing, treat that as a reason to slow down, not a footnote.

Conclusion

An agent doing security work from general knowledge is not short on technique — it is short on the conditions that make a technique safe to run: whose system this is, what the scope is, what will break, and which of two same-named skills it actually loaded. The skills worth installing are the ones that write those conditions down. For directory recon, recon-dir-scan puts the authorization gate before the first command. For privilege escalation, zebbern's linux-privilege-escalation is the copy that tells you a failed exploit can crash the box, where its same-named twin does not. binary-triage forces the agent to understand a binary before attacking it; ljagiello's ctf-pwn stays inside its declared lane; and binary-hardening is the defensive counterpart you hand over so the agent can also close the doors it just learned to open. Install those, apply the four-question read to anything else, and the judgment your agent was missing is now written into the skills themselves.