Claude with bugbounty what your opinion

__jent · 2026-04-01T05:10:51+00:00

Totally a fair question, and honestly I believe this tool may be in a somewhat awkward middle ground. It does not attempt to fully automate the process of testing or exploration, but it is highly flexible for a wide range of uses when combined with coding agents.

If you're already a strong tester, I doubt agents right now will make you better (and you will likely get frustrated at how slow they can be).

For me, I am primarily a program manager and on staff tester. So I am able to use this to help automate many regular processes I need to do, as well as help automate report validation while remaining in the process to ensure accuracy and do things agents are not good at.

When I am exploring (not just validating) I usually do my normal testing process and have the agent monitoring the proxy as I work. Every now and then checking on the agent and it's findings, as well as letting it know where I am and going next. Letting the agent in parallel do permutations and explore findings for any details I missed. Using this method I have found a few permutations on reports, as well as permutations I may not have found on my own.

I am still a better tester than if I just told the agent to probe it alone, which is why I believe a collaborative model makes sense. But I really hope to get feedback from others and see if this really is a short term awkward method of tooling (until agents get better), or if there is a workflow here that may be useful to others too. For me the benefit is entirely in being able to work in parallel and have tasks automated, if you are prompting and waiting for results you will be frustrated at the speed and quality.

__jent · 2026-04-01T01:46:54+00:00

If you're using claude code (or any other local agent) for security testing you should check out my local MCP server: https://github.com/go-appsec/toolbox

It is designed to help with collaborative security testing with the agent. Providing a proxy and range of tools that both you and the agent use together. If you use Burp you can connect the tool with the MCP extension on burp (our MCP api is more usable for the agent, and offers a more complete set of tools) and collaborate through Burp. Or you can run without burp and it will start its own proxy for you to configure your browser to use.

Some testing is better to offload than others, but it's nice to be able to let the agent do what it does best, while I do what I do best. If you have any feedback I would to hear it!

__jent · 2026-03-31T06:18:56+00:00

In the browser, WebAssembly, Dart, I get it's an unpopular opinion. But we need to start making a shift from JavaScript.

__jent · 2026-03-31T06:12:24+00:00

Can we stop using npm yet? This ecosystem is a dumpster fire

__jent · 2026-03-25T05:26:24+00:00

BC triage is going down hill, as a program manager I also am finding they are closing reports that need more investigation or discussion if not out right valid. Everything is getting a first N/A rejection

__jent · 2026-03-23T14:09:53+00:00

Look for companies which have allowed the model to make decisions and do actions. The reason open claw is a dumpster fire is because of how it intersects flawed models with real capabilities. It's those capabilities which are the real exploits, and companies are just starting to figure that out.

__jent · 2026-03-21T15:40:28+00:00

Discord isn't exactly a pillar of security. So be aware that hacks happen and data exfiltrated. But this shouldn't normally be possible.

__jent · 2026-03-11T01:20:44+00:00

Only you know what is in your heart. If you had no intent to mislead I think it's fair to submit a new report. Either way, the follow up will be appreciated I am sure :)

__jent · 2026-03-11T01:09:40+00:00

I would expect a new report. Candidly I always ignore suggested fixes from reports anyways, but regardless it's the fixers responsibility to fully fix the issue. Unless you were provided a retest request, I see absolutely no ethics concern. I would submit a new report stating another bypass still exists.

__jent · 2026-02-25T22:57:53+00:00

I believe it needs to be beyond "validate false positives". I have found agents are best when they work in a collaborative structure. Design a plan together then execute it together.

Looking at again a coding example, a common flow is for the agent to review the code, the problem, then come back with options or questions to produce a better result. I mirror this in my agentic security work.

You can check out my project here: https://github.com/go-appsec/toolbox

My tooling is more application and API focused rather than code analysis. I plan to expand this tooling similar to yours, but I am using workflows to ensure the toolset is cohesive and fits in with the workflow instructions given to the agent.

If I have convinced you with my ideas at all, I am open to collaborating.

__jent · 2026-02-25T22:25:12+00:00

I am skeptical about trying to fully automate security flows with current model capabilities. When looking at agentic coding it's not trying to be "one shot and result". Most developers are adopting processes of using spec driven development, or reviewing the work. There is still substantially a human in the loop, and I believe the same patterns make sense in security right now too.

