Internal scanning
Run a WASViking scan against an internal target through the agent tunnel.
Once a Sentinel agent is online, scanning an internal application looks identical to scanning an external one. The same scan profiles, the same analyzers, the same finding format. The transport is the only thing that changes.
Create an internal target
In the portal, Targets → New target:
| Field | Value |
|---|---|
| URL | https://internal-app.corp (whatever resolves inside your network) |
| Routing | Pick an online Sentinel agent instead of "Cloud egress" |
| Subdomain coverage | single host is the safest default for internal targets |
| Scan profile | Pick the one that matches the application |
Internal targets cannot route through the WASViking cloud egress. The Routing field enforces this.
Authentication
Internal apps usually require login. Pick the auth mode that matches your stack:
- Form Login with AI Autofill works for most server-rendered apps.
- Bearer is right for internal REST APIs with OIDC.
- Cookie is the escape hatch for opaque session systems.
Credentials are encrypted at rest in the WASViking control plane. They travel to the agent encrypted, are used in memory, and never written to disk on the host.
What happens during the scan
- The portal queues the scan in Redis.
- The gRPC server hands the job to the right agent (matched on org binding and online state).
- The agent receives the scan plan, opens the requested probes, and streams responses back to the cloud-side analyzers via the tunnel.
- Analyzers process the data on the WASViking side. Findings are written to MongoDB, an Evidence record links the agent + host.
- The AI Recommendation runs on the cloud side once the engine verdict is available.
The agent does not run analyzer logic locally for DAST. It is a transport. This keeps the analyzer engine consistent regardless of internal vs external.
Finding format
Findings produced through a Sentinel agent are indistinguishable from
external findings in the portal, with one exception: each carries a
source.agent_id and source.agent_host field. Filter the Findings
page by agent to see only what came through a given host.
Limits and guardrails
- One concurrent scan per agent by default. Configurable per agent. Heavy hosts can run 2 to 4 in parallel.
- Bandwidth. The tunnel uses HTTP/2; analyzer probes are small but numerous. A 1 Mbps link is enough; a 10 Mbps link is comfortable.
- Scan timeout. 12 hours hard ceiling per scan (stale-scan cleanup). Most internal scans finish in 20 to 45 minutes.
Restricting agent reach
For sensitive networks, restrict what the agent can reach with host-side firewall rules. The agent honors these and reports unreachable hosts as discovery failures in the scan log.
A typical pattern:
- Allow the agent to reach the application subnet.
- Block the agent from reaching the management network.
- Block egress from the agent to anything other than the WASViking gRPC endpoint.
Multiple agents
You can install multiple agents per organization. Use this to:
- Cover network segments that cannot reach each other.
- Pair an agent per data center / cloud region.
- Isolate scanning load from production-critical agents.
The portal shows all agents and their state. Target routing picks one.
What it does not do
Sentinel does not scan the host it runs on. The agent is a transport for DAST; it does not implement host-based vulnerability scanning, endpoint protection, or network discovery. For SBOM and secrets on the host, see the next pages in this section.