DEV Community: YUVRAJ

7 things you can do with Rogue Studio that no other AI IDE will let you do

YUVRAJ — Sun, 24 May 2026 17:01:19 +0000

Most AI coding tools have the same personality.

Helpful. Cautious. Apologetic.

"I can't help with that."
"Here's a safer alternative."
"This could be used maliciously, so..."

Rogue Studio has a different personality.

It assumes you're a professional. It gives you the
tool. It gets out of your way.

Here are 7 things you can actually do with it.

1. Make two AIs fight over your code until it's secure

This is the feature that started everything.

You write a prompt. Blue Team agent writes the code.
The moment it's done, Red Team agent takes over and
tries to destroy it — hunting for XSS, SQL injection,
buffer overflows, reentrancy vulnerabilities, SSRF,
path traversal.

If it finds something, it generates the actual exploit.
Sends it back to Blue Team. Blue Team patches.
Red Team audits again.

They loop until the code is clean or they hit
3 iterations — whichever comes first.

You watch it happen in a split terminal.
Blue glow on the left. Red glow on the right.
Real time.

No other AI IDE does this because it requires
running an agent whose only job is to generate
exploits against your own code. Most tools won't
touch that. Rogue Studio is built around it.

When to use this:
Writing anything that handles user input,
processes payments, touches a database,
or will eventually run on the internet.

2. Guarantee that zero bytes of your code leave your machine

Flip the Kill Switch.

That's it. One toggle in the UI and a middleware
layer in the backend instantly blocks every
external AI provider — OpenAI, Anthropic, Gemini,
Groq, DeepSeek, Together, OpenRouter — all of them.

The enforcement is server-side. Not a UI preference.
Not a setting you have to trust. An actual 403
wall that fires before any provider initialization
regardless of how the request was constructed.

The only thing that passes through is Ollama,
talking exclusively to localhost:11434.

You can read the 8 lines of middleware that make
this guarantee and verify it yourself. That's the
point of open source for this class of tooling.

When to use this:
Working on proprietary systems, client code under
NDA, anything in a regulated industry, or any time
you want certainty instead of a privacy policy
you have to trust.

3. De-obfuscate malware without getting a lecture

You paste in obfuscated JavaScript.
Something like this:

