AboutSecurity: A Pentest Knowledge Base Packaged for AI Agents

The gap AboutSecurity fills: methodology that an agent can read

Most pentest references are written for humans. They assume a reader who can skim a page, judge which section applies, and adapt the steps. An AI agent cannot do that reliably from prose. It needs a file it can load whole, with a name that tells it when the file is relevant. AboutSecurity is built around that constraint. The README describes the repository as a knowledge base with security methodologies in AI Agent-executable format, and the Skills directory holds more than 200 entries covering the chain from reconnaissance through post-exploitation. The intended user is a penetration tester or red teamer who already works inside an agent-assisted editor and wants the agent to reach for a structured procedure instead of improvising one. The secondary audience is anyone building tooling on top of the data: the Dic, Payload and Vuln directories are plain files with metadata, so they can be indexed or queried by something other than an agent.

How the Skills tree maps onto Claude Code's flat directory

The mechanism is a naming mismatch and a symlink. Claude Code only recognises a flat layout: .claude/skills/<name>/SKILL.md. AboutSecurity stores its skills in nested categories, so a SQL injection methodology lives at a path like skills/exploit/web-method/sql-injection/SKILL.md. The sync script bridges the two by creating symlinks that flatten the nested tree into the shape the agent expects. After syncing, the README states that the agent matches and loads relevant skills from conversation context without the user naming them. That is the whole design: no server, no plugin API, no runtime. The repository is a directory of markdown files plus a small script that makes those files discoverable.

The category structure is worth reading as a statement of scope. Exploit splits into advanced, auth, binary, network-service and web-method. Post-exploitation splits into OS-level privilege escalation, persistence, tool delivery and product-specific tactics. The README draws an explicit line between postexploit/ and Vuln/: skills describe what to do after access is gained, while Vuln entries carry affected versions, PoC code and exploitation steps per CVE. That distinction is the clearest organising idea in the project, and it is the part most likely to survive a rewrite of the surrounding tooling.

Dictionaries and payloads as plain files the agent reads at runtime

The Dic and Payload directories do not need syncing. The README's guidance is to point the agent at a path in conversation, for example asking it to use the dictionaries under Dic/auth/ to brute-force SSH, or to load the payload list from Payload/xss/ for fuzz testing. The agent reads those files through its Read and Glob tools. The README notes that dictionary and payload directories use lowercase hyphen-separated naming and that each carries a _meta.yaml file. That metadata file is the only structured hook the project offers for programmatic consumers, and the supplied material does not describe its schema. Anyone planning to build an index over Dic or Payload should inspect a _meta.yaml first, because the field names are not documented here.

Scale claims in the README are specific enough to be checkable: 200 or more skills, 600 or more vulnerability entries, 394 middleware entries, 19 port brute-force dictionary types. Treat those as counts to verify against the tree rather than as evidence of quality. A directory with 394 middleware entries can still be shallow on any single product.

Getting it running: clone, sync, or stand up the MCP server

The README gives two paths. The first is file-based. Clone the repository, then run the sync script from inside it:

git clone https://github.com/wgpsec/AboutSecurity.git cd AboutSecurity ./scripts/sync-claude-skills.sh --target /path/to/your-project

The result is a set of symlinks under .claude/skills/<skill-name>/ in the target project. Omitting --target syncs into the AboutSecurity repository itself, which is the mode for using an agent directly against the knowledge base. The README warns that the script must be re-run after skills are added or removed, which follows from the symlink approach: the flat directory is a derived view, not a source of truth.

The second path is the MCP service, which the README recommends. It points at a separate repository, wgpsec/context1337, described as a standalone MCP resource service that turns AboutSecurity into a consumable API. The setup is three commands:

git clone https://github.com/wgpsec/context1337.git cd context1337 make run

That single make target is documented as cloning the data, building the index and starting the server. Registration with Claude Code is one line:

claude mcp add aboutsecurity --transport http http://localhost:1337/mcp

After that the README shows natural-language queries such as searching for SQL injection resources or listing XSS payloads. Note that this path introduces a second repository with its own build and its own maintenance, and the README does not state which languages or runtime versions context1337 requires.

Where the design strains: symlinks, staleness and the missing licence

The symlink sync is the weakest joint. Every skill added upstream is invisible to a target project until someone re-runs the script, and the README says so plainly. In a team where one person updates the knowledge base and others consume it, that is a manual step that will be forgotten. A git submodule or a package registry would fail differently but fail less often. This is a real cost, not a theoretical one.

The licence is the second problem, and it is more serious. The supplied repository metadata lists the licence as unknown, and the README does not name one. For a repository that ships exploit payloads, default credentials for security appliances and OA systems, and per-CVE PoC code, the absence of a stated licence is not a formality. It determines whether a company can mirror the content internally, whether it can be redistributed in a product, and whether contributions carry any warranty. Until the maintainers state a licence, treat the terms as undefined. That is a factual observation about the material, not legal advice, and any organisation planning to embed this content should get its own answer.

The third strain is freshness. The README claims 600 or more vulnerability entries, but the releases listed are from January 2021, and the most recent push to the default branch is dated 2026. Those two signals point in opposite directions. Either the repository is being updated without tagged releases, or the vulnerability data has aged while the surrounding agent tooling was added. The README does not say which. Anyone relying on Vuln entries for current CVE coverage should check the dates inside the entries themselves before trusting the count.

How it differs from a scanner or a payload collection

The obvious comparison is a scanner such as nuclei, which the repository's own tool/ directory covers. The difference is what gets executed. A scanner ships templates that the tool runs against a target and reports on; the logic lives in the engine and the templates are data for that engine. AboutSecurity ships no engine. Its skills are instructions for a general-purpose agent, and the agent decides what to do with them. That makes AboutSecurity broader in coverage and far less deterministic. A nuclei template either matches or it does not. A skill file produces whatever the model does with it that day.

The second comparison is a conventional cheatsheet collection such as PayloadsAllTheThings. The content overlaps heavily. The difference is packaging: AboutSecurity adds the flat-directory sync for Claude Code and the MCP index in context1337, so the material can be retrieved by an agent without a human copying snippets. If you never use an agent, that packaging buys you nothing and you are left with a directory tree.

Maintenance cost and what to check before adopting

Two moving parts need attention. The sync script must be re-run whenever the skill set changes, and the MCP path adds context1337 as a second repository to clone, build and keep running. Neither is heavy, but both are manual. The dictionary and payload directories need no maintenance at all if you reference them by path.

Before adopting, verify the licence, since none is stated in the supplied metadata. Verify that ./scripts/sync-claude-skills.sh produces the symlink layout your project expects, because the README describes the output but not the script's error handling. Verify that make run in context1337 still completes on your machine, since that repository is separate and its requirements are not listed here. Finally, spot-check the date and depth of a few Vuln entries in the category you care about, because the release history and the recent push date do not agree on how actively the vulnerability data is maintained.

Editorial conclusion

Adopt it if your team already runs Claude Code or Cursor and wants methodology files the agent can load without you pasting cheatsheets into chat. Skip it if you need a tool that runs on its own, or if you work in an environment where a repository of offensive payloads cannot be cloned onto developer laptops. Before committing, verify three things: whether the sync script handles your target project layout, whether the MCP server context1337 still builds from source, and which licence actually covers the repository, because the supplied material does not state one.

Official sources

1. Issues
2. README
3. Releases
4. wgpsec/AboutSecurity on GitHub