A Sentinelleai web or DNS scan is not a penetration test. It runs known-pattern tools and, optionally, a read-only reasoning pass over their output. It does not attempt exploitation unless you explicitly arm and consent to an active module, and even then only against a target you have proven you control. It cannot find what a skilled human tester finds by exploring your application's business logic. We strongly recommend a professional penetration test by a qualified firm before launch and at regular intervals afterwards.
What you need first: proof of possession
A web or DNS scan is refused unless the account has already proven control of that hostname; see Proof of possession. Loopback, private-network, and similar addresses are exempt from that proof, and only for an admin account or on an installation running without authentication; an ordinary member scanning those addresses is refused outright rather than silently exempted, since no proof of ownership could ever be offered for them anyway. This is what keeps the platform from being a rented attack tool against a hostname a caller simply types in.
What a web scan runs
| Check | What it does |
|---|---|
| Headers | CSP, HSTS, frame options, content-type options, and related response headers, each validated rather than only checked for presence. A CSP that allows unsafe-inline, for instance, is flagged even though the header exists. |
| TLS | Cipher suites, protocol versions, chain validity, and expiry, read from the real handshake rather than assumed from a connection that failed for an unrelated reason. |
| Known-pattern vulnerability scanning | A large community template set, run with a curated exclusion of templates that log in, flood, or send tokens to a third party, since scanning your own site is not meant to generate the same traffic as an attack against it. A marker header lets your own logs tell this traffic apart from a real one. |
| Port sweep | Runs on a slower, weekly cadence rather than every scan, because a broad service sweep is itself intrusive enough to trip an intrusion-detection system. |
| Private-surface exposure | Runs on every scan: asserts that surfaces you have declared private stay unreachable from outside, and distinguishes a firewall-filtered port from a closed-but-unfiltered one from an open one. The middle case is the one that turns into an incident the moment something starts listening there. |
| Endpoint liveness | Checks whether an endpoint your site's own shipped code calls out to still answers, rather than assuming a well-formed credential in a bundle still works. |
| Breach and certificate-transparency data | Checks known breach corpora and certificate-transparency logs for the domain. |
| Threat-intelligence feeds | Abuse and threat-intelligence lookups where the corresponding provider key is configured; reported as not configured rather than silently skipped when it is not. |
Findings are also compared against the surfaces you have declared private for that asset, and an alert can go out the moment a previously closed surface reappears open. See Monitors & alerts.
What a DNS scan runs
| Check | What it does |
|---|---|
| Mail authentication | SPF, DKIM (against a set of common selectors), DMARC, and MX presence. |
| Delegation and dangling records | Confirms each nameserver the domain delegates to actually answers for the zone, and flags a CNAME pointing at a target that no longer resolves, the first, DNS-only half of a subdomain-takeover risk. |
| DNS posture | Whether a record that exists actually does anything. An SPF record over its lookup limit is present and inoperative, a DMARC record with no report address is present and unread, a signed zone with no chain to a validating parent is present and trusted by nobody. DNSSEC is judged against an explicit validating resolver rather than a stub resolver, since a stub can report every zone as broken regardless of whether it actually is. |
| Typosquatting | Registered lookalike domains for yours. |
A dangling CNAME into a provider is, on its own, only half of a takeover question: DNS can show that a name resolves nowhere, but not whether a provider would actually let a stranger claim it today. Where a provider's own hosting service answers the same generic page for any unclaimed name, that page is read directly and the name is decided rather than left as a guess; where a provider's not-found page is indistinguishable from an ordinary web server's, the name is reported as undecidable rather than guessed either way.
Application-source checks for web apps
Separately, when you run a code scan of your application's own source, not the live site, a further set of checks reads it specifically for web-application risk: OWASP API Top 10 patterns, DOM-based cross-site scripting and prototype pollution reachable from the browser, session-identifier fixation and expiration, application-layer authentication posture, and OAuth scope-versus-capability mismatches on your own login connectors. These run against source you submit to a code scan, not against a URL you submit here.
The reasoning panel add-on
An optional AI layer can run after the checks above complete, reasoning over their combined output rather than probing anything further itself. It is read-only by construction: it never contacts or attacks the target, and its only outbound call is to the model. It exists to catch what signature-based tools structurally cannot: business-logic and authorization flaws with no fixed pattern, and correlation across several small findings into one exploit path. It fails closed: if it cannot produce a trustworthy consolidated result, nothing is billed and the deterministic findings from the scan stand on their own, unchanged.
This panel is disabled by default on the platform. Where it is enabled, a hypothesis it raises that would need live confirmation to settle is never confirmed by the panel itself. It is flagged for one of the consented active modules below to test, explicitly and separately.
The dynamic scan
A dynamic scan is different in kind from the checks above: instead of reading source or probing a live host, it mounts an application directory you provide, starts it inside a sandboxed container on a network with no route out, and attacks it from a second container on that same isolated network. Nothing it sends can reach anything beyond what you handed it. Because the target is a local application directory rather than a hostname, this scan does not go through the proof-of-possession gate that a web or DNS scan does; instead, like every input that names a path on the scanning host, it is limited to an admin account or a single-operator installation.
There is no crawler and no automatic route discovery by default: a plan names two identities, a request, and a marker value that only the rightful identity's response should contain. A plan can also be derived by crawling the running application as each identity and comparing what they saw, but a derived candidate is only proposed with a marker when one was actually observed in one identity's response and shown absent from the other's. Where no such marker exists, the candidate is left unarmed with a stated reason rather than given an invented verdict. An endpoint nobody wrote or discovered a plan for is not tested, and its absence from the report says nothing about it.
{
"authz": [
{
"id": "INV-7",
"resource": "invoice 7, owned by alice",
"request": { "method": "GET", "path": "/api/invoice/7" },
"marker": "SECRET-7",
"owner": {
"name": "alice",
"login": { "method": "POST", "path": "/login",
"body": "{\"user\":\"alice\",\"pass\":\"...\"}" },
"carry": "cookie"
},
"other": {
"name": "bob",
"login": { "method": "POST", "path": "/login",
"body": "{\"user\":\"bob\",\"pass\":\"...\"}" },
"carry": "cookie"
},
"anonymous": { "name": "anon", "login": null, "carry": "cookie" }
}
],
"fuzz": {
"seedRequest": { "method": "POST", "path": "/api/items", "body": { "id": 1 } },
"budget": 60
}
}The two identities and the marker are what make the difference between "this endpoint leaks across users" and "this endpoint returned something to both of them" decidable at all. The anonymous identity is optional; its absence is reported, since without it the platform cannot tell "both identities saw this" apart from "this is public".
Active verification modules and consent
A small number of modules go further than reading or reasoning: they send traffic designed to actively confirm a hypothesis, against a target the account itself declares. Every one of them shares the same posture.
- Disarmed by default. Nothing in this category runs at all unless the operator has explicitly enabled that class of action on the deployment.
- A consent phrase, typed verbatim by the caller, on every declared target, not a boolean flag that a future change could default to true by accident.
- The declared target must already be proven under the same ownership gate as a web or DNS scan; a non-loopback target additionally requires an explicit allow-list entry set in the environment before the module is even loaded.
- Hard ceilings on corpus size, request rate, and total run time, enforced inside the module regardless of what a caller asks for.
- Never a rented attack tool: nothing here accepts an arbitrary caller-supplied target the way a paid stress-testing service would.
Two modules in this family are relevant to a web target: a sustained-load tester that measures degradation under saturation, concurrency, and volumetric load rather than a single malformed request; and a runtime prompt-injection tester for an agent endpoint, covered in full on AI & agents. Both are marked in observation in the current plan structure. See plans & billing for what "in observation" means for a line item.
What it stops short of
- Known-pattern tooling finds signatures and misconfigurations, not your application's business logic. An authorization flaw with no fixed shape is exactly what the optional reasoning panel and the dynamic scan's authorization plans exist to reach, and neither replaces a skilled human tester exploring your application by hand.
- The reasoning panel never confirms anything live by itself; a hypothesis that needs confirmation is only tested by an explicitly armed and consented active module.
- A dangling CNAME into a provider whose not-found page cannot be told apart from an ordinary server's is reported as undecidable, never guessed either way.
- The port sweep runs weekly, not on every scan; the daily private-surface check covers the surfaces you have declared, not a full re-sweep.
- Active modules only ever run against a target the account itself declared and proved, never one discovered elsewhere in a scan.
- Nothing here executes a full exploit chain end to end the way a real intrusion attempt would.