DEV Community: Intelliflame

We ran an AI agent against our own dependency tree. It found a PII leak in 10 minutes. Then it stopped. Here's why.

Intelliflame — Fri, 30 Oct 2026 03:30:47 +0000

Last week we pointed BugTraceAI — our open-source agentic security scanner — at our own infrastructure, the way we ask every user to do before they point it anywhere else.

Ten minutes in, it surfaced something real: a self-hosted Wallos instance (open-source subscription tracker) exposing subscriber PII through an unauthenticated endpoint. Validated. Reproducible. The kind of find that makes the whole pipeline feel worth building.

Then the agent did something we're actually proud of: it stopped.

The stop, and why it matters

The natural next step for that finding would have been to test whether the PII disclosure chains into something bigger — an RCE, an account takeover, whatever lives down that road. A less constrained agent would have gone there. Ours didn't, because its charter said: validate the finding, then hand it to a human.

That's not a limitation we grudgingly accept. It's the product. An agent that decides for itself how far to push into someone else's system isn't a security tool — it's an liability with a nice CLI. The line between "verified finding" and "exploitation attempt" is a human decision, and we built BugTraceAI so the human makes it.

We disclosed the standalone PII issue to the maintainer (CVE-2026-2747 was assigned to a related finding in the same project). We did not chase the chain.

The uncomfortable question this leaves

Here's what keeps circling in my head since:

When an agent finds 90% of a vulnerability chain and a human completes the last 10%, that's clearly the human's judgment. But when the agent could have found the last 10% and didn't because of a charter — is the resulting report weaker? Would a client rather have the full chain, knowing it came from an agent that had permission to go there? And if so, what does a "permission to go there" charter even look like that isn't just "unleash the thing"?

Every vendor in this space is quietly making this trade-off — capability vs. containment — and most of them aren't saying out loud where they drew the line. We just drew ours in public: validate, don't exploit; hand off, don't escalate.

Your turn

So, people who run agents against real targets — where's your line?

Does your agent stop at validation, or does it chase chains within an authorized scope?
Have you ever had an agent find something that made you glad it was constrained?
And honestly: has a charter ever cost you a finding you needed?

We've been debating internally whether "validate-only" is a principled default or just liability management dressed up as ethics. Still not sure we've settled it. Comments open — genuinely want to know where other teams land.

BugTraceAI is open source (AGPL) — the charter, the pipeline and the stop-mechanism are all in the repo. Disagree with our line? That's what the issue tracker is for.

Evidence-first security testing: why we refuse to ship unverified scanner output

Intelliflame — Wed, 21 Oct 2026 06:31:25 +0000

Scanners are wonderful at finding candidates and terrible at finding truth. Every tool in this space — including our own BugTraceAI — produces output that looks like findings and sometimes isn’t.

Our rule is simple: nothing enters a report until a human has reproduced it and captured evidence. Three reasons, learned from shipping this platform:

1. False positives cost more than missed findings. A reported-but-wrong finding burns the client’s trust and their engineer’s afternoon. A finding we catch manually next week costs one sprint. Asymmetric — so we bias hard toward verification.

2. Severity is a business judgement, not a calculator. CVSS gives a number; it cannot know that the “critical” SSRF is unreachable in your network topology. Human context decides ranking, and the report says why.

3. The report is the product. If we ship unverified output, we’ve shipped a scan, not an assessment.

We practice what we preach: automated breadth (crawling, fuzzing, CVE matching) covers the full URL tree, then manual expert testing confirms every finding with step-by-step reproduction and HTTP evidence before it ships. Roughly 60% of engagement hours are manual.

If you’re building security tooling, we argue about this exact stuff in our community forums — disagreement welcome.

Repo: https://github.com/BugTraceAI/BugTraceAI

appsec #cybersecurity #infosec

We opened our issue tracker to conversation: BugTraceAI community forums are live

Intelliflame — Wed, 21 Oct 2026 06:29:07 +0000

Two weeks ago we wrote Meet BugTraceAI — an open-source, self-hosted agentic pentester. The star count since then (365 at this moment) tells us people are watching. What we want now is conversation.

So we've enabled GitHub Discussions on the main repository, organised into three rooms:

