Scan inside the network. Without VPN, jump hosts, or inbound ports.
The Sentinel agent dials outbound over mTLS gRPC and opens a tunnel. Every WASViking analyzer runs against your internal targets through that tunnel, with no analyzer-specific code and no architectural concession on the cloud side.
Cloud DAST cannot reach your internal apps. Most workarounds make it worse.
Exposing internal apps through a VPN, reverse proxy, or static-IP allow list creates a new attack surface and a new operations burden. Installing a heavy on-prem appliance with inbound ports trades scanning blindness for a firewall hole.
Sentinel is the opposite pattern: a small Go agent the customer installs, that opens an outbound mTLS tunnel to WASViking. No inbound ports. No static IPs. No allow-listing on the WASViking side either.
# Run on the customer host (Linux, systemd)
$ ./wasviking-sentinel register --org acme --token wv_join_*****
[sentinel] Generating client certificate (mTLS) on this host...
[sentinel] Binding to org: acme
[sentinel] Registered. Tunnel handshake: OK
$ sudo systemctl enable --now wasviking-sentinel
● wasviking-sentinel.service - active (running)
NoNewPrivileges=true
ProtectSystem=strict
MemoryDenyWriteExecute=true
[sentinel] Tunnel established to sentinel.wasviking.com
Same scanner. Same finding format. Just routed through the tunnel.
Every dynamic analyzer routes its HTTP probes through TunneledHTTPAdapter transparently. The SQLi, XSS, JWT, GraphQL, SOAP, WebSocket, and InjectionClass analyzers do not need tunnel-specific code. The tunnel is a property of the platform, not a feature of one scanner.
Transport and certificate lifecycle
mTLS terminated at the proxy with header-forwarded client certificate (AWS ALB compatible), then plain h2c on the internal loopback. Org binding via certificate CN/O. The client certificate is generated on the customer host at first registration and never leaves it: end-to-end mTLS from agent to tenant. Rotate or revoke from Sentinel Agents in the portal in one click, with full usage history per agent.
Agent hardening
systemd unit with NoNewPrivileges, ProtectSystem=strict, MemoryDenyWriteExecute, restricted syscalls. Releases signed with cosign. Optional obfuscated enterprise build.
Operator privacy
Strict secret redaction at the gRPC service layer. The server never logs full proto, job, or response, so cookies, CSRF tokens, and bodies of internal targets do not leak to operator logs.
More than internal DAST. Sentinel is the on-premise edge of the platform.
Internal application scanning
Run any WASViking analyzer against internal hosts. The finding format is identical to an external scan, with clear lineage to the agent and the host that produced it.
See DAST coveragePremise-side SBOM
wasviking-sentinel sbom walks build manifests and submits CycloneDX 1.5 enriched with OSV and CISA KEV to your tenant. The base for the CI/CD gate and the Evidence Bundle.
Local secrets discovery
wasviking-sentinel secrets walks filesystem and git history. Raw secrets never leave the agent. Only SHA-256 hash and masked preview reach WASViking.
CI/CD gate
wasviking-sentinel ci --sca, --secrets, and --template for org-scoped scan policies. Deterministic exit codes the pipeline already understands.