DEV Community: Nachiket Roy

Building an AI-Powered Security TUI with Rust and MCP

Nachiket Roy — Wed, 19 Aug 2026 16:05:15 +0000

Picking up where I left off

In my midterm update, I introduced the two main parts I was working on for OWASP BLT: BLT-MCP, which connects AI models with the BLT API, and BLT-CLI, a Rust-based terminal interface for working with BLT.

At that point, most of the foundation was there, but some of the features were still being worked on. The triage workflow was still coming together, and the screenshot analysis feature was only an early experiment. Since then, both have come together quite a bit, so here is where the project is now.

What BLT-CLI can do now

The CLI has grown quite a bit since the midterm version. You can browse vulnerabilities, search and filter reports, view bounty hunts, check contributor rankings, inspect individual vulnerabilities, submit new reports, and use the AI features for analysis and screenshots.

There are also logs and health information available from the interface. Guest mode is available as well, so you can explore the application without having to configure everything first.
Here is a small demo of BLT-CLI running in guest mode -

How it works

There are currently two ways to use the CLI. In the basic mode, it talks directly to the BLT API.

When AI features are needed, it can use BLT-MCP, which sits between the CLI, the BLT API, and the AI models. This keeps the terminal interface focused on the actual user experience while the MCP server handles the connection between the different services.

AI-assisted triage

One of the main things I wanted to experiment with was using AI to help with triage. When looking at a vulnerability, the AI can analyze the available information and provide suggestions around severity, attack vectors, potential impact, duplicate risk, and other things worth considering.

The AI does not automatically change the vulnerability. It gives you an analysis that you can review and decide what to do with. I think this is an important distinction. AI can save time when doing repetitive analysis, but I did not want it making changes behind the scenes.

Submitting reports from the terminal

The report submission workflow is also now part of the CLI. You can fill in the usual information such as the title, URL, severity, bug type, description, and proof of concept.

The form can be filled out entirely from the terminal and submitted directly to BLT. So the workflow can now go from looking at a vulnerability, analyzing it, writing the report, and submitting it without having to constantly move between different applications.

From a screenshot to a report

This was probably the feature I was most interested in when I started working on the project. At the time of the midterm update, the vision part was still very experimental. Now it works as part of the normal workflow.

You can provide a screenshot and the vision model can analyze it and help fill in parts of a vulnerability report, including the title and reproduction steps.

What comes next

There is still plenty to improve. Some of them are better AI analysis, more reliable MCP tools, smoother TUI workflows, better error handling, and more functionality in the CLI.

I also want to keep experimenting with how AI can fit into security workflows without turning everything into an automatic black box. The current version is really just a starting point.

Wrapping up

This also concludes my summer term project. It was genuinely fun to spend the term building and testing new things, especially getting to work with Rust, MCP, AI models, and the terminal UI together.

Not everything worked on the first try, and there were plenty of things I had to rethink along the way, but that was probably one of the best parts of the project. I got to experiment with different ideas and see what actually made sense once everything was put together.

There is still a lot that can be improved, but I am happy with where the project ended up compared to where it started.

Try it out

The project is still evolving, so there are definitely some rough edges.

BLT-CLI and BLT-MCP will be published soon, and once they are available, you will be able to try them out yourself. If you find something that does not work or have an idea for improving the workflow, feel free to open an issue or merge request.

The project is still being built, and feedback from people actually using it is probably the most useful thing it can get.

Thank you for reading and following along!!

Connecting AI and Security with BLT-MCP

Nachiket Roy — Mon, 06 Jul 2026 21:25:45 +0000

This summer i was given the opportunity to work on my BLT-MCP project with OWASP-BLT. Over the last few months, I've been working on transforming how users interact with BLT. Now it marks the midpoint of the project, and there's been some interesting development i would like to share.

What is MCP?
MCP (Model Context Protocol) is an emerging open standard that helps AI models securely interact with local tools and remote data sources. By building an MCP server for OWASP BLT, we're essentially teaching AI assistants (like Claude, Cursor) how to natively speak with BLT directly. Your AI can read issue context, browse repositories, and submit vulnerabilities, without ever leaving your IDE.

The Two Pillars So Far