Feature Requests — tell us what the platform should do next. Nine threads are already open, from Nuclei integration to scheduled scans.
Roadmap — weigh in on what we're building before we build it. Two live design questions: autonomous authentication/session handling, and an AI-powered HTTP repeater.
General — secure defaults, deployment hardening, agent safety, anything else. The thread we most want answered: suggested secure defaults for local installs.

Why discussions instead of just issues? Issues are for bugs; discussions are for disagreements. A pentest tool embodies opinions — what to scan first, what counts as evidence, how much autonomy an agent should have — and opinions improve when people argue with them. We would rather hear "your default is wrong" in week one than discover it in a post-mortem.

Where to start if you have five minutes: AI report generation (what should an agent-written pentest report actually contain?), local LLM integration (air-gapped environments), or the API provider ecosystem proposal.

Every serious idea gets a response — usually within a day.

Repo: https://github.com/BugTraceAI/BugTraceAI

appsec #cybersecurity #opensource #ai

From zero to first scan: installing BugTraceAI in about 10 minutes

Intelliflame — Mon, 12 Oct 2026 05:06:19 +0000

Second in the BugTraceAI series — the first post covered what it is and why "agentic" matters. This one is the hands-on part.

Getting BugTraceAI running takes roughly ten minutes: one install command, a short interactive menu and a model API key. No security expertise needed to get it going — finding things is the tool's job.

Screenshots are from an earlier Launcher build — the flow is the same; some labels and version numbers differ slightly in the current release.

What you need

A Linux machine or VM (or WSL on Windows). The standalone terminal profile needs Python 3.10+; full-platform deployments also use Docker (Docker Engine, Compose and Git).
An LLM provider API key — e.g. OpenRouter, Anthropic or Z.ai. Analysis runs with your own key.
Ten minutes and a target you're allowed to test. No target yet? Use BugStore, our intentionally vulnerable practice app.

Step 1 — One command

curl -fsSL https://raw.githubusercontent.com/BugTraceAI/BugTraceAI-Launcher/main/install.sh | bash

The script pulls down the Launcher — the guided installer for the whole ecosystem. Prefer to read before you run? Clone it and start it yourself:

git clone https://github.com/BugTraceAI/BugTraceAI-Launcher.git ~/bugtraceai-launcher
~/bugtraceai-launcher/launcher.sh

On Windows, run this from Git Bash or WSL — PowerShell has no bash.

Step 2 — Pick what to install

The Launcher opens an interactive terminal menu. It checks your environment first (Docker, Compose, Git, curl, RAM and disk — each reported explicitly), then asks which product combination to install:

Profile	What gets installed	Runtime
`terminal`	CLI terminal workspace (TUI)	Local Python or Docker
`web`	WEB dashboard, with either or both scanning engines	Docker
`full`	WEB + both scanning engines + CLI TUI	Docker
`server`	CLI web-scanning API/MCP	Local Python or Docker
`terminal-server`	CLI TUI + web-scanning API/MCP, no WEB	Local Python or Docker
`api`	BugTraceAI-API target engine, REST + MCP	Docker

For a first look, full shows the complete picture; for the lightest start, choose terminal.

Step 3 — Wizard or AI setup

Next, choose how to run the installation:

Install with Wizard — manual, step-by-step choices. Supports every module combination.
Install with AI — the AI Setup & Repair Assistant. Currently supports API-only or the full WEB + CLI + API selection, with OpenRouter or Anthropic.

You'll enter and verify your provider API key during this flow, and the final review shows the selected modules, runtime and ports before anything is written to disk.

Step 4 — Confirm the stack is up

When the install finishes, all services run locally in Docker — check them with:

docker ps

Five containers, all healthy — and nothing leaves your machine.

Step 5 — Open the console and connect your model key

Open the web console — the default is http://localhost:6869, and the installer prints the exact URL for your setup:

Then go to Settings, add your LLM provider key and hit Test API Connection. Green means you're ready to save and scan:

Step 6 — First scan

Point it at your target — or at BugStore, the practice shop we built for exactly this:

Watch the six phases run: Recon → Discovery → Strategy → Exploit → Validate → Report. When it's done, export the report as Markdown or JSON, and open any finding to see its evidence chain — requests, code snippets and traces. That's the part that matters: you verify before you file.

