- by x32x01 ||
AI is becoming much more useful for cybersecurity than simply answering questions or explaining code.
Instead of using an AI assistant that waits for every instruction, you can connect an AI agent to security tools and give it a goal. The agent can then analyze information, interact with tools, investigate potential vulnerabilities, and report what it finds.
That is exactly what I wanted to test using:
The results were surprisingly interesting.
For example, you might tell an AI:
Analyze this request.
Then you might manually send another request and ask:
Check this parameter.
Then you repeat the process for another endpoint.
An AI agent works differently.
An agent can use available tools and interact with its environment to perform multiple steps toward a goal. Depending on its permissions and integrations, it can execute commands, inspect information, analyze requests, and continue an investigation with much less manual guidance.
That difference becomes especially interesting in cybersecurity.
Instead of manually telling the agent what to investigate at every step, you can give it a security objective and allow it to work through an appropriate methodology.
The model is responsible for understanding instructions, analyzing results, deciding what to investigate next, and producing useful conclusions.
A simple way to think about the architecture is:
AI Model = reasoning and decision-making
AI Agent = tools and execution environment
The model decides what should happen next, while the agent provides the environment and tools required to perform those actions.
This distinction is important when building an AI-powered security testing workflow.
For my experiment, I wanted the agent to have access to skills related to web application security and bug hunting.
The goal was to give it a methodology that could help it investigate common web vulnerabilities rather than expecting it to discover everything from scratch.
For example, when investigating a potential XSS attack surface, a simplified workflow could be:
I did not want to constantly switch between Burp Suite and the AI agent.
A typical workflow might look like this:
So I wanted the agent to interact with Burp Suite directly.
This is where MCP became useful.
I connected OpenCode to Burp Suite through an MCP server using a Burp extension that provides the integration.
The setup then looked like this:
OpenCode + AI Model + Security Skills + Burp Suite
Instead of relying entirely on requests that I manually copied and pasted, the agent could work with HTTP traffic through the connected security tooling.
I opened Burp Suite and browsed the application normally so that HTTP requests appeared 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 traffic and using the XSS-related skills I had configured. It then tested relevant requests through Burp.
After roughly two minutes, it identified a reflected XSS vulnerability.
It also generated an exploit demonstration and produced a report describing the steps and result.
That was interesting, but there was an obvious limitation:
The application was deliberately vulnerable.
So the next question was more important.
Could an AI agent discover something on a real bug bounty target without being told exactly what vulnerability to look for?
I already knew about an Open Redirect vulnerability on the target.
Open Redirect vulnerabilities are often considered low severity, although their impact depends on how the affected application handles redirects and authentication.
The vulnerability itself was relatively simple, but there was an interesting detail that I wanted to see whether the agent could discover independently.
The question was:
Could the AI agent find the same vulnerability without me explaining the trick beforehand?
Before testing that, it helps to understand how I found the issue manually.
Suppose an authenticated page is:
After logging in, the page is accessible.
Now log out and request the same page again.
The application may redirect you to the login page. Some applications preserve the original destination so that the user can return to the requested page after authentication.
For example:
That creates an important security question:
Can the redirect destination be controlled by the user?
For example:
If an application accepts an attacker-controlled external destination and redirects the user there after authentication, that behavior may indicate an Open Redirect vulnerability.
However, simply finding a parameter named
You need to understand how the application processes the value and whether the final destination can actually be controlled.
The page displayed the user's orders.
I then logged out and requested the same 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:
Its value looked encoded:
After decoding the Base64 value, I got:
That explained what the application was doing.
Instead of storing the original path directly, the application was encoding it with Base64.
I then tested whether the parameter could be replaced with an encoded external URL.
For example, the URL:
can be Base64-encoded as:
After changing the parameter and completing the authentication flow, the application redirected me to the external domain.
That demonstrated the Open Redirect behavior.
This time, I did not manually provide the agent with the specific requests or explain the Base64 encoding technique.
Instead, I gave the agent the authorized target and asked it to investigate for an Open Redirect.
Then I let it work.
The agent was able to reach the vulnerability without being told about the Base64 encoding trick beforehand.
It also investigated whether the Open Redirect could potentially be combined with other weaknesses to create a higher-impact attack scenario.
For example, it considered whether the behavior could potentially be related to account takeover or SSRF.
In this particular case, I had already investigated those possibilities manually and did not find a higher-impact chain.
The vulnerability therefore remained a low-severity Open Redirect.
Still, the experiment demonstrated something useful:
The agent was able to reproduce the general discovery process without being given the exact technique I had used during my manual investigation.
At least, that is not what this experiment demonstrated.
What I found more interesting is where AI agents can potentially save time.
A large part of web application security testing involves repetitive tasks such as:
That gives the human researcher more time to focus on problems that are much harder to automate.
The difficult cases often involve understanding an application's business logic.
An experienced researcher may notice that two seemingly unrelated features interact in an unexpected way.
A vulnerability might depend on:
An AI agent can help investigate them, but a human's understanding of the application's architecture and business logic can still make a major difference.
The interesting part was the 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, validating findings, 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 identified a reflected XSS vulnerability in a deliberately vulnerable test environment and later discovered an Open Redirect on a real authorized bug bounty target without being given the exact technique I had used during my manual investigation.
The Open Redirect itself was ultimately low severity, and the agent did not discover a higher-impact chain.
But that was not really the point.
The experiment showed that AI agents can already be useful for automating repetitive parts of web security testing.
The real question is no longer simply: "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 that waits for every instruction, you can connect an AI agent to security tools and give it a goal. The agent can then analyze information, interact with tools, investigate potential vulnerabilities, and report what it finds.
That is exactly what I wanted to test using:
- OpenCode
- An AI model
- Bug hunting skills
- Burp Suite
The results were surprisingly interesting.
AI Assistant vs. AI Agent
A traditional AI assistant such as ChatGPT or Claude can analyze information, explain code, or help you understand an HTTP request. However, you normally have to perform the actual actions yourself.For example, you might tell an AI:
Analyze this request.
Then you might manually send another request and ask:
Check this parameter.
Then you repeat the process for another endpoint.
An AI agent works differently.
An agent can use available tools and interact with its environment to perform multiple steps toward a goal. Depending on its permissions and integrations, it can execute commands, inspect information, analyze requests, and continue an investigation with much less manual guidance.
That difference becomes especially interesting in cybersecurity.
Instead of manually telling the agent what to investigate at every step, you can give it a security objective and allow it to work through an appropriate methodology.
The AI Model Is the Brain
After setting up OpenCode, you need an AI model capable of reasoning about the information provided by the agent.The model is responsible for understanding instructions, analyzing results, deciding what to investigate next, and producing useful conclusions.
A simple way to think about the architecture is:
AI Model = reasoning and decision-making
AI Agent = tools and execution environment
The model decides what should happen next, while the agent provides the environment and tools required to perform those actions.
This distinction is important when building an AI-powered security testing workflow.
Adding Bug Hunting Skills
An AI model alone does not automatically understand every security testing methodology.For my experiment, I wanted the agent to have access to skills related to web application security and bug hunting.
The goal was to give it a methodology that could help it investigate common web vulnerabilities rather than expecting it to discover everything from scratch.
For example, when investigating a potential XSS attack surface, a simplified workflow could be:
- Identify user-controlled input.
- Determine how the input reaches the application.
- Test relevant parameters.
- Analyze the application's responses.
- Determine whether the behavior is actually exploitable.
- Document the result.
Connecting OpenCode to Burp Suite
There was still one major problem.I did not want to constantly switch between Burp Suite and the AI agent.
A typical workflow might look like this:
- Browse the application.
- Capture a request in Burp Suite.
- Copy the request.
- Send it to the AI.
- Ask the AI to analyze it.
- Modify the request.
- Send another request.
- Repeat the process.
So I wanted the agent to interact with Burp Suite directly.
This is where MCP became useful.
I connected OpenCode to Burp Suite through an MCP server using a Burp extension that provides the integration.
The setup then looked like this:
OpenCode + AI Model + Security Skills + Burp Suite
Instead of relying entirely on requests that I manually copied and pasted, the agent could work with HTTP traffic through the connected security tooling.
Testing the Agent on an XSS Vulnerability
For the first experiment, I used a deliberately vulnerable test application containing an XSS vulnerability.I opened Burp Suite and browsed the application normally so that HTTP requests appeared 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 traffic and using the XSS-related skills I had configured. It then tested relevant requests through Burp.
After roughly two minutes, it identified a reflected XSS vulnerability.
It also generated an exploit demonstration and produced a report describing the steps and result.
That was interesting, but there was an obvious limitation:
The application was deliberately vulnerable.
So the next question was more important.
Could an AI agent discover something on a real bug bounty target without being told exactly what vulnerability to look for?
Testing an AI Agent on a Real Bug Bounty Target
For the second experiment, I used a real target that had an authorized 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 considered low severity, although their impact depends on how the affected application handles redirects and authentication.
The vulnerability itself was relatively simple, but there was an interesting detail that I wanted to see whether the agent could discover independently.
The question was:
Could the AI agent find the same vulnerability without me explaining the trick beforehand?
Before testing that, it helps to understand how I found the issue manually.
How I Found the Open Redirect Manually
One useful pattern when investigating authentication flows is to look at what happens when an unauthenticated user requests a page that normally requires authentication.Suppose an authenticated page is:
example.com/accountAfter logging in, the page is accessible.
Now log out and request the same page again.
The application may redirect you to the login page. Some applications preserve the original destination so that the user can return to the requested page after authentication.
For example:
example.com/login?redirect=/accountThat creates an important security question:
Can the redirect destination be controlled by the user?
For example:
example.com/login?redirect=https://example.comIf an application accepts an attacker-controlled external destination and redirects the user there after authentication, that behavior may indicate an Open Redirect vulnerability.
However, simply finding a parameter named
redirect is not enough.You need to understand how the application processes the value and whether the final destination can actually be controlled.
The Base64 Trick
On the target I was testing, I first logged in and opened an authenticated page:redacted.com/orders/order-listThe page displayed the user's orders.
I then logged out and requested the same page again.
The application redirected me to a URL similar to:
http://redacted.com/?loginflow=true...At first, I wondered where the original destination had gone.
Then I noticed a parameter named:
redirectingParamIts value looked encoded:
L29yZGVycy9vcmRlci1saXN0After decoding the Base64 value, I got:
/orders/order-listThat explained what the application was doing.
Instead of storing the original path directly, the application was encoding it with Base64.
I then tested whether the parameter could be replaced with an encoded external URL.
For example, the URL:
https://example.comcan be Base64-encoded as:
aHR0cHM6Ly9leGFtcGxlLmNvbQ==After changing the parameter and completing the authentication flow, the application redirected me to the external domain.
That demonstrated the Open Redirect behavior.
Could the AI Agent Find It?
This was the part I was most interested in.This time, I did not manually provide the agent with the specific requests or explain the Base64 encoding technique.
Instead, I gave the agent the authorized target and asked it to investigate for an Open Redirect.
Then I let it work.
The agent was able to reach the vulnerability without being told about the Base64 encoding trick beforehand.
It also investigated whether the Open Redirect could potentially be combined with other weaknesses to create a higher-impact attack scenario.
For example, it considered whether the behavior could potentially be related to account takeover or SSRF.
In this particular case, I had already investigated those possibilities manually and did not find a higher-impact chain.
The vulnerability therefore remained a low-severity Open Redirect.
Still, the experiment demonstrated something useful:
The agent was able to reproduce the general discovery process without being given the exact technique I had used during my manual investigation.
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 demonstrated.
What I found more interesting is where AI agents can potentially save time.
A large part of web application security testing involves repetitive tasks such as:
- 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 problems 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 an application's business logic.
An experienced researcher may notice that two seemingly unrelated features interact in an unexpected way.
A vulnerability might depend on:
- A specific user role.
- A particular workflow.
- Multiple requests performed 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 a human's understanding of the application's architecture and business logic can still make a major difference.
AI Agents Can Act as Force Multipliers
For me, the most interesting result was not that an AI agent found a low-severity Open Redirect.The interesting part was the 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, validating findings, 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 security tools I already use and see what it could actually do.The combination of an AI model, an agent, security-focused skills, and Burp Suite turned out to be surprisingly capable.
It successfully identified a reflected XSS vulnerability in a deliberately vulnerable test environment and later discovered an Open Redirect on a real authorized bug bounty target without being given the exact technique I had used during my manual investigation.
The Open Redirect itself was ultimately low severity, and the agent did not discover a higher-impact chain.
But that was not really the point.
The experiment showed that AI agents can already be useful for automating repetitive parts of web security testing.
The real question is no longer simply: "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?"
Last edited: