On-Prem Agent

About 5 minutes. You copy the install snippet out of the portal and run it on one host inside the network you want tested. The agent ships as a Docker container, an RPM or a DEB package, so it fits whatever build process you already use. There is no agent server, orchestrator hub or database to stand up alongside it, and there is no state to back up: if the host dies, deploy a fresh agent and it reconnects.

No. The agent makes a single outbound, server-authenticated TLS 443 connection to the platform and listens on nothing, so 0 inbound firewall rules are required and there is no VPN, jump host or tester credential to manage. It survives restrictive corporate proxies via HTTP CONNECT and reconnects automatically after a link drop. Scans execute natively on the LAN instead of tunnelling every packet out to a remote scanner, so internal testing is not constrained by the capacity of a VPN or WAN link.

Yes. One host can cover multiple subnets, provided it can route to them and those ranges are inside your authorised scope. Most organisations start with a single agent and add more only where routing, segmentation or a separate site makes it necessary, for example a DMZ that cannot reach the core network. Multi-site and MSP estates see every deployed agent, and whether it is online, from one console in the portal.

Updates are operator approved. The portal shows when a new version is available, and you click Upgrade on the agent, which installs it when the agent is idle and never mid-scan. A version pin or pause set on the agent host holds every update. Only a release PentestOps flags as a critical security fix installs without a click, and even then a pin or pause holds it. Images are built from versioned, audited Dockerfiles rather than pulled from an unsigned source, and an SBOM is available on request for procurement or compliance review. The agent reports its health to the portal every 30 seconds, so if it stops checking in, the portal shows it offline within about two minutes.

Discovered credentials are redacted before findings ship, so they never leave the agent in plaintext. SSH keys used for remediation stay on your hosts; the agent uses them in place and never exfiltrates them. Every dispatched scan, exploitation attempt and remediation playbook is tied to a signed Rules of Engagement record and written to a full audit trail, and the agent refuses targets outside the approved scope.

It is not a backdoor: it only performs work you dispatch from the portal, signed, scoped and audit-logged, plus scheduled discovery of the ranges in your signed scope. It does not capture or inspect traffic, so it does not replace an IDS, IPS or SIEM, though a metrics endpoint lets your existing monitoring watch the agent itself. It is not a VPN and never routes your application traffic. And it is not a replacement for human pentesters: it runs the repetitive, high-volume testing so your specialists can spend their time on the creative work that automation handles poorly.

No. External network, web application, API and email assessments run from the platform without an agent, cloud posture auditing uses read-only credentials you issue, and Kubernetes auditing is agentless via a read-only kubeconfig. The agent exists for the work that can only be done from inside: LAN asset discovery, internal port and service detection, credential testing, Windows and Active Directory enumeration, intranet web applications, and a daily network re-sweep that records host, port and service changes in a drift ledger.