MontNoir
An automated pentest a human can actually defend.
- Product
- AI penetration testing platform
- Model
- Fixed price, $1,000 per audit
- Output
- Professional PDF audit with reproduction steps
- My role
- Product design, UX, interface system
Context
MontNoir sells a security audit, not a security tool. A business hands over the target, and an in-house agent runs the whole penetration test end to end - no manual work on the customer's side, no checklist to configure, no algorithm to tune. The engine is under the hood and stays there.
Automation is the product, and automation is the objection
Security buyers are trained to distrust automated findings, and they are right to be. A scanner that reports a critical vulnerability that turns out to be noise costs more than it saves, because someone senior has to spend a day disproving it.
An AI agent makes that worse before it makes it better. The moment a customer suspects the finding was generated rather than found, the whole report becomes unusable - not because it is wrong, but because it cannot be defended to anyone else.
So the design problem is not making automation look impressive. It is making automation auditable by a person who did not run it.
Show the work, then show the finding
Every finding carries its evidence and a reverse-engineering guide: the exact steps to reproduce it by hand. That single decision reframes the product. The agent stops being an oracle to be believed and becomes a colleague who shows their working, and a customer can verify any claim without asking MontNoir for anything.
The run itself is visible while it happens. A live session log shows what the agent is doing, what it has checked, what it needs, and where it is spending the budget. Automation that hides its process reads as a black box; automation that narrates it reads as competence.
The topology view carries the same intent. Hosts, services, endpoints and credentials are drawn as a graph with the attack path traced across it, so a finding has a place in a system rather than existing as a line in a list.
The interface stays deliberately calm. Dark, low-saturation, with colour reserved for severity. Security products often use alarm as a substitute for confidence; a product charging a flat fee for a finished audit cannot afford to look anxious.
My approach
Design for the sceptic, not the buyer
Assume every finding will be challenged by an engineer who was not in the room, and give them what they need to check it themselves.
Attach reproduction to the claim
Pair each finding with evidence and manual reproduction steps, so nothing in the report rests on trusting the model.
Narrate the run
Expose the live session: current activity, findings so far, budget used and time elapsed, so an automated audit still feels accountable.
Put findings in a system
Draw the target as a graph and trace the attack path across it, so severity is understood in context rather than in isolation.
Design the deliverable, not just the app
Treat the exported PDF as a first-class surface, because that is the artefact the customer forwards to people who never open the product.
An automated audit a human can defend
The product covers the whole job - target in, professional audit out - without asking the customer to do security work. What makes it sellable is not the automation but the fact that every line of the output can be independently reproduced.
The flat price only works if the report lands finished. That put the PDF at the centre of the design rather than at the end of it, and it set the standard for everything on screen: if it would not survive being forwarded to a CTO, it was not done.
Designing an AI product turned out to be the same discipline I apply to AI as a tool, which is the subject of AI speeds up the hands. Trust itself was never the design target - the reproducible behaviour underneath it was, and that habit is the argument in designing for outcomes, not screens. Axis is the other tool here built for people who have to rely on it while they work.
- Every finding ships with evidence and manual reproduction steps
- Live session log keeps an automated run accountable while it works
- Attack path drawn as a graph, so severity has context
- The exported audit designed as a deliverable, not an afterthought
Reflection
The hard part of an AI product in security is not capability, it is admissibility. Designing so that a stranger can disprove any claim we make turned out to be the thing that made the claims worth paying for.