Security Agent Skills: Testing Method, Not Another Scanner

Most security tooling ships as a scanner. You point it at a target, it runs a fixed set of checks, and it hands you a list. Security agent skills take the opposite shape. Instead of packaging the checks, they package the tester’s method: the order you look at things, the way you decide a lead is real, and the discipline that keeps you from calling a guess a finding. A skill is a short playbook an AI agent reads and follows, and its value is judgment, not a script.

What a security agent skill is

A skill is a small file with a name, a description of when to use it, and a body that walks an agent through one class of security work. The agent loads it the moment the task matches, the same way it loads any other instruction. The body does not tell the agent to run a specific product. It names the capability a step needs, for example “something that can answer who calls this function from a real parse,” and leaves the tool choice to whoever runs it.

That framing matters because the reasoning is the part that transfers. A scanner’s rules go stale and are tied to one engine. A method survives a rename, a new framework, and a different toolchain, because it describes how to think about a bug, not how to grep for one.

Why method beats a script

Anyone who has triaged scanner output knows the failure mode. The tool floods you with matches, ranks them by a number that does not mean much, and misses the bugs that need a chain of two or three steps to see. The reason is simple. A rule fires on a shape. A vulnerability is a shape plus a context, and the context is where the judgment lives.

A rank is triage, not a filter. A lead is a fact, never a verdict. You confirm it against the real code, or you kill it and write down why.

So every skill in the library is built on the same spine. Enumerate the whole taxonomy before you look at one family, so you do not tunnel on the first idea. Read a lead as evidence, not as a conclusion. Prove it with a path from source to sink, or a request that actually returns another user’s data, before you write it up. This is the same reasoning behind how experienced testers find vulnerabilities, and the same reason static analysis misses business logic.

What the library covers

The open collection spans five lanes, from white box code review to black box testing to red teaming an AI agent. A few of the areas it goes deep on:

AI agent and LLM red teaming

• The lethal trifecta. Where private data, untrusted content, and an exfiltration path meet in one agent context. Read the pattern in the lethal trifecta.
• Indirect prompt injection. Whether an agent obeys instructions hidden in content it ingests. Background in indirect prompt injection.
• MCP tool integrations. Tool poisoning, shadowing, and metadata that runs before consent. See MCP tool poisoning.
• Memory and retrieval poisoning. A poisoned index or memory that fires on an innocent query. See RAG data poisoning.
• Excessive agency. Missing approval gates, open egress, and denial of wallet. See excessive agency and least privilege for agent tools.

White box bug hunting

• Taint adjudication. Turn a source to sink lead into a confirmed finding or a documented kill. The method behind source to sink dataflow analysis.
• Guard gaps. Find the unguarded peer of a function that is checked everywhere else.
• Business logic. Step skipping, limit overrun, and replay that scanners never see. Background in business logic vulnerabilities.
• Fail open controls. A gate that allows on error, on an empty list, or on missing input. See fail open access control.

Web and access control depth

• Broken object level authorization. Reaching another user’s record through an id you should not control. See IDOR.
• Server side request forgery. Proving SSRF to internal reach and instance credentials. See SSRF.
• Request smuggling and cache attacks. Front end and back end desync, and the key versus response gap. See request smuggling and cache poisoning.

How a single skill runs

Each skill follows the same loop, so an agent behaves the same way whether it is reviewing code or probing an endpoint.

• Scope. Confirm the work is authorized. If you cannot name the authorization, you stop.
• Orient. Map the surface for this class of bug before touching one instance.
• Enumerate. List every candidate in the family, not just the first that catches your eye.
• Adjudicate. For each lead, read the provenance and decide. Confirm with a real path or a real request, or kill it and record the reason.
• Report. Emit the survivors in one shared finding schema, so results from any skill are consistent and ready to write up.

The kill step is the part that separates a method from a scanner. A skill is judged as much by the leads it throws away with a clear reason as by the bugs it keeps.

How to use it

The collection is open source under the MIT license, so you can read every skill before you run it. There are three ways to pick it up:

• As a plugin. Install the whole set into an agent that supports the skill format, and it routes to the right skill by name and description.
• One skill by hand. Copy a single skill folder into your own skills path when you only want one class of check.
• Any agent, by hand. The skill bodies are standalone playbooks. Read one and follow the loop yourself, running whatever tools you already have at each step.

The code, the full skill list, and the shared finding schema live in the security-agent-skills repository on GitHub.

The takeaway

A scanner encodes a list of known shapes. A skill encodes how a good tester reasons about a shape in context, which is the part that finds the bug two steps deep and throws away the noise. That is why the library leads with method and stays tool agnostic. Bring your own tools; keep the judgment.

This is the same principle UnboundCompute is built on. An autonomous researcher that studies how an application is meant to work, forms ideas about where that logic breaks, and proves a finding with hard evidence before reporting it. In early work, a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. You can read more on the about page.

For the AI agent side of this method, the AI Agent Security Field Guide maps how agents get attacked and how to defend each case.

Put an autonomous researcher on your own systems

UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.