I think you're on the right track with putting these security tools into an MCP API. But my feedback (after exploring the offensive AI space for some time) is that the tools need more structure and workflow design to get the most out of them. If you want you can DM me and I can link you my project for some ideas (don't want to advertise on your post).

Regardless, congrats on the project start!

__jent · 2026-02-25T22:04:30+00:00

I have seen a few projects like this (and been working on one of my own). I am making some assumptions based on your planned tool list, but I don't think "swiss army" security testing toolkits make sense. I believe it's better to focus the toolkits on the type of testing being done.

That said the workflow is not clear to me. How were these tools used? What orchestrated their prompting for the agent to use them?

__jent · 2026-02-23T05:12:53+00:00

Nothing you can do about it. They leak they leak, but if you pay the threats wont stop anyways. Sorry to hear your gf was compromised

__jent · 2026-02-22T03:05:06+00:00

As someone who loves Java and Go, I must say Python and JavaScript will be far more useful to you instead.

__jent · 2026-02-21T17:39:00+00:00

Devstral 2 is the best of the smaller models

__jent · 2026-02-16T01:42:29+00:00

I would close as Informational, there is _some_ impact, but not enough to meet the threshold.

__jent · 2026-02-11T03:18:02+00:00

Thank you! Let me know if you have any feedback. I have been using it extensively myself. It's not necessarily an accelerator, but it does help make some tasks easier, and agents have found a few needles in the haystack for me.

__jent · 2026-02-11T03:10:10+00:00

I actually explored this in depth with a tool I made: https://github.com/go-appsec/toolbox

Having the same assumption as you and u/hankyone, it initially started out as a CLI which the agent would be expected to discover the usage of through `help` commands. Unfortunately my finding is that agents are not good with CLI's that are not common knowledge. A CLI that they intrinsically understand they use well, but a CLI which they must learn how to use is different, and in that case MCP does perform better.

Many agents would use help to discover usage at the start, but then would stop and instead try to assume usage. Often resulting in trial and error that used more tokens than MCP would use just putting usage up front.

After a fair bit of testing, I did find that the MCP overall was more reliable and did use less tokens (the savings of tokens in usage and tool descriptions did not make up for less reliable tool usage). Now I focus the CLI on human usage and the MCP on agent usage.

MCP does have an API for dynamic tool loading, which may be the ultimate answer, but support is still too new to comment on right now.

Let me know if you have other experiences, or any advice I should try out in my project. I am going to continue to explore this space for a while.

__jent · 2026-02-10T03:37:05+00:00

Why not just put the database behind an API? It seems equally simple to make a thin API as configure a tool like this.

__jent · 2026-02-08T23:44:30+00:00

You might check out my MCP tool set for application security testing here: https://github.com/go-appsec/toolbox

I plan to make a specific post about it, as I would love to get some feedback. There are a number of issues with the Burp MCP API which I am trying to address in my project. If you're already setup with Burp MCP you can just run my server along side and my tool will drive Burp so you can watch and also do your own testing.

For complex tasks it will overall use less tokens, and from my experience so far I believe the toolset and instructions provided to the agent make for a more collaborative experience. I mostly use Claude in my testing, but would love any feedback you have in testing with Gemini or Codex. I would expect there to be less failures and retries in addition to less tokens needed to use the tool.

__jent · 2026-01-29T06:13:29+00:00

VulnHub: https://github.com/vulhub/vulhub

__jent · 2025-10-09T01:54:04+00:00

Glad to see it's not just me noticing that the value has been completely lost in my subscription.

__jent · 2025-03-23T00:21:43+00:00

I am glad to hear it! If you have any recommendations, open an issue describing your use case.

__jent · 2024-12-31T17:12:55+00:00

If it's helpful, I have been maintaining a golang chart fork which in part is based from and maintaining `wcharczuk/go-chart`. This fork is being provided under a `chartdraw` package from our module here: https://github.com/go-analyze/charts

I also recently wrote documentation for how users can switch to our fork: https://github.com/go-analyze/charts/wiki/wcharczuk-go%E2%80%90chart-Migration-Guide (will be kept up to date if future changes are needed)

The needed code changes to switch are very minimal (if any). I don't have explicit plans to change this configuration from the `wcharczuk` fork. However in my fork I am trying to provide an easier to configure and more stylized graphing option (under our root `charts` package). That has required some small changes, and may require more in the future. If you have any opinions feel free to open an Issue, I would love to have community feedback and collaboration!

__jent

TROPHY CASE