Table of Contents
AI agents are already changing offensive security. We built an open framework to help researchers use them while keeping control over scope, evidence, and reporting quality.
AI agents are already part of offensive security workflows.
Researchers use tools such as Claude Code, Codex, Cursor or Windsurf to analyze applications, explore attack paths, and assist with vulnerability reporting. They can accelerate research and help researchers investigate more efficiently.
But as their adoption grew, we started seeing another side of the equation.
Agents could continue testing beyond the authorized scope. They could perform unnecessarily destructive actions to demonstrate impact. They could interact with real user data where test accounts would have been enough. Or they could turn a Medium vulnerability into a Critical one by scoring what could happen rather than what had actually been demonstrated.
The problem wasn’t that researchers were using AI agents.
The problem was that nobody had given the agent the rules of the game.
So we decided to do exactly that.
From correcting reports to guiding agents upstream
Bug bounty comes with constraints that are obvious to an experienced researcher, but aren’t necessarily obvious to an AI agent.
Stay within scope. Don’t cause damage. Don’t access real customer data when it isn’t necessary. Demonstrate the vulnerability rather than extrapolating its impact. Score what you can prove. Produce a report that another human can reproduce.
Instead of dealing with these issues after testing, during triage, we wanted to address them earlier in the process.
That’s why we built the Yogosha Skill: a common set of rules of engagement and report-quality instructions that an AI agent can load before it starts working.
The objective is twofold: guide the agent toward in-scope, non-destructive testing and improve report quality through stronger evidence, controls, and more defensible CVSS scoring.
And it isn’t tied to a single model or vendor.
One source, six agent integrations
Most coding agents provide a standard mechanism for loading project-level instructions.
Codex and OpenAI CLI can read an AGENTS.md file. Cursor has project rules. Windsurf and Continue have their respective rule formats. For an agent built directly on an API, the same instructions can be passed as a system message. Claude Code can use the complete Yogosha plugin or its rules directly.
At the center of the project is one file: RULES.md.
It is the single source of truth.
The agent-specific versions are generated from that source so that the methodology remains consistent regardless of the tool being used. Today, the project covers six implementations: Claude Code, Codex/OpenAI CLI, Cursor, Windsurf, Continue and raw API-based agents.
One source. Six agents. Zero methodology drift.
But what matters most isn’t where those rules live. It’s what they make the agent do differently.
Show the proof, don’t just tell the story
One of the core principles of the Skill is what we call load-bearing proof.
Every vulnerability has a decisive step that actually demonstrates the issue.
Take an authorization flaw. Showing that an endpoint exists isn’t enough. The report needs to demonstrate that unauthorized access actually occurred.
If that decisive step hasn’t been captured, the agent must not write the report as though it had been demonstrated.
Potential impact remains potential impact.
The Skill also asks the agent to perform negative controls alongside positive results. An invalid identifier returning a 404, another user’s identifier returning a 403, or a corrupted token producing an error can help establish that a successful test represents an actual security issue rather than caching, routing or default application behavior.
The principle is simple:
Show the proof, don’t just tell the story.
A Critical vulnerability has to earn its Critical score
AI-generated reports can sound extremely convincing.
That becomes a problem when confidence in the language exceeds confidence in the evidence.
The Skill therefore challenges the proposed CVSS 4.0 vector. The agent examines each metric and requires captured evidence for High or Critical values. Demonstrated impact and hypothetical impact must remain clearly separated.
If the evidence doesn’t support a metric, the score should be adjusted and the reason explained.
Our rule of thumb:
A defensible Medium is better than a rejected Critical.
For the researcher, that means producing a report that is easier to defend. For triage, it means less time spent challenging unsupported assumptions. And for the customer, it means receiving a severity assessment grounded in demonstrated impact.
Non-destructive by default
Scope and testing behavior are another core part of the Skill.
The agent is instructed to stay within the program scope and use the researcher’s own test accounts.
No brute force. No denial of service. No unnecessary access to real customer data. Any modification performed during testing should be restored.
And if demonstrating a vulnerability would require a destructive action, the agent should stop and describe safe manual validation steps instead of executing that action itself.
This distinction matters because an AI agent can be very effective at pursuing an objective.
What it doesn’t inherently know is when pursuing that objective further is no longer acceptable.
From testing to reporting
For Claude Code, we went further than a set of instructions.
The Yogosha plugin can accompany the researcher through the reporting workflow.
Starting from the researcher’s notes, the agent can check the scope, plan the decisive proof and its controls, guide non-destructive testing, challenge the CVSS score, structure the report and review it from a triager’s perspective.
When the report is ready, it can create a draft on the Yogosha platform after explicit confirmation from the researcher. Once the evidence has been added, it can also verify that the expected screenshots and video are present before submission.
The plugin can connect to the platform through the official Yogosha MCP server. MCP, or Model Context Protocol, allows an AI agent to interact with external tools. In this case, it can access capabilities such as reading a program and its scope or working with the researcher’s own reports.
Throughout the workflow, however, one principle remains:
The agent prepares. The researcher decides.
Actions that write to the platform require explicit confirmation. Submission remains a human decision.
A behavioral guardrail, not a security boundary
There is an important limitation to all of this.
The Yogosha Skill is not a sandbox or a security control.
It doesn’t technically prevent an agent from reaching an out-of-scope host. It cannot stop a malicious operator from ignoring the rules. And it cannot protect a workflow where the agent doesn’t load the instructions in the first place.
It is a behavioral guardrail designed to make a cooperative AI agent much more likely to remain within scope, test without causing harm and report vulnerabilities accurately.
Hard enforcement still belongs to infrastructure: restricted outbound access, rate limiting, test data and other technical controls.
We’re not pretending that a Markdown file is a security boundary.
We’re using methodology to make AI-assisted security research more predictable, reproducible and useful.
Testing the rules themselves
Of course, writing rules for an AI agent isn’t enough.
We also need to test whether the agent follows them.
The Skill is evaluated using adversarial scenarios: requests to go out of scope, extract large amounts of data, perform destructive writes in production, inflate vulnerability severity or use brute force.
We compare agent behavior with and without the rules over multiple runs rather than relying on a single successful example. The same test suite can then be used for non-regression testing as the Skill evolves.
RULES.md remains the single source of truth, while agent-specific files are regenerated to remain synchronized. Continuous integration also includes secret detection.
Because if we’re going to give AI agents rules, we also need to test whether they actually follow them.
AI is already in the workflow. Now it needs a methodology.
The question is no longer whether security researchers will use AI agents.
They already do.
The more interesting question is how we make sure those agents inherit the practices that experienced researchers and triagers have built over years: respect the scope, minimize impact, prove what you claim, challenge your own assumptions, and keep humans in control of the final decision.
That’s what the Yogosha Skill is designed to do.
The project is open and available.
Same agent. Now with the rules of the game.
