Quox hardens Quox

The fastest way to find out whether a tool works is to use it on yourself. So we did.

Quox has a security testing capability: a set of governed agents that run reconnaissance and scanning against a target, record what they find, and check each finding before anyone acts on it. It is early. It is phase one. But the core loop is real, and the honest test of a security tool is simple. Does it find something you did not already know about your own systems.

There was one rule the engine could not break. It can only touch a target it has proven it is allowed to touch.

The rule: prove you are allowed

Our environment runs real hosts, ours and our customers'. A scanner loose on that network with no boundary is not a security tool. It is an incident waiting to be written up.

So the engine does not take a target on trust. Before it runs anything, it checks four things in order: is this target in scope for this engagement, has control of it been verified, is the requested action under the risk ceiling set for the job, and is it inside the allowed time window. Any answer of no, and nothing runs. No command is even built.

For this test, the target was a fresh virtual machine running a complete, isolated copy of the Quox stack, with no real data and no production access. Control of it was verified through the fleet, not assumed. Everything the engine did from there is on the record.

What it found

The engine ran DNS resolution, TLS inspection, HTTP probing and template-based vulnerability scanning. Twenty-three findings came back. Most were informational. One was not, and it was ours.

The dashboard was serving none of its HTTP security headers to the browser. No content security policy, no strict transport security, no clickjacking protection, nothing. Not on the actual application pages.

The cause is a well-known nginx trap, and we had walked straight into it. The security headers were defined, correctly, at the server level. But nginx does not inherit add_header directives into a location block that declares its own headers. The block that serves the application also set a cache-control header, and that single line silently dropped every security header for the pages that mattered.

The config read as correct. The headers were there in the file. They just never reached the browser.

It argued with itself

A scanner that reports everything it sees is noise. One of the twenty-three findings was a false alarm. A scanner template decided a plain health-check endpoint was a particular AI product, on the strength of a generic ok response that happened to match its fingerprint.

In the engine, finding something and confirming it are two different jobs, done by two different agents. The agent that reports a finding cannot clear it. A separate verifier has to confirm or refute, and it has to give a reason. It refuted the false alarm, in writing, and that reasoning now sits on the record next to the finding.

Three findings confirmed, one thrown out, each with its justification attached.

This is the part that matters more than the scan itself. Anyone can run a scanner. The work is separating the one real problem from the twenty-two that are not, and being able to show why.

Report, not repair

The engine did not fix the header bug. That is deliberate. Its job ends at proof. It wrote up the finding with its evidence and opened the issue in our tracker itself. A human picks up the fix.

That boundary is the whole point. An agent that both finds and fixes is an agent you have to trust twice, once to be right about the problem and again to be right about the change. An agent that finds, proves, and hands off is one you can check at every step. The value is not automation for its own sake.

It is that the scope, the verification, the finding, the verdict and the filed issue are all recorded, and can be read back later by someone who was not in the room when it happened.

What is real, and what is not

To be clear about where this sits. The security capability is at phase one. The pipeline that turns a finding into a filed issue shipped this week. Some of the newer scanning tools still need their binaries installed on the machine that runs them before they mean anything. This is not a finished product, and we are not going to pretend it is.

What is real is the loop. We pointed a governed agent at our own stack. It found a genuine bug our own reviews had missed, it separated the real problem from the noise and showed its working, and it filed the result without touching anything it was not allowed to touch. We call this capability QuoxSecurity.

That is not a demo. That is the thing doing its job.