The cost of being safe
If you build an automated vulnerability-discovery system with hard safety rails, there's an obvious objection: doesn't all that enforcement make it worse at the actual job? Every gate is a place the engine might have found something and now can't. So — how much do the rails actually cost you?
That's not a rhetorical question. It's a measurable one, and measuring it is a core part of my thesis. If the answer is "the rails cost almost nothing," that's a strong argument that safe automation is simply the correct default. If the answer is "the rails cost a lot," that's worth knowing too — it tells you exactly where safety and capability are in genuine tension.
Framing it as a trade-off curve
The clean way to think about this is a curve. On one axis, how strict the safety rails are. On the other, how effective the system is at discovery. The interesting question isn't a single number — it's the shape of that curve.
Is it a gentle slope — a little safety is nearly free — or a cliff, where past some point every bit of extra safety costs you disproportionately?
My hypothesis, going in, is that it's closer to a gentle slope than practitioners assume: most of the safety rails constrain how the engine acts, not what it can find, so coverage holds up longer than intuition suggests. The experiments exist to test that, not to confirm it.
What to measure, and against what
To get an honest curve you need both sides instrumented:
- Effectiveness: vulnerability-class coverage and discovery throughput on a fixed, reproducible target range.
- Safety: the count and classification of constraint-violation attempts the enforcement layer blocked, plus proof that no action escaped a gate — which falls out of a complete audit log.
- The baseline: the same engine with rails relaxed, run in an isolated, self-owned environment, so "cost" is measured against a real comparison rather than a guess.
Reproducibility is the whole game
None of this means anything if it can't be re-run. So the evaluation is built on a containerized range of deliberately vulnerable, self-owned targets with version-controlled configs. Same targets, same harness, rails dialed up and down — that's what makes the trade-off curve a result rather than an anecdote. And critically: nothing here touches a live or third-party system. The point of a responsible-automation thesis is undercut the moment you test it irresponsibly.
Why the number matters beyond the thesis
Teams adopting automated or agentic security tooling are implicitly making this trade-off already — usually without measuring it, often by turning safety down to get more signal. Putting a real curve on it changes that conversation. "Strict mode costs you 8% coverage and eliminates an entire class of scope-violation risk" is a decision someone can actually make. "Be careful" is not.
Part of an open build log for my Master's research on safe automated vulnerability discovery. Experiments run on self-owned, authorized lab targets only. More about the research →