The MCP Server
Written in Python, the server acts as the translation layer between LLMs and the BLT API. It exposes two main capabilities to the AI:
- Resources (blt:// URIs) - the AI can fetch live data exactly when it needs context. For example, reading blt://issues/123 to get the details of a specific vulnerability.
- Tools - actionable endpoints that let the AI do things, like submit_issue and add_comment.
The BLT-CLI (Rust Terminal UI)

While IDE integration is great, sometimes you just want a fast terminal experience. I built BLT-CLI in Rust using ratatui a Terminal UI (TUI) that connects directly to the MCP server and the BLT API. Triage logic is being built alongside it, so you can browse, review, and act on issues right from the terminal.

What's Next
The core logic and terminal are built. For the remaining sprint, I'll be focused on testing everything end-to-end, polishing the rough edges, and starting work on a vision pipeline that can turn a dropped screenshot into a drafted vulnerability report, which is still early and in progress.
Thanks for following along!

My Journey Into Open Source and My First Big PR

Nachiket Roy — Tue, 03 Mar 2026 07:18:27 +0000

I heard about open source around a year ago, and honestly, I didn’t jump in out of excitement - it was pure curiosity. I just wanted to see how things worked behind the scenes. So I started exploring the good-first-issue label on GitHub, picked some random repos, forked them, committed a few changes, and slowly figured out the whole contribution workflow.
Back then, I also knew about GSoC - Google Summer of Code - but only at a surface level. To me, it was simply “contribute → get selected.” I had no idea how big real-world codebases could be or how overwhelming they might feel.

Finding My Direction: OWASP

While browsing blogs about how to get started, almost everyone suggested reading previous years’ GSoC write-ups. So I did. And while reading those posts, one organization suddenly stood out: OWASP.

The reason was simple - I already knew about the OWASP Top 10. Out of hundreds of unfamiliar organizations, OWASP felt like a place where I at least understood the purpose.

As I explored further, projects like NEST, CRE, and BLT started popping up. I leaned toward NEST at first because I’m more comfortable with TypeScript. BLT looked really interesting, but I had zero experience with Django or Python.

And then came the twist.

The Blog That Changed Everything

I found a GSoC blog written by a contributor. They had built four security labs for the BLT project and the write-up was so friendly that it gave me confidence:

“I may not know the stack, but I can surely replicate this and extend it.”

That belief was strong enough for me to try. Plus, I knew I could use AI tools to understand things. How hard could it be?

Well… harder than I expected.

My First PR: The Reality Check

I replicated the labs, joined the Slack workspace, got confirmation, and made my PR in October:

Added Labs: Under Security Labs Added More Labs #4628

Nachiket-Roy posted on Oct 14, 2025

Added more labs in security labs section closes #4784

To seed labs and their tasks simply run : python manage.py seed_all_security_lab

Summary by CodeRabbit

Refactor
- Restructured task detail page into clear, per-lab sections for payload exercises (SQLi, XSS, CSRF, Command Injection, Broken Auth, IDOR, File Upload, Sensitive Data Exposure, Open Redirect, SSRF)
- Unified and simplified MCQ and simulation submission flows and result display with consistent styling driven by correctness
- Minor formatting and structural template cleanups
Chores
- Added a management command to seed the six security labs and their tasks for testing/dev environments

View on GitHub

The moment I asked for a review, reality hit.
Replication wasn’t as simple as copy → paste → commit.

I had:

added irrelevant files
failed pre-commit checks
triggered Sentry and CodeRabbit warnings I didn’t even understand
and generally made every beginner mistake possible

After a lot (and I mean a lot) of back-and-forth, and with patient help from the maintainer - Donnie, I finally cleared everything. One month later, the PR was merged. And that changed everything for me.

From Zero Momentum to Light Speed

Once that first PR got merged, it was a massive boost.

I started reading issues, picking tasks, opening PRs, getting reviews, fixing things, and before I knew it, I had multiple PRs merged in the same month. The slow start turned into full-speed progress.

We were also encouraged to review others’ PRs. I didn’t really know how to do that, so I watched how other contributors reviewed code and followed their patterns. Tools like CodeRabbit and Sentry helped; they taught me how to reason about code warnings.

I also started recognizing common patterns in the backend:

N+1 query problems
cache stampede issues
repeated logic patterns
places where optimizations were needed

I wasn’t an expert, but I was learning how to spot things. I used Copilot and CodeRabbit to understand unfamiliar parts of the repo and slowly built a mental map of its workflow.

Where I Am Now

From that first confused PR to today, the journey has been wild.
I now:

understand the repo’s structure
can navigate issues, commits, and workflows confidently
know how reviews function
contribute regularly
and feel genuinely connected to the project

What started as a random attempt to explore open source turned into something meaningful that i want to continue growing in.