In agentless privileged access, the user opens a session in a web browser and the connection to the target is made by a gateway, not by software on the user's computer. Nothing is installed, no VPN is needed, and the credential never reaches the person.
"Agentless" is used loosely, so it is worth being exact about what is and is not removed. This article explains what happens between the click and the session, and what to verify in a pilot.
What happens when a user clicks Connect
- The user authenticates to the console, with multi-factor authentication where policy requires it.
- Policy is checked. Is there an approved grant for this user, this target, right now? Does the time window, source or risk score allow it?
- The gateway opens the connection to the target on the user's behalf, using the protocol the target speaks: RDP, SSH, VNC, a web application, or a Kubernetes console.
- The credential is injected server-side. The gateway retrieves the credential from the vault and uses it to log in. The user is never shown it, cannot copy it, and has nothing to paste into a stray window.
- The session is rendered in the browser. The gateway translates the remote screen or terminal into a stream the browser can display, and sends keystrokes and mouse events back.
- Everything is recorded and observable. Video and keystroke or command records are captured at the gateway, and a supervisor can watch live, take control or end the session.
- The grant expires. When time is up the gateway ends the session, and for just-in-time grants any temporary account is removed.
The user's computer never needs a route to the target, which is why internal systems can be reached without a VPN: only the gateway needs that network path.
What this removes from the endpoint
| Concern | With a thick client and VPN | With an agentless gateway |
|---|---|---|
| Software to install and patch on every admin laptop | Yes | No |
| Network path from the laptop into the data centre | Yes, by VPN | No, only the gateway has it |
| Privileged password on the user's machine | Often | Never |
| Contractor on an unmanaged device | A risk | Acceptable: nothing sensitive is stored locally |
| Where recording happens | Often on the endpoint | At the gateway |
For vendors and contractors, this changes the conversation: access can be granted for a task without enrolling their laptop or issuing them a VPN account.
What "agentless" does not mean
- There is still software on the gateway. You deploy and operate it.
- Targets may still need setup. For example, a Windows host needs remote desktop enabled, and some controls (such as restricting which programs run) are applied on the host by policy.
- Not every client tool is a browser tab. Tools such as database consoles and terminal clients can be published through the gateway as remote applications, so the user sees one application window in the browser instead of a full desktop.
- Latency exists. A rendered stream adds a little delay compared with a local client. Test it from the locations your admins really work in.
Controls that belong at the gateway
Because the gateway sits in the path, it is the right place for:
- Clipboard and file-transfer policy, per resource.
- Recording of every session, with retention.
- Live oversight: spectate, intervene, take control, terminate.
- Session limits and idle timeouts.
- Step-up authentication in the middle of a session when risk rises.
- Command or scope enforcement for the protocols where it is possible, and recording plus risk scoring where it is not.
- Jump servers for segmented networks, so the gateway reaches a bastion that reaches the target.
Pilot checklist
- Reach a target with no VPN from a laptop that has no PAM software installed.
- Try to find the password. Inspect the page, the network traffic and the clipboard. It should not be there.
- Test the protocols you actually use. RDP to a Windows server, SSH to a Linux host, a web admin console, and one published tool such as a database client.
- Test through a jump server if your network is segmented.
- Watch live as a supervisor, then take control, then terminate. Check what the user sees.
- Disable clipboard or file transfer on one resource and confirm it is enforced.
- Check recording: playback works, is complete, and is searchable.
- Measure latency from your real locations, with typical admin tasks.
- Let a grant expire during a session and confirm the session ends and any temporary account is removed.
How ZenXPAM supports this
ZenXPAM delivers RDP, SSH, VNC, web applications and Kubernetes consoles through the browser with credentials injected at connect time, and publishes tools such as SSMS, DBeaver, PuTTY, pgAdmin, Chrome and Edge as single-application windows. The protocol gateway is built on Apache Guacamole, orchestrated by ZenXPAM's own approval, vault and policy services. Sessions can be routed through jump servers and on-premises site tunnels, recorded with keystroke and command capture, and supervised live with spectate, take-control and terminate. Clipboard and file-transfer behaviour is set per resource, and the same grant model covers standard, just-in-time and emergency access. See the agentless remote work solution or book a demo.
FAQ
Is agentless PAM less secure than a thick client? The credential and the network path stay at the gateway, which usually reduces exposure. What matters is how well the gateway itself is protected and monitored.
Does it work for Linux and databases? Yes, SSH terminals work in the browser, and database tools can be published as remote applications or reached through a query proxy.
Can a contractor use it from a personal device? That is one of its main uses, because the sensitive material stays at the gateway. Pair it with multi-factor authentication and a short, approved grant.
Do I still need a VPN? Not for users reaching targets through the gateway. The gateway needs network access to the targets.
What about performance? A browser stream adds some delay. Test from the locations your administrators work in, with the tasks they actually do.