I built an Open Source web-security workflow with 15 agents

hctor.tech — Sat, 22 Aug 2026 13:36:32 +0000

Instead of producing one unexplained score, WebScan coordinates 15 defensive agents. Each one looks at a specific part of a web app's posture, then connects what it observed to a recommended change and a way to verify the fix.

The agents cover three broad areas:

•
Safer public delivery: transport, browser isolation, and visible session controls.

•
How the app protects people and data: authentication, authorization, input safety, client exposure, API and error behavior, and data privacy.

•
Security that stays maintainable: configuration hygiene, dependencies, supply chain, deployment, logging and recovery, plus storage and cryptography.

WebScan is for websites that you own or are explicitly authorized to review. A public URL is not permission, so the workflow includes an ownership acknowledgement and a domain-verification step before a review starts.

It is designed for defensive improvement and does not try to test credentials, bypass controls, or perform disruptive activity.

I am the author, and I would really value specific feedback:

1.
Does the 15-agent split make security work easier to prioritize?

2.
Which report detail helps you move from a finding to a real fix?

3.
How should a small project make its coverage and limitations easy to understand?

WebScan GitHub Repo

From repeated clicks to a reusable visual guide

hctor.tech — Sat, 22 Aug 2026 11:47:36 +0000

How I built ClickTrail to turn fragile browser instructions into local-first visual documentation.

1. The browser is where a lot of invisible work happens

I kept noticing the same small failure in different contexts.
A browser task was easy to explain while I was sitting next to someone, but it became fragile the moment I tried to hand it off in a chat message.

A list of steps lost context.
A folder of screenshots lost order.
A screen recording was often too long for someone
who only needed to complete one specific task.

The task itself was not always complicated. It could be setting up an account, following an internal support path, preparing a page, or showing a family member where to find a setting. The problem was that the author already knew the workflow.

The reader did not.
When one click was missing, or the interface looked
slightly different, the written explanation stopped being enough.

That is the problem I wanted to work on with ClickTrail: not browser automation, not a giant knowledge base, and not another cloud dashboard.
I wanted a focused way to turn a browser path into a visual guide that another person could open, follow, and share when appropriate.

I built ClickTrail as an Open Source, local-first Chrome extension. The scope is deliberately narrow:

1- Capture a workflow
2- Organize it into a visual guide
3- Create an output that can be reused.

1.1 Why a screenshot folder is not a guide

A screenshot is evidence that a screen existed.

It is not automatically an instruction. The reader still has to work out the order, understand why a particular moment matters, and decide what to do if their own screen is not identical.

Useful browser documentation needs a little more structure. It needs a sequence that matches the task.

It needs enough context to help a reader recognize where they are. And it needs an output that does not
create extra work for the person receiving it. That is the gap ClickTrail tries to make smaller.

1.2 What I am still trying to learn

ClickTrail is a small project, and I do not want to present it as a universal solution.
Clear writing, careful product design, and good support still matter.
A visual guide cannot fix a workflow that should be simpler in the first place.

What I am trying to learn is where visual browser guides offer the most value.

Which workflows do people explain repeatedly?

I built and maintain ClickTrail, so I am especially interested in feedback that is concrete enough to act on.
A real workflow that felt hard to explain is more useful than a generic compliment.

A privacy question that reveals unclear wording is more useful than a vague feature request.

If that problem sounds familiar, you can inspect the project on GitHub