Security & testing · Beta
Scope first, then the work
Quox Security is Quox's security testing engagement layer.
In plain words
What it is, where it lives, when to reach for it
- What is it
- A permission layer for security testing agents: no scan runs without an authorised, in-scope, ownership-verified engagement.
- Where do I use it
- In your terminal through the
quox engagementcommands, and the Engagements console in the dashboard. - When would I use it
- When you want to test your own systems and need proof of scope and ownership before anything runs.
- How do I use it
- Run
quox engagement create <name>, add and verify targets, then scan. Beta, internal targets only, production capped at discovery.
Most security tooling assumes permission. Point a scanner at a target and it goes.
Quox Security assumes nothing. An agent cannot touch a target until an engagement says so: who owns it, what risk it is allowed to carry, and proof the target is actually yours.
The team
Four agents, one authorisation gate
All four are reachable in chat today. None of them can call a capability the engagement has not authorised.
DRAGO opens the engagement
Sets the environment tier and the risk ceiling, adds targets, and will not proceed until a target has proven it is really yours.
RECON-Q maps what is there
Subdomain enumeration and service discovery, once the policy check allows it for that target.
PROBE-Q tests the web surface
HTTP probing and template-based scanning, capped at the same risk ceiling as everything else in the engagement.
ATTEST-Q checks the claim
Nothing gets called a finding until it survives an adversarial second look asking for evidence it reproduces.
What Quox Security does not do yet
- It has not been proven against an external target yet. Every capability has been driven live against internal and staging systems, not a public, internet-facing domain you own. Subdomain enumeration in particular needs a verified domain target and has not been run for real yet.
- Production targets are capped hard. The highest risk level allowed against a production-tier target is discovery, and there is no way to raise that yet. Nothing above safe-active risk has ever run.
- It is not a purchasable product yet. There is no pricing, store listing or self-serve onboarding. You reach it through the API, the CLI, a Quox agent, or the in-product console.
- The deeper packs are not built. A capability registry with multiple providers per tool, cloud and identity packs, dynamic team assembly and any exploit or red-team capability are later phases and do not exist yet.
The gate every capability has to pass
Four checks, in order, before anything runs
Before an agent can run discovery, probing or scanning against a target, it has to pass a real authorisation check: is this target in scope, has it proven it is really yours, is the requested risk level allowed. Nothing runs before that.
The same gate runs whether the caller is an agent, the REST API, or the CLI. A denial states exactly which check failed, and nothing is ever built or sent to a host once one does.
- Is the target actually part of this engagement's scope
- Has the target proven it is really yours
- Is the requested risk level at or under what this engagement allows
- Is it currently inside the engagement's time window
$ quox engagement check-policy ENG_01J... example.test discovery
Already real
What is proven, live
Driven end to end through the governed CLI against real targets, not fixtures standing in for them. The gate, the scans, the findings and the report all ran.
Live scanning, every run governed
Twelve capability tools (nuclei, nmap, httpx, whatweb, sslscan, ffuf and more), eight proven live end to end. Every run passes the scope and risk gate first, is argument-injection-proofed, and executes on a bastion-managed scan host, never from a browser.
Injection-safe by construction
Every parameter passed to a scanning tool is shell-quoted and checked for argument injection, proven by handing the built command to a real shell and reading back what it parsed, not a regular expression guess.
Ownership verification with a real SSRF guard
DNS TXT, well-known file and QuoxAgent fleet membership prove a target is really yours. The web checks route through the same egress guard the rest of Quox uses: private ranges, loopback and metadata endpoints are blocked, redirects are not followed.
A policy gate with a paper trail
Every check runs against real engagement and target rows, not a mock, and a denial states exactly which rule stopped it: out of scope, unverified, over the risk ceiling, or outside the time window. Cross-org isolation is proven: another org never sees your engagement.
Findings that survive a second look
A finding is a candidate until an adversarial reviewer confirms it reproduces or refutes it as noise. Confirmed findings export to a PDF report, a GitHub issue, or a QuoxPlan note.
Continuous scanning, with diffs
Scans run on a schedule, diff each run against the last into new, regressed and resolved, and file a new high-severity result straight into your issue tracker. Server-side on a cron cadence, not a browser timer.
Status
Quox Security, honestly
- Stage
- Beta. The engagement model, 4 agents, 12 capability tools, scheduled scanning, the findings pipeline and an in-product console are all wired and driven live against internal targets.
- Environments
- dev and staging supported and driven live. Production is hard-capped at discovery risk, with no elevation path yet.
- Verification
- DNS TXT, well-known file (SSRF-guarded) and QuoxAgent fleet membership are real. Signed-attestation is declared but not built, and says so if you try it.
- Tools
- 12 across recon, web, TLS, network and offensive. 8 proven live end to end (nuclei, nmap, httpx, whatweb, sslscan, ffuf, dig, openssl). 3 not yet proven live: subdomain enumeration, secret scanning, image scanning.
- Findings
- Stored, adversarially verified, and exportable to a PDF report, a GitHub issue, or a QuoxPlan note.
- Agents
- DRAGO, RECON-Q, PROBE-Q, ATTEST-Q, all reachable in chat today.
- Interfaces
- REST API, the quox engagement CLI, and the in-product console. Full CLI parity: nothing lives only in chat.
- Next
- prove it against an external target you own, then lift production past discovery.
Beta. Not for sale yet. This reflects the current build, driven live against internal targets, not a commitment to a date.