- by x32x01 ||
AI is becoming much more useful for cybersecurity than simply answering questions or explaining code. Recently, I started experimenting with AI agents for bug hunting, and the results were much more interesting than I expected.
Instead of using an AI assistant as a tool that waits for every instruction, I wanted to see what would happen if an AI agent could actually interact with security tools, analyze requests, follow a methodology, and investigate a target with much less guidance from me.
That led me to an interesting setup:
OpenCode + an AI model + Bug Hunting skills + Burp Suite
And eventually, I tested the workflow against both a vulnerable test application and a real bug bounty target.
Here is what happened.
A traditional AI assistant such as ChatGPT or Claude can help you analyze information, write code, explain a request, or generate a message. However, you usually have to perform the actual actions yourself.
For example, if you ask an AI assistant to write an email, it can generate the message, but you may still need to open your email application, find the recipient, paste the message, and send it.
An AI agent works differently.
An agent can use tools and interact with its environment to perform multiple steps in a workflow. Depending on the tools and permissions available to it, an agent can open applications, inspect information, execute commands, make decisions, and continue working toward a goal.
That difference becomes especially interesting in cybersecurity.
Instead of constantly telling the AI:
The model is responsible for understanding instructions, reasoning about the available information, and deciding what should happen next.
Examples include models such as GPT-5.6, Claude Sonnet, and other models designed for coding or agentic workflows.
A useful way to think about the architecture is:
AI Model = reasoning and decision-making
AI Agent = tools and execution environment
The model determines what it should do next, while the agent provides the environment and tools required to actually perform those actions.
This distinction becomes important when building an AI-powered bug hunting workflow.
At this point, we had: Agent + Model
But that alone was not enough for what I wanted to test.
I wanted the agent to understand common bug hunting workflows, so I added skills related to web application security and cybersecurity.
The idea was to give the agent a methodology and a collection of techniques that could help it investigate web applications.
For example, if the target contains a potential XSS attack surface, the agent can be instructed to investigate it rather than waiting for me to manually provide every individual request.
A simplified workflow might look like this:
I did not want to keep switching between Burp Suite and the AI agent.
A common workflow when using AI for bug hunting is:
So I asked a simple question:
Why not let the agent interact with Burp Suite directly?
That is where MCP came into the picture.
I connected OpenCode to Burp Suite through an MCP server, using a Burp extension that provides the integration.
Now the setup looked much more interesting:
OpenCode + AI Model + Security Skills + Burp Suite
The agent could work with HTTP traffic instead of relying entirely on requests that I manually copied and pasted.
I opened Burp Suite and browsed the application normally so that HTTP requests would appear in Burp's HTTP history.
Then I gave the agent a straightforward task:
Analyze the requests in Burp history and investigate the application for XSS.
I did not manually walk it through every request.
The agent started analyzing the available requests, using the XSS-related skills I had configured, and testing different requests through Burp.
After roughly two minutes, it was able to identify a reflected XSS vulnerability.
It also generated an exploit and produced a report describing the steps and result.
That was already interesting.
But there was an obvious limitation:
It was a deliberately vulnerable test environment.
So the next question was much more important.
Could the agent discover something on a real bug bounty target without me explaining the vulnerability beforehand?
I already knew about an Open Redirect vulnerability on the target.
Open Redirect vulnerabilities are often classified as low severity, although their real impact can depend heavily on how the affected application handles authentication and redirects.
The vulnerability itself was relatively simple, but there were a couple of interesting details.
What I wanted to know was:
Could the AI agent discover the same vulnerability without me explaining the trick first?
Before testing the agent, it is useful to explain how I found the issue manually.
Suppose a website has an authenticated page such as:
After logging in, you can access the page.
Now log out and try to access the same URL again.
Because you are no longer authenticated, the application may redirect you to the login page.
Some applications preserve the original destination so that, after authentication, you can automatically return to the page you originally requested.
For example:
That creates an interesting security question:
Can the redirect parameter be controlled by the user?
For example:
If the application accepts an external destination and redirects the user there after authentication, this may indicate an Open Redirect vulnerability.
The important part is not simply seeing a redirect parameter.
You need to understand how the application processes the value and whether an attacker can control the final destination.
This page displayed the user's orders.
I then logged out and tried to access the page again.
The application redirected me to a URL similar to:
At first, I wondered where the original destination had gone.
Then I noticed a parameter named:
The value looked encoded.
After decoding the Base64 value, I got:
That explained what the application was doing.
Instead of storing the original path directly, it was encoding it with Base64.
So I tested whether I could replace the encoded value with a Base64-encoded external URL.
For example:
becomes:
After changing the parameter and following the authentication flow, the application requested the login credentials and OTP.
Once authentication was completed, the application redirected me to the external domain.
That was the Open Redirect vulnerability I had discovered.
This time, I did not open Burp Suite and manually provide the agent with requests.
Instead, I gave the agent the target and asked it to look for an Open Redirect.
Then I let it investigate.
This was the part that impressed me the most.
The agent was able to reach the vulnerability without me explaining the Base64 encoding trick beforehand.
It also investigated whether the Open Redirect could be chained with other issues or potentially lead to a higher-impact scenario, such as account takeover or SSRF.
In this particular case, I had already investigated those possibilities manually and did not find a higher-impact chain.
So the vulnerability remained a low-severity Open Redirect.
Still, the experiment was successful from a different perspective.
The agent had managed to reproduce the general discovery process without being handed the exact vulnerability details.
At least, that is not what this experiment showed me.
What I found more interesting is where these agents can save time.
A large part of web application security testing involves repetitive tasks:
That gives the human researcher more time to focus on things that are much harder to automate.
The difficult cases often involve understanding the application's business logic.
For example, an experienced researcher may notice that two seemingly unrelated features interact in an unexpected way.
A vulnerability may depend on:
An AI agent can help investigate them, but human understanding of the application can still make a major difference.
The interesting part was the potential workflow.
Instead of spending a large amount of time manually performing repetitive security checks, an agent could potentially handle some of that work in the background.
The researcher can then spend more time understanding the application and looking for complex vulnerabilities that require deeper reasoning.
In other words:
AI does not necessarily replace the bug hunter. It can make the bug hunter more efficient.
That is the direction I am most interested in exploring.
The combination of an AI model, an agent, security-focused skills, and Burp Suite turned out to be surprisingly capable.
It successfully found a reflected XSS vulnerability in a test environment and later managed to discover an Open Redirect on a real bug bounty target without being given the exact trick I had used during my manual investigation.
The Open Redirect itself was ultimately low severity, and the agent did not find a higher-impact chain.
But that was not really the point.
The experiment showed me that AI agents can already be useful for automating repetitive parts of web security testing.
I am going to keep exploring this area because I think the combination of AI agents and bug hunting has a lot more potential than simply asking an AI chatbot to analyze a Burp request.
The real question is no longer just: "Can AI find vulnerabilities?"
It is becoming:
"How much of the bug hunting workflow can an AI agent handle while the human researcher focuses on the problems that actually require human insight?"
Instead of using an AI assistant as a tool that waits for every instruction, I wanted to see what would happen if an AI agent could actually interact with security tools, analyze requests, follow a methodology, and investigate a target with much less guidance from me.
That led me to an interesting setup:
OpenCode + an AI model + Bug Hunting skills + Burp Suite
And eventually, I tested the workflow against both a vulnerable test application and a real bug bounty target.
Here is what happened.
AI Assistant vs. AI Agent
Before getting into the bug hunting workflow, it is important to understand the difference between an AI assistant and an AI agent.A traditional AI assistant such as ChatGPT or Claude can help you analyze information, write code, explain a request, or generate a message. However, you usually have to perform the actual actions yourself.
For example, if you ask an AI assistant to write an email, it can generate the message, but you may still need to open your email application, find the recipient, paste the message, and send it.
An AI agent works differently.
An agent can use tools and interact with its environment to perform multiple steps in a workflow. Depending on the tools and permissions available to it, an agent can open applications, inspect information, execute commands, make decisions, and continue working toward a goal.
That difference becomes especially interesting in cybersecurity.
Instead of constantly telling the AI:
Then:
Then:
You can give the agent a goal and let it work through the investigation.
The AI Model Is the Brain
After installing OpenCode, there is another important component we need: the AI model.The model is responsible for understanding instructions, reasoning about the available information, and deciding what should happen next.
Examples include models such as GPT-5.6, Claude Sonnet, and other models designed for coding or agentic workflows.
A useful way to think about the architecture is:
AI Model = reasoning and decision-making
AI Agent = tools and execution environment
The model determines what it should do next, while the agent provides the environment and tools required to actually perform those actions.
This distinction becomes important when building an AI-powered bug hunting workflow.
Adding Bug Hunting Skills
OpenCode can work with different models, including free options. During my testing, I experimented with Muse Spark 1.3 from Meta, which was focused on coding and agentic workflows at the time.At this point, we had: Agent + Model
But that alone was not enough for what I wanted to test.
I wanted the agent to understand common bug hunting workflows, so I added skills related to web application security and cybersecurity.
The idea was to give the agent a methodology and a collection of techniques that could help it investigate web applications.
For example, if the target contains a potential XSS attack surface, the agent can be instructed to investigate it rather than waiting for me to manually provide every individual request.
A simplified workflow might look like this:
- Identify user-controlled input.
- Analyze how the input reaches the application.
- Test relevant parameters.
- Observe the application's response.
- Investigate whether the behavior is exploitable.
- Document the result.
Connecting OpenCode to Burp Suite
At this point, I had another problem.I did not want to keep switching between Burp Suite and the AI agent.
A common workflow when using AI for bug hunting is:
- Browse the application.
- Capture a request in Burp Suite.
- Copy the request.
- Send it to the AI.
- Ask the AI to analyze it.
- Make another request.
- Repeat the process.
So I asked a simple question:
Why not let the agent interact with Burp Suite directly?
That is where MCP came into the picture.
I connected OpenCode to Burp Suite through an MCP server, using a Burp extension that provides the integration.
Now the setup looked much more interesting:
OpenCode + AI Model + Security Skills + Burp Suite
The agent could work with HTTP traffic instead of relying entirely on requests that I manually copied and pasted.
Testing the Agent on an XSS Vulnerability
For the first experiment, I used a test website containing an XSS vulnerability.I opened Burp Suite and browsed the application normally so that HTTP requests would appear in Burp's HTTP history.
Then I gave the agent a straightforward task:
Analyze the requests in Burp history and investigate the application for XSS.
I did not manually walk it through every request.
The agent started analyzing the available requests, using the XSS-related skills I had configured, and testing different requests through Burp.
After roughly two minutes, it was able to identify a reflected XSS vulnerability.
It also generated an exploit and produced a report describing the steps and result.
That was already interesting.
But there was an obvious limitation:
It was a deliberately vulnerable test environment.
So the next question was much more important.
Could the agent discover something on a real bug bounty target without me explaining the vulnerability beforehand?
Testing an AI Agent on a Real Bug Bounty Target
For the second experiment, I used a real target that had a bug bounty program and that I had previously tested manually.I already knew about an Open Redirect vulnerability on the target.
Open Redirect vulnerabilities are often classified as low severity, although their real impact can depend heavily on how the affected application handles authentication and redirects.
The vulnerability itself was relatively simple, but there were a couple of interesting details.
What I wanted to know was:
Could the AI agent discover the same vulnerability without me explaining the trick first?
Before testing the agent, it is useful to explain how I found the issue manually.
How I Found the Open Redirect Manually
There is a simple pattern I like to test when investigating authentication flows.Suppose a website has an authenticated page such as:
example.com/account<br>After logging in, you can access the page.
Now log out and try to access the same URL again.
Because you are no longer authenticated, the application may redirect you to the login page.
Some applications preserve the original destination so that, after authentication, you can automatically return to the page you originally requested.
For example:
example.com/login?redirect=/account<br>That creates an interesting security question:
Can the redirect parameter be controlled by the user?
For example:
example.com/login?redirect=https://evil.com<br>If the application accepts an external destination and redirects the user there after authentication, this may indicate an Open Redirect vulnerability.
The important part is not simply seeing a redirect parameter.
You need to understand how the application processes the value and whether an attacker can control the final destination.
The Base64 Trick
On the target I was testing, I first logged in and opened an authenticated page:redacted.com/orders/order-list<br>This page displayed the user's orders.
I then logged out and tried to access the page again.
The application redirected me to a URL similar to:
http://redacted.com/?loginflow=true...<br>At first, I wondered where the original destination had gone.
Then I noticed a parameter named:
redirectingParam=L29yZGVycy9vcmRlci1saXN0<br>The value looked encoded.
After decoding the Base64 value, I got:
/orders/order-list<br>That explained what the application was doing.
Instead of storing the original path directly, it was encoding it with Base64.
So I tested whether I could replace the encoded value with a Base64-encoded external URL.
For example:
https://evil.com<br>becomes:
aHR0cHM6Ly9ldmlsLmNvbQ==<br>After changing the parameter and following the authentication flow, the application requested the login credentials and OTP.
Once authentication was completed, the application redirected me to the external domain.
That was the Open Redirect vulnerability I had discovered.
Could the AI Agent Find It?
Now came the part I was most interested in.This time, I did not open Burp Suite and manually provide the agent with requests.
Instead, I gave the agent the target and asked it to look for an Open Redirect.
Then I let it investigate.
This was the part that impressed me the most.
The agent was able to reach the vulnerability without me explaining the Base64 encoding trick beforehand.
It also investigated whether the Open Redirect could be chained with other issues or potentially lead to a higher-impact scenario, such as account takeover or SSRF.
In this particular case, I had already investigated those possibilities manually and did not find a higher-impact chain.
So the vulnerability remained a low-severity Open Redirect.
Still, the experiment was successful from a different perspective.
The agent had managed to reproduce the general discovery process without being handed the exact vulnerability details.
What This Means for Bug Hunting
I do not think AI agents are going to replace experienced bug hunters.At least, that is not what this experiment showed me.
What I found more interesting is where these agents can save time.
A large part of web application security testing involves repetitive tasks:
- Looking for user-controlled input
- Reviewing HTTP requests
- Testing common parameters
- Checking redirect behavior
- Repeating similar requests
- Looking for common vulnerability patterns
- Investigating large amounts of application traffic
- Documenting findings
That gives the human researcher more time to focus on things that are much harder to automate.
Where Human Bug Hunters Still Matter
Finding a basic vulnerability is only one part of bug hunting.The difficult cases often involve understanding the application's business logic.
For example, an experienced researcher may notice that two seemingly unrelated features interact in an unexpected way.
A vulnerability may depend on:
- A specific user role
- A particular workflow
- Multiple requests in a specific sequence
- An unusual business rule
- Trust relationships between different components
- A combination of individually harmless behaviors
An AI agent can help investigate them, but human understanding of the application can still make a major difference.
AI Agents Are Better Viewed as Force Multipliers
For me, the most interesting result from this experiment was not that an AI agent found a low-severity Open Redirect.The interesting part was the potential workflow.
Instead of spending a large amount of time manually performing repetitive security checks, an agent could potentially handle some of that work in the background.
The researcher can then spend more time understanding the application and looking for complex vulnerabilities that require deeper reasoning.
In other words:
AI does not necessarily replace the bug hunter. It can make the bug hunter more efficient.
That is the direction I am most interested in exploring.
Final Thoughts
This experiment started with a simple idea: connect an AI agent to the tools I already use for bug hunting and see what it can actually do.The combination of an AI model, an agent, security-focused skills, and Burp Suite turned out to be surprisingly capable.
It successfully found a reflected XSS vulnerability in a test environment and later managed to discover an Open Redirect on a real bug bounty target without being given the exact trick I had used during my manual investigation.
The Open Redirect itself was ultimately low severity, and the agent did not find a higher-impact chain.
But that was not really the point.
The experiment showed me that AI agents can already be useful for automating repetitive parts of web security testing.
I am going to keep exploring this area because I think the combination of AI agents and bug hunting has a lot more potential than simply asking an AI chatbot to analyze a Burp request.
The real question is no longer just: "Can AI find vulnerabilities?"
It is becoming:
"How much of the bug hunting workflow can an AI agent handle while the human researcher focuses on the problems that actually require human insight?"