Autonomous by default.
Gated where it counts.
Sylas is a 400-billion-parameter model trained from the ground up on six years of real attack chains. It runs inside an architecture that enforces scope in code, stops for a human before it touches anything, and records every decision it makes.
Point it at production. It cannot talk its way out of scope, because scope is not something it is asked to respect — it is a gate in the execution path.
Issue a tool call against any target. Three are in the signed scope and three are not.
It is a different model, not a different prompt.
If general-purpose models are as capable as they now appear, what stops anyone pointing one at a network and calling the result a penetration test? Three things, and none of them is knowledge.
A test runs for hours or days against an environment that changes underneath it. Engagement state lives in a structured, queryable object — not a conversation history that drifts, degrades and falls out of the context window on day three.
Every tool call is validated in code against a signed Rules of Engagement object. A prompt-level guardrail can be argued with. A code-level check at the tool boundary cannot.
Every finding has to survive challenge from an auditor, an insurer or the customer whose asset it names. “The model reported it” is not evidence. A replayable, timestamped chain of the exact calls that produced it is.
Sylas was trained on approximately six years of real-world attack telemetry — full chains, from initial compromise on a perimeter device through lateral movement into internal systems. Not synthetic scenarios, and not isolated events scraped from public vulnerability databases. A model trained on write-ups can describe a technique. A model trained on chains has seen what an operator does next when the first three attempts fail.
Six phases, fixed order, one gate.
A penetration test cannot be modelled as a chat session. Sylas sits inside a state graph that drives every engagement through defined phases in an order it cannot bypass. Step through it — and note where it stops.
Reconnaissance
Maps the authorised estate and pulls first-party intelligence before touching anything: exposed credentials on the dark web, lookalike and typosquatting domains, and the current external attack surface.
Finding it and proving it are different jobs.
Automated scanners carry a documented 10–40% false positive rate, and that cost lands on your team. So the component that discovers a candidate does not get to decide whether it is real. A separate validation pass re-examines the captured evidence, and a candidate reaches the report only if the exploit path reproduces.
Candidates that fail validation are not quietly dropped. They are retained and surfaced as informational with the limitation stated openly. What was attempted and could not be confirmed is part of the deliverable, not an embarrassment to edit out.
Every proven finding ships with reproduction steps, captured request and response data, screenshots and video playback of the exploitation sequence. You get what you need to reproduce it yourself — and to verify the fix.
Why you can afford to run this more than once a year.
Most organisations test annually because that is what manual testing costs, not because annual is the right cadence. Median attacker dwell time is measured in days. An annual test leaves roughly eleven months of unvalidated configuration drift, new deployments and newly disclosed vulnerabilities.
Only the parameters relevant to the current inference are engaged — around 80 billion of 400 billion. Frontier-scale capability at a fraction of the cost dense activation would demand, which is what makes quarterly and continuous testing affordable rather than a once-a-year purchase.
Inference runs on GPU infrastructure we own and operate, provisioned per engagement and released on completion. There is no hyperscale cloud margin on every hour of inference, and no dependency on a third-party model API.
Testing cadence set by how fast your estate changes and how fast attackers move — rather than by what a manual consulting model can afford to deliver.
The questions a regulated buyer asks first.
Each engagement executes in its own dedicated, hardened container, provisioned at the start and destroyed on completion. Engagements never share execution environments, and no state persists between customers.
Engagement data — target detail, recovered credentials, evidence of successful exploitation — never transits a third-party model provider. Your data is not used to train Sylas or any other model.
Sylas demonstrates exploitability; it does not exfiltrate or retain your business data. Where a finding requires evidence of exposure, the capture is the minimum necessary and redacted in the customer-facing report.
When an auditor, insurer or regulator asks how a test was conducted, we produce the full execution trace, the signed Rules of Engagement with its enforcement record, and reproduction evidence for every finding — then put a member of the validation team on a call to walk through it. That level of substantiation is not something a conventional engagement can produce, because a human tester does not log at that resolution.
Mapped to what you are actually assessed against.
A raw severity score tells you something is wrong. A finding mapped to the control it breaks tells you what it costs you at your next assessment, and what to do about it. Pick a framework.
Findings and remediation tracking demonstrate the control operating, not merely existing.
Engagements follow recognised methodology sources: the OWASP Testing Guide, OWASP Top 10, NIST SP 800-115 and the Penetration Testing Execution Standard.
Autonomy in execution is not autonomy in reporting.
Findings are reviewed by qualified security professionals who take professional responsibility for the report that reaches you. They confirm exploitability, apply the business context the system cannot infer, set final severity against your environment and compensating controls, and are available to you, your auditors and your insurers to substantiate it.
Sylas does not reliably find business logic flaws, which are the majority of critical web vulnerabilities — and it does not replace a senior tester's judgment on impact. It runs the exhaustive, repeatable work at machine speed so the people on the engagement spend their hours on the part that genuinely needs them.
Scope a test against something you already know.
The most useful evaluation is a target a competent tester has recently assessed, so you have a baseline to compare against. We will run it and walk you through the findings, the evidence and the trace.