Common questions

Port already in use? The wizard detects it and offers alternatives — you can also type a custom port (1024–65535). An occupied port is never silently replaced.
No API key yet? Any supported provider works (OpenRouter, Anthropic, Z.ai, …). Keys are pay-as-you-go, and they stay in your deployment.
Where do reports and scans live? In your own infrastructure. BugTraceAI is self-hosted: scan data and evidence never leave your machine, and analysis runs with your own provider key.

Honest notes

All components are in beta — expect rough edges; report anything odd via GitHub Issues.
Launcher 3.3.26 passed focused installer tests on clean Linux VMs; macOS and ARM runtime validation is not included yet.
Verify findings before you file them. AI output is a lead, not a verdict — that is exactly why the pipeline validates every finding.

Where to go next

Docs: the project Wiki — Getting Started, Architecture and component guides
Community: Discord · GitHub Issues
Not ready to install? Explore the live demo or grab the demo report
If this saves you time: a star on GitHub genuinely helps an open-source security project get discovered

BugTraceAI is built for authorized security testing only — only test applications you have explicit written permission to test.

Meet BugTraceAI: an open-source, self-hosted agentic pentester

Intelliflame — Wed, 07 Oct 2026 03:33:36 +0000

Every security team knows the pattern: you want a proper assessment of an app, but the options are waiting weeks for a consultancy slot, or stitching together a dozen tools and babysitting them for days. Bug bounty hunters know a variant of the same problem — the toolchain is powerful but fragmented, and every judgement call is on you.

We are building a third option. BugTraceAI is an open-source, self-hosted framework for authorized bug bounty and penetration testing. It runs an autonomous agentic pipeline: AI agents plan and prioritize the work, specialist tools and browser validation collect the evidence, and every finding comes out with something you can verify before you file it.

Why "agentic" matters here

Plenty of scanners already automate checks. The gap BugTraceAI aims at is the layer above: deciding what to test, in what order, and what to do with ambiguous signals.

In BugTraceAI, agents drive a six-phase pipeline:

Recon — crawl the target and discover endpoints
Discovery — analyze URLs and collect initial findings
Strategy — consolidate findings and route work to specialists
Exploit — run specialist checks and collect evidence
Validate — verify findings before they reach the report
Report — generate structured, human-readable deliverables

The AI reasons and prioritizes; deterministic security tools (including Go fuzzers and browser-based validation via Playwright) adjudicate. The design principle in one line: AI output is a hypothesis — evidence makes it a finding.

Four components, one ecosystem

BugTraceAI-CLI — the autonomous scanner: terminal workspace (TUI), REST API and MCP, multi-agent pipeline with specialist tools
BugTraceAI-WEB — browser dashboard with 20+ AI security tools, real-time scan monitoring and a CLI control center
BugTraceAI-API — evidence-first API security testing service over REST and MCP
BugTraceAI-Launcher — guided deployment: Wizard or AI-assisted setup, local or Docker runtime

Plus BugStore — a deliberately vulnerable practice shop with 32 planted OWASP vulnerabilities, so you can try the whole workflow legally.

Everything is self-hosted and Apache-2.0 licensed. Scans, reports and evidence stay on your infrastructure, and analysis runs with your own LLM provider key.

Does it actually find things?

Three CVEs disclosed so far, found with BugTraceAI:

Product	CVE	CVSS
Wallos	CVE-2026-27479	7.7 High
ZoneMinder	CVE-2026-27470	8.8 High
Piwigo	CVE-2026-27834	7.2 High

The project was presented on stage at DEF CON 34 (Las Vegas), RootedCON 2026 (Madrid) and HKOSCon 2026 (Hong Kong). Component versions are currently in beta — treat outputs as leads to verify, not verdicts. (That is the point of the evidence-first design.)

Try it

Live demo (a real scan): demo.bugtraceai.com
Self-host in minutes: one-command Launcher install — see the Quick Start in the GitHub README
Practice target: BugStore
Code: github.com/BugTraceAI — if this is useful, a star helps other security folks find it

BugTraceAI is built for authorized security testing only. Only test applications you have explicit written permission to test.