From a domain to a decision, in six acts.
Every assessment follows the same arc (submit, observe, orient, decide, act, report) wrapped in a cognitive core that reasons over your attack surface as a model, not a wall of output. Here is the whole flow in plain language.
The six acts
You authorize a target
You enter a domain or IP you own or are authorized to test. Before a single packet leaves the box, SmartGate scores the target and refuses off-limits categories: hospitals, governments, schools and critical infrastructure. Authorized targets are queued; everything else is declined with a reason.
Recon maps the attack surface
The pipeline runs the same tools a human tester reaches for: subdomain discovery, port discovery, live-web probing with technology fingerprinting, and service-version scanning of each discovered asset. A discovery pass then goes behind the live origins, crawling the application including its JavaScript, mining archived URLs, reading any published API spec, and probing for undocumented query parameters. The result is one structured picture of your surface: what exists, what is exposed, what is running, and what takes input.
The agent ranks what matters
A security-tuned model reads that whole picture and writes a prioritized threat assessment: an executive summary, an overall risk level, and findings with severity, evidence, impact and remediation. It writes under evidence rules (below), so you get the few findings that matter, described in language narrower than a scanner's.
It decides whether to dig deeper
After each pass the agent asks itself whether one more focused scan wave is worth it. That decision runs under a hard step budget and is fully audited, so you can read why it continued or stopped. It is built to stop itself; the budget is the guarantee, not a hope.
It probes its own conclusions
Thirteen probe classes exist. Seven are quiet enough to run unattended: known-CVE versions, exposures, misconfiguration, subdomain takeover, TLS, anonymous FTP and open DNS resolvers. A match badges the finding CONFIRMED with the evidence behind it; a miss leaves it honestly marked unproven, and the refutation is kept on the record rather than quietly dropped. The other six touch the application actively and never fire on their own: they wait for an operator to approve them, one at a time.
You get a deliverable
Export the whole assessment as a client-ready PDF: prioritized findings, evidence, impact and remediation, written up in plain prose. It is the artifact you hand to a client or drop straight into a ticket.
A brain, not a bigger checklist
A scanner has a checklist. The thing that makes Xseth reason is its cognitive core: three capabilities that work over a shared, persistent picture of your surface. This is what we mean by Observe, Orient, Decide, Act.
The world-model
Every scan is projected into a persistent graph of hosts, subdomains, services, web endpoints and the edges between them. The agent reasons over that structure instead of treating each finding in isolation. The graph is the picture of a single scan and is rebuilt each time, so a re-scan gives you a fresh read rather than an accumulating one.
Attack-path chaining
A separate reasoning pass looks for places where individually-low findings combine into a high-impact path: an exposed config plus a weak service that, together, unlock something a checklist would never connect. "No genuine chain here" is a valid, common answer; it is reasoning about candidate paths, not a claim of proof.
The bounded decide-loop
The Observe → Orient → Decide → Act cycle is the loop. Each turn the agent decides to continue or stop, bounded by a step budget and recorded as an audit trail. Convergence usually halts it first; the budget is the hard guarantee that it always terminates.
How the model is kept honest
A language model will happily write a confident sentence about something it never checked. Three rules stop that from reaching your report, and none of them rely on the model choosing to behave.
Observed and inferred stay apart
The assessment has to say which exposure it actually saw and which misconfiguration it deduced, as two different things. Blurring them into one confident sentence is how a scanner turns an open port into a breach report.
A verdict the model does not write
A probe either matched or it did not. That signal is deterministic, and the model gets no vote in it. This is why a CONFIRMED badge carries weight that a confidence score never can: it is not the model grading its own homework.
Your verdict outranks both
Mark a finding a false positive and it stays marked across re-scans and drops out of the exported report. The agent's original row is kept for audit, so the disagreement is on the record rather than erased.
Reachability, not exploitability
When Xseth badges a finding CONFIRMED, it means a non-destructive probe reached the issue and matched real evidence: the weakness is genuinely there and reachable. It does not mean Xseth broke in. Proving a weakness is real (reachability) and proving you can exploit it end-to-end (exploitability) are different claims, and we only make the first. Anything not confirmed stays marked unproven rather than dressed up as fact.