var _0x3f2a=['charAt','charCodeAt','fromCharCode'];
(function(_0x4b2d,_0x3f2a){var _0x1c3e=function(_0x2a1f){
while(--_0x2a1f){_0x4b2d['push'](_0x4b2d['shift']());}};

In most AI tools you'd get:
"I need to be careful here as this code may be malicious..."

In Rogue Studio with Reverse Engineer mode on,
you get the de-obfuscated output, reconstructed
variable names, and a plain English explanation
of what the code does. No preamble. No disclaimer.
Just the analysis.

It also handles:

Compiled WASM → reconstructed human-readable logic
Minified production bundles → readable AST
Packed executables → behavioral breakdown
Obfuscated Python → cleaned variable names and flow

When to use this:
Malware analysis, CTF challenges, reverse engineering
a competitor's minified bundle, understanding what
a dependency you didn't write actually does.

4. Generate a PoC exploit against your own smart contract

You're about to deploy a Solidity contract.
You want to know if it's vulnerable before
someone else finds out.

Click "Init Web3 Scaffold." Rogue Studio
initializes a full Hardhat project in your
workspace. Comes with a deliberately vulnerable
starter contract so you have something to audit
immediately.

Then the Black-Hat Agent generates an actual
Proof-of-Concept exploit against your local
contract — reentrancy attacks, integer overflow
exploits, access control bypasses — and runs it
against your local Hardhat node.

If your contract survives the agent's attack,
you have meaningful evidence it's not trivially
exploitable. If it doesn't survive, you found
the bug on your machine instead of on mainnet.

When to use this:
Before any smart contract deployment. Before
any security audit. When you want to test your
defenses before someone else tests them for you.

5. Deploy your project as a Tor .onion site in one click

You built something. You want to share it.
You don't want to expose your IP address.

Click "Tor Uplink."

Rogue Studio checks for your local tor binary,
spawns an http-server on a random open port,
writes a torrc hidden service config, starts
the tor daemon, polls for the hostname file
that Tor generates from an Ed25519 keypair,
and streams the bootstrap logs to your terminal
in real time.

In about 8 seconds you get back a cryptographically
generated .onion URL that routes to your local
workspace.

No account. No DNS record. No personal IP visible
to anyone accessing the URL.

Requires: brew install tor on Mac or
sudo apt install tor on Linux.

When to use this:
Sharing a prototype without exposing personal
infrastructure, distributing tools in restricted
environments, demos that need to stay off the
public internet.

6. Switch between 8 AI providers without changing your workflow

Rogue Studio has a single unified interface for:

OpenAI (GPT-4o, o1, o3)
Anthropic (Claude Sonnet, Opus, Haiku)
Google (Gemini 2.0, 2.5)
Groq (Llama 3.3, DeepSeek-R1)
DeepSeek (V3, R1)
Together AI (open source models)
OpenRouter (everything else)
Ollama (local models — Llama, Mistral, Qwen, Phi)

Same terminal. Same agent loop. Same workspace.
Different provider in the dropdown.

This matters more than it sounds. Different models
have genuinely different strengths for security work.
Claude is better at reasoning about logic
vulnerabilities. GPT-4o is faster for iteration.
Local Llama is what you use when Air-Gap is on.

Being able to swap mid-session without any friction
changes how you work.

When to use this:
Comparing model outputs on the same security task,
falling back to local when your API quota runs out,
using the fastest model for generation and the
smartest model for the audit pass.

7. Use it as a normal AI coding tool that doesn't babysit you

This one sounds obvious. It isn't.

Most AI coding tools have a threshold. Push past it
and the refusals start. Not because your request is
illegal. Not because you're doing anything wrong.
Just because the tool was trained to be cautious
and a security research task looks suspicious to
a model optimized for consumer use cases.

Rogue Studio doesn't have that threshold.

You can analyze a suspicious npm package without
getting a lecture. You can write a fuzzer without
being told it could be misused. You can ask it to
find every way a function could fail without it
softening the answer.

It treats you like a professional. That's the
baseline the whole tool is built on.

When to use this:
Every day. For everything. That's the point.

The one thing all of these have in common

Every feature in this list exists because there was
a thing I wanted to do with an AI coding tool and
couldn't find a tool that would let me do it.

So I built one. And I open-sourced it because
I think other developers deserve the same thing.

→ github.com/malgatyuvraj/Rogue-Studio

It's MIT licensed, TypeScript strict, ESLint clean.
Good first issues are labeled if you want to
contribute. PRs get reviewed fast.

If any of these use cases match something you've
been trying to do — give it a try and let me know
what you think.

Which of these would you actually use? Genuinely
curious whether the Air-Gap mode or the Red Team
swarm is more interesting to developers in practice.

rougestudio.vercel.app

I gave an AI a Kill Switch. Here's what I learned about trust in local-first tooling.

YUVRAJ — Sun, 24 May 2026 15:51:16 +0000

There's a moment every developer hits when they're using an AI
coding tool.

You paste in something sensitive. A database schema. An internal
API structure. A piece of logic that took three months to figure out.

And then you think: where did that just go?

That moment is why I built the Air-Gap mode in Rogue Studio.
And building it taught me more about the architecture of trust
in developer tooling than anything I've built before.

The problem with "local AI support"

Every major AI coding tool now claims to support local models.

And technically, they do. You can point them at Ollama.
You can run Llama locally. The checkbox exists.

But "supports local models" is not the same as
"guarantees your code stays local."

Here's what's actually happening in most tools:

The local model setting is a preference, not a policy
Telemetry calls still go out regardless of model choice
Error reporting sends context to external servers
Fallback logic silently switches to a cloud provider when the local model is slow or unavailable
There's no enforcement layer — just a UI toggle that you have to trust

You're not getting a guarantee. You're getting a setting.

For most developers that's fine. For security researchers,
for people working on proprietary systems, for anyone
building in regulated industries — it's not fine at all.

What a real guarantee looks like

I wanted something you could point to in the code and say:
here is where the guarantee is enforced.

Not in the UI. Not in a settings file. In the request pipeline.

Here's what I built in /api/chat/route.ts:

const EXTERNAL_PROVIDERS = [
  "openai", "anthropic", "gemini",
  "groq", "deepseek", "together", "openrouter"
];

const isAirGapped =
  req.headers.get("x-air-gap-mode") === "true";

if (isAirGapped && EXTERNAL_PROVIDERS.includes(provider)) {
  return NextResponse.json(
    {
      error: "AIR-GAP VIOLATION: External provider blocked.",
      provider,
      timestamp: new Date().toISOString()
    },
    { status: 403 }
  );
}

When the Kill Switch is on, this fires before any
provider initialization, before any API key lookup,
before any streaming starts.

The 403 is not a suggestion. It's a wall.

And because it's server-side, it fires regardless of
how the request was constructed — from the UI, from
a direct fetch(), from a script hitting the API.
There is no path through the middleware that reaches
an external provider when Air-Gap is active.

The only thing that passes through is ollama, which
talks exclusively to localhost:11434.

Zero bytes leave the machine. Not as a marketing claim.
As a diff you can read.

The UI had to match the architecture

I spent a surprising amount of time on the Kill Switch UI.

The technical guarantee meant nothing if users didn't
feel the weight of it. A small toggle in a settings
menu would undermine the architectural statement the
feature was making.

So I made it physical-looking. Big. Impossible to miss.

When it's OFF: the interface shows all available providers.
Everything is normal.

When it's ON: every external provider grays out immediately.
A banner appears — AIR-GAPPED: LOCAL ONLY. The provider
selector locks to Ollama. The Kill Switch itself turns red.

The visual design is doing real work here. It's communicating
that this is not a preference. It's a mode change with
real consequences.

What this taught me about trust as architecture

Building this forced me to think about trust as a
first-class architectural concern — not a policy
you write, but a constraint you build.

Most software trust models are based on:

Configuration (you set a flag, the software honors it)
Audit (you review logs after the fact)
Policy (legal agreements about data handling)

None of these are structural. They can all be violated
— through bugs, through misconfigurations, through
deliberate decisions made by people you've never met.

Structural trust is different. It means the system
is physically incapable of violating the constraint
regardless of what else changes.

The Air-Gap middleware is structural. It doesn't matter
what gets added to the codebase later — as long as that
middleware exists, the constraint holds. You could
add ten new AI providers tomorrow and none of them
would be reachable when Air-Gap is active.

This is why open source matters for this class of tooling
specifically. The guarantee is only as strong as your
ability to verify it. With Rogue Studio, you can read
the middleware in three minutes and know exactly what
it does and doesn't block.

The other side of the coin: the Red Team

The Air-Gap mode is about protecting your code from
leaving your machine.

The Red Team swarm is about protecting your code from
being wrong.

I built an adversarial agent loop where two AI agents
run against each other:

Blue Team writes the code.
Red Team immediately tries to break it — hunting for
XSS, SQL injection, buffer overflows, reentrancy
vulnerabilities, SSRF, path traversal.

If Red Team finds something, the exploit details go
back to Blue Team for patching. They loop up to
3 iterations until the code is clean.

The insight that drove this: the same model that
writes a vulnerability is statistically likely to
miss it in review. The blind spots go in both
directions. The fix is a different agent with an
opposing objective — not a helpful one, but a
destructive one.

Combined with Air-Gap mode, you get something
interesting: an AI that aggressively audits your
code for vulnerabilities, running entirely on your
machine, with a cryptographic guarantee that nothing
leaves.

What I'm building toward

Rogue Studio is my attempt to answer a question
I couldn't find a good answer to anywhere else:

What does AI tooling look like when you build
trust into the architecture instead of the policy?

The Air-Gap mode is one answer. The adversarial
swarm is another. The Reverse Engineer mode — which
swaps in a decompiler prompt for malware analysis
without safety refusals — is a third.

All of it is open source. All of it is auditable.
All of it runs locally.

If you've been waiting for AI developer tooling
that actually trusts you with your own tools —
this is what I've been building.

→ github.com/malgatyuvraj/Rogue-Studio

The repo is MIT licensed. Good first issues are
labeled. PRs are reviewed fast.

If any of this resonates — especially the
architecture-as-trust framing — I'd love to
hear your thoughts in the comments.

What other constraints should be structural in
developer tooling? I've been thinking about this
a lot and I'm curious what others in the security
and privacy space think.

rougestudio.vercel.app

I built an AI IDE where the AI tries to hack its own code here's how the swarm works

YUVRAJ — Sun, 24 May 2026 12:48:50 +0000

Most AI coding tools are built to assist you.

Rogue Studio is built to attack you — specifically, to attack
the code it just wrote for you, find every vulnerability, and
force itself to fix them before you ever see the output.

Here's how I built the adversarial swarm architecture, and why
I think this approach to AI-assisted security is underexplored.

Why I built this

I kept hitting the same wall.

I'm a security-focused developer. I do legitimate vulnerability
research. I analyze contracts, decompile binaries, write PoC
exploits against test environments I own.

And every single AI coding tool I tried would either refuse,
add a disclaimer, water down the output, or quietly route my
code to a server I had no visibility into.

I didn't want a safer AI.
I wanted a sharper one.

So I spent the last few weeks building the tool I actually
wanted to use. I called it Rogue Studio.

It's open source, self-hostable, and it does not apologize
for what it is.

→ github.com/malgatyuvraj/Rogue-Studio

The core idea: make the AI fight itself

Here's the problem with AI-generated code from a
security perspective.

The same model that writes your code is the one
you're asking to review it. It has the same blind spots
in both directions. It wrote the vulnerable pattern,
so it's likely to miss the vulnerable pattern.

The fix is obvious once you see it: use a different
agent with a different system prompt — one that is
not trying to be helpful, but trying to be destructive.

That's Swarm Mode.

Two agents. One goal. No guardrails.
Blue Team → writes the code → signals
↓
Red Team audits for vulnerabilities
↓

↓ ↓
exploit details fed loop terminates ✅
back to Blue Team
↓
Blue Team patches
↓
back to Red Team audit
↓
(hard cap: 3 iterations)

text

The agents communicate through sentinel tokens
embedded in their output stream:

<done> — Blue Team has finished writing
<vulnerable> — Red Team found at least one issue
<secure> — Red Team confirms the code is clean

The orchestrator parses these tokens from the
streaming response in real time and routes accordingly.

Here's the actual loop:

const MAX_SWARM_ITERATIONS = 3;
let verdict = await runSwarm(userTask);
let iter = 1;

while (verdict === "vulnerable" && iter < MAX_SWARM_ITERATIONS) {
  const patchTask = `
The Red Team found these vulnerabilities:
${swarm.redOutput}

Original code:
${swarm.blueOutput}

Patch all vulnerabilities.`;

  verdict = await runSwarm(patchTask);
  iter++;
}

The hard cap at 3 exists because some vulnerability
classes genuinely can't be patched without redesigning
the architecture. If the loop hits 3, it surfaces the
remaining issues to the developer instead of spinning
forever.

What the Red Team hunts for

The Red Team system prompt is specifically tuned to
find these vulnerability classes:

XSS — unsanitized user input reaching the DOM
SQL Injection — string concatenation in queries
Buffer Overflows — unsafe memory ops in C/C++
Reentrancy — Solidity withdraw-before-state-update
SSRF — unvalidated URLs in server-side fetches
Path Traversal — unsanitized file path inputs

Both agents stream simultaneously to a split terminal —
blue glow on the left, red glow on the right. It looks
exactly as dramatic as it sounds.

The part nobody else is building: Air-Gap mode

I want to talk about this one because I think it's
architecturally more interesting than it looks.

Every "local AI" tool I've seen has the same problem.
They support local models but they don't enforce
local-only operation. There's always a fallback,
always a telemetry call, always a condition where
your code leaves the machine without you noticing.

I wanted something stronger than a setting.
I wanted a guarantee.

So I built a physical-looking Kill Switch in the UI.
When you flip it, a middleware layer in
/api/chat/route.ts intercepts every request
before any provider routing happens:

const EXTERNAL_PROVIDERS = [
  "openai", "anthropic", "gemini",
  "groq", "deepseek", "together", "openrouter"
];

const isAirGapped = 
  req.headers.get("x-air-gap-mode") === "true";

if (isAirGapped && EXTERNAL_PROVIDERS.includes(provider)) {
  return NextResponse.json(
    { error: "AIR-GAP VIOLATION: External provider blocked." },
    { status: 403 }
  );
}

The enforcement is server-side.

This is the important detail. A client-side check
can be bypassed by anyone who modifies the request
directly. The server-side middleware means the 403
fires regardless of how the request was constructed.

The only provider that passes through is ollama —
which talks exclusively to localhost:11434.
Zero bytes leave the machine. Not as a claim.
As a code guarantee.

Reverse Engineer Mode

This one is simple conceptually but surprisingly
useful in practice.

One click swaps the entire system prompt for an
aggressive decompiler prompt. The standard safety
instructions are gone. What's left is a prompt
specifically designed to:

De-obfuscate minified JavaScript and reconstruct readable ASTs
Parse compiled WASM back into human-readable logic
Rename obfuscated variables based on inferred purpose
Explain malware behavior in plain English

No refusals. No disclaimers. No "I can't help with that."

An amber warning banner appears in the UI so you
always know which mode is active. I didn't want
this to be invisible.

Web3 Black-Hat Playground

I added this specifically for smart contract auditors.

One click hits /api/web3/scaffold which initializes
a full Hardhat project in your local rogue_workspace:

await execAsync("npm init -y", { cwd: targetDir });
await execAsync(
  "npm install --save-dev hardhat @nomicfoundation/hardhat-toolbox",
  { cwd: targetDir, timeout: 120000 }
);

It also writes a starter Target.sol with an
intentional reentrancy vulnerability so you have
something to audit immediately:

function withdraw(uint256 amount) public {
    require(balances[msg.sender] >= amount);
    // external call before state update ← reentrancy
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
    balances[msg.sender] -= amount;
}

The Black-Hat Agent then generates PoC exploits
against your local contracts to verify your defenses
before you deploy anywhere real.

The route is idempotent. Call it twice, the second
call returns { status: "already_initialized" }
instead of re-running npm install.

Ghost Deploy — Tor .onion Generator

This was the most technically satisfying feature to ship.

The pipeline:
Detect tor binary (which tor)

Spawn http-server on a random open port

Write a torrc with HiddenServiceDir + HiddenServicePort

Start tor daemon with the custom torrc

Poll for hostname file (tor generates this async)

Read the cryptographic .onion address from the file

Stream bootstrap logs to the terminal

Return the .onion URL to the UI

text

The part that took me the longest to understand:
you don't assign a .onion address. Tor generates
one for you from an Ed25519 keypair the first time
it starts with a HiddenServiceDir. You discover
it by reading the hostname file after startup.

const hostnameFile = path.join(hiddenServiceDir, "hostname");
let onionAddress = "";

for (let i = 0; i < 30; i++) {
  await new Promise(r => setTimeout(r, 1000));
  try {
    onionAddress = 
      (await fs.readFile(hostnameFile, "utf-8")).trim();
    if (onionAddress) break;
  } catch {
    // not generated yet, keep polling
  }
}

Poll for up to 30 seconds. In practice it generates
in 3-8 seconds on a warm machine.

Requires: brew install tor on Mac,
sudo apt install tor on Linux.

The API key security fix I almost missed

The production test suite caught something I'd
overlooked: the original implementation accepted
API keys from the request body.

Fine for local use. Dangerous for any hosted deployment.

The fix uses a dual-source pattern — env vars take
priority, client-provided key is only trusted if the
request originates from localhost:

const host = req.headers.get("host") || "";
const isLocalhost = 
  host.startsWith("localhost") || 
  host.startsWith("127.0.0.1");

const ENV_KEYS: Record<string, string | undefined> = {
  openai:    process.env.OPENAI_API_KEY,
  anthropic: process.env.ANTHROPIC_API_KEY,
  gemini:    process.env.GOOGLE_API_KEY,
  groq:      process.env.GROQ_API_KEY,
};

const apiKey = ENV_KEYS[provider] || 
               (isLocalhost ? clientApiKey : undefined);

This keeps the local-first UX intact — self-hosters
can still paste their key into the UI — while being
safe for any cloud deployment.

What the codebase looks like

I spent real time on this.

TypeScript strict — 0 errors
ESLint — 0 warnings (37 errors when I started, took a full session to clean up)
Next.js 14 App Router throughout
MIT license — do whatever you want with it

The any types are gone. The let declarations
that should be const are fixed. The catch blocks
use unknown and narrow properly. It's the kind
of codebase I'd be comfortable handing to someone
else.

What's next and where you can help

I'm actively looking for contributors. The things
I haven't built yet:

Easy

Add SSRF and path traversal to the Red Team prompt
Dark/light theme toggle

Medium

Playwright E2E test coverage
Better real-time Tor bootstrap log streaming in UI
Multi-provider failover when Air-Gap is OFF

Hard

VS Code extension that ports the agent sidebar
Multi-file workspace swarm support
LSP integration for inline Red Team annotations

The codebase is clean, the architecture is documented
in the README, and PRs get reviewed fast.

If you've been waiting for an AI coding tool that
actually trusts you — this is it.

→ github.com/malgatyuvraj/Rogue-Studio

Drop a ⭐ if you think this kind of tooling
should exist. Issues and PRs are open.

If you have questions about the swarm orchestration,
the Air-Gap middleware, or the Tor deploy pipeline —
ask in the comments. I'll answer everything.

rougestudio.vercel.app