Agent-Based vs Agentless PAM: Deployment, Coverage and Bypass Risk

Whether privileged access is enforced by software on every target or by a gateway in front of them decides what your PAM programme can see, what it can stop, and how an attacker gets around it. Agent-based PAM installs a component on each server or endpoint that enforces policy locally. Agentless PAM leaves targets untouched and controls access from the outside, through a proxy, jump host or session gateway that brokers connections and holds the credentials. This guide compares the two as architectures, not products: threat model, coverage, bypass, credential exposure and how to decide by estate, including operational technology where installing software is often not an option. It is for PAM owners, infrastructure architects and assessors. Category requirements are in the PAM Buyer's Guide, and how the gateway itself should be hardened is in Securing the jump host and bastion itself; this page does not repeat either.

Key takeaways

• The control point moves. Agentless PAM controls the path to the target; agent-based PAM controls what happens on the target. Each is blind where the other is strong.
• A gateway only works if it cannot be skipped. NIST SP 800-53 SC-7(15) routes networked privileged access through a dedicated, managed interface. Without target-side enforcement, an agentless design records only the administrators who chose to use it.
• Agents see local privilege; gateways do not. Local elevation with sudo or a local administrator, console logons and actions on hosts that are offline or outside the network never cross a proxy.
• Both concentrate risk. The proxy holds credentials for most privileged accounts; the agent runs as root or SYSTEM on every host and trusts its update channel. Protect whichever you deploy as tier zero.
• Most estates need both. Gateways for network devices, databases, OT and appliances that cannot take software; agents for server fleets and endpoints where local elevation and offline coverage matter; one policy and one audit trail across them.

What each architecture is

Agentless PAM: control the path

The target keeps its native access protocols: SSH, RDP, WinRM, database listeners, web consoles, device management interfaces. An administrator authenticates to a PAM gateway, selects a target and an account, and the gateway opens the session, usually injecting a vaulted credential so the person never sees it. The gateway records the session, can apply command or keystroke policy on protocols it understands, and closes the session when approval expires. To rotate passwords it connects to each target with a privileged service account (often called a reconcile or rotation account) and changes the managed credential over the same native protocols.

NCSC describes this kind of administration proxy as an intermediary that can be a central point for authentication, policy and logging, while noting that a proxy is not the only way to get those properties. Microsoft's privileged access guidance treats jump servers, gateways and PAM solutions as intermediaries that must sustain the security assurances of the session from the originating device and account through to the resource.

Agent-based PAM: control the host

A component runs on each target with the highest local privilege. It takes policy from a central service and enforces it locally: which commands or applications may run elevated, which accounts may log on, whether a session is recorded, and whether local administrator group membership is allowed. It sees activity however the user arrived, including console logons, and can usually enforce cached policy and queue logs while disconnected. The same agent may handle password rotation from inside the host, removing the need for a remote reconcile account.

Native operating system features show both halves of the agent model. On Linux, the sudoers manual documents I/O logging (log_input and log_output, both off by default) that runs the command in a pseudo-terminal and records input and output, and remote logging to a sudo_logsrvd server from sudo 1.9. On Windows, LAPS rotates each device's local administrator password from the device itself and backs it up to Microsoft Entra ID or Active Directory. The Endpoint Privilege Management Guide covers the endpoint side.

Side-by-side comparison

Threat model for each option

Agentless: what it defends and what it does not

• Defends against: credential theft from administrator laptops (the person never holds the password), shared and unrotated passwords, unattributed sessions, and remote logons outside an approval window, provided the target accepts privileged logons only from the gateway.
• Exposed by design: the gateway stores or retrieves credentials for most privileged accounts. Microsoft's intermediaries guidance notes that PIM and PAM solutions typically store credentials for most or all privileged roles, and that sessions passing through jump servers let attackers use standard credential theft tools on them.
• Blind spots: what happens after the shell opens. Elevation inside the session or an encrypted inner channel reaches the gateway as bytes it may not interpret.
• Attacker path: reach the target directly over SSH (T1021.004) or RDP (T1021.001) using a credential obtained elsewhere, or compromise the administrator's device and ride the brokered session. NCSC warns that compromising a management device may still allow access through an administration proxy.

Agent-based: what it defends and what it does not

• Defends against: standing local administrator rights, abuse of sudo rules and sudo caching (T1548.003), unrecorded console and local sessions, and use of local accounts (T1078.003) that never touch the network.
• Exposed by design: a privileged process on every host and a central service that can push policy or code to all of them. Compromise of that channel is a fleet-wide software deployment path, the pattern ATT&CK describes as T1072 Software Deployment Tools.
• Blind spots: hosts without the agent (new builds, unsupported OS versions, appliances), and anything the agent cannot hook. The sudoers manual notes that intercept mode, used to check commands spawned by a shell or editor, does not run set-user-ID programs unless explicitly allowed and is incompatible with SELinux RBAC without seccomp filter support.
• Attacker path: gain root or SYSTEM by another route and stop, unload or reconfigure the agent (T1685 Disable or Modify Tools), then act without local enforcement.

Coverage: where each stops

Bypass paths and how to close them

The usual weakness in agentless PAM is not the gateway but targets that still accept administration from elsewhere: make them refuse privileged logons that did not come from the gateway, and alert on any that slip through. The detailed network and protocol controls for a jump host are in Securing the jump host and bastion itself; the decision points specific to this comparison are below.

• Direct connection around the gateway: restrict SSH, RDP, WinRM and database listeners to the gateway's addresses with host and network firewall rules, and alarm on privileged logons from any other source. NCSC notes IP allow lists alone are weaker, as shared or spoofed address space can bypass them, so pair them with injected credentials the user never sees.
• Personal keys on targets: an SSH key in an authorized_keys file bypasses both the gateway and its recording. Inventory keys and move to a certificate authority; see the SSH Protocol and Certificate Authority Guide.
• Agent tampering: treat a stopped or unenrolled agent as a security event and protect its service and configuration from local administrators.
• Break-glass routes: NCSC asks for break-glass access so a proxy failure does not lock administrators out, with every use alarmed. Keep exactly one documented route per tier and test it; undocumented ones become the everyday path.

Credential exposure on the proxy and on the host

Agentless designs move credentials off administrator devices onto the gateway, a good trade only if the gateway is better protected. First, the reconcile accounts used for rotation have rights on every target, so they are among the most valuable credentials in the estate; scope them per target class. Second, the gateway's own administrators can usually replay recordings, change policy and retrieve secrets; NCSC describes the PAM system as an attractive target and asks for it to be architecturally constrained, patched and monitored. Third, interactive Windows sessions through an intermediate host can leave reusable credential material in memory (T1003.001 LSASS Memory). Microsoft documents Remote Credential Guard and Restricted Admin mode as ways to stop credentials being sent to the remote host, but also states that Remote Credential Guard is not supported through Remote Desktop Gateway or Connection Broker, so check what your gateway path allows before relying on it.

Agent-based designs reduce remote rotation accounts but place a trusted, privileged process on every host. Protect the policy service as tier zero, stage agent updates through the same rings as operating system patches, and require a second approver for policy that grants broad elevation. On SSH, do not let a gateway or agent workflow depend on agent forwarding: the OpenSSH client manual warns that an attacker with access on the remote host cannot obtain key material from a forwarded agent but can perform operations with the keys. For a breached vault, follow If your privileged access management (PAM) vault is compromised.

Operational overhead

Operational technology constraints

OT changes the default. NIST SP 800-82 Rev. 3 recommends security software such as intrusion detection, antivirus and file integrity checking only where technically feasible, testing patches under field conditions, and a DMZ architecture that prevents direct traffic between corporate and OT networks, with multi-factor authentication for remote access. Control system vendors frequently restrict what may be installed on engineering workstations and HMIs, and controllers cannot run agents at all. The workable pattern is an agentless gateway in the OT DMZ: named accounts, approval tied to a maintenance window, recording, and firewall rules that allow engineering protocols to the plant only from that gateway. Where the control system vendor approves an agent on an engineering workstation, test it on a non-production cell first. The OT Remote Access Guide covers the remote access design itself.

Choosing: decision guidance

• Choose agentless first when: targets cannot run software (network, storage, OT, appliances), the main risk is remote administration and third-party access, or you need coverage quickly without changing every host.
• Choose agent-based first when: the main risk is standing local administrator rights and sudo sprawl, hosts roam or go offline, or you must evidence what happened inside sessions regardless of how users arrived.
• Use both when: you run large server fleets: the gateway brokers remote access; the agent or native sudo logging controls elevation and catches anything that skipped the gateway.
• Small organisations: one hardened gateway with SSO and MFA as the only admin path, per-device local administrator rotation and native sudo I/O logging to a remote server is a realistic baseline before buying agents.
• Large or regulated estates: expect a mix by target class, one request and approval workflow, and an audit trail that joins gateway sessions to host-side events by user and time. The PAM Maturity Model helps place the mix by level.

Decision checklist: can each target class run a vendor-supported agent, do targets refuse administration except from the gateway, which hosts go offline for days, who can change agent policy or retrieve gateway credentials, and what happens when the central component is down?

Worked scenario: mixed estate

A manufacturer runs 1,200 Linux and Windows servers across two data centres and a cloud tenant, 4,000 laptops, network and storage devices, and three plants with HMIs and engineering workstations. The review split the design by target class. Servers: a gateway brokers all remote SSH and RDP with injected credentials, host firewalls accept admin protocols only from the gateway, and native sudo I/O logging with remote log servers covers elevation; agents go only on the 150 servers holding payment and design data. Laptops: an endpoint privilege agent removes standing local admin rights and LAPS rotates the local administrator password. Network and storage: gateway only, with device ACLs limited to its addresses. Plants: a gateway in each OT DMZ, maintenance-window approval and recording, no agents on HMIs. Detection joins gateway session IDs with host logons, and any privileged logon without a matching gateway session raises an alert. Monitor-only mode found 37 servers still administered through personal SSH keys, removed before enforcement.

How to implement: phased approach

1. Classify targets: list each target class with whether it can run a supported agent, whether it is reachable from a gateway, and whether it goes offline.
2. Stand up the gateway path: onboard privileged accounts, inject credentials, record sessions, and keep a tested break-glass route per tier.
3. Monitor before blocking: for two to four weeks, alert on privileged logons that have no matching gateway session, and fix the workflows that depend on direct access.
4. Enforce at the target: restrict admin protocols to gateway addresses, remove personal keys, rotate every credential an administrator has seen.
5. Add agents by ring: pilot on a test ring in audit mode, then a low-risk production ring, then high-value hosts; keep a documented rollback (uninstall package and restore previous sudoers or local group policy) for each ring.
6. Join the evidence: send gateway sessions, agent events and native host logs to the SIEM with a shared user and session key.
7. Review quarterly: agent coverage against the asset inventory, reconcile account rights, and who can change policy on either component.

Detection and measurement

• Privileged logons without a gateway session: SSH and RDP logons to targets whose source is not the gateway; target zero outside break-glass.
• Agent coverage gap: percentage of in-scope hosts with a healthy, reporting agent compared with the asset inventory.
• Agent health events: service stopped, unenrolled or policy reverted; each one investigated within a set time.
• Credential exposure: percentage of privileged sessions using injected credentials rather than displayed passwords, and time from checkout to rotation.
• Reconcile account use: logons by rotation accounts outside scheduled rotation jobs.
• Break-glass use: each use ticketed and followed by rotation.

Common failure patterns

• Gateway without target enforcement: recording looks complete while most administration still goes direct.
• Agent deployed, not monitored: nobody notices when it stops reporting, often an attacker's first move after gaining root.
• Displayed passwords: users copy vaulted passwords into their own tools and reuse them later outside the gateway.
• Over-scoped reconcile accounts: one domain-wide account rotates everything and becomes the best credential to steal.
• Agents forced onto OT: an unapproved agent on an HMI breaks a vendor support agreement or a real-time process; keep OT agentless unless the control system vendor approves.
• No fail-safe decision: a central outage either locks out administrators during an incident or silently disables enforcement; decide and test the behaviour per host class.

Framework mapping

Practitioner checklist

• Classify every target class as agent-capable, gateway-only or both.
• Make targets refuse admin protocols from anywhere except the gateway.
• Alert on privileged logons with no matching gateway session.
• Inject credentials instead of displaying them, and rotate after checkout.
• Scope reconcile accounts per target class and monitor their logons.
• Treat the gateway, vault and agent policy service as tier zero.
• Monitor agent health and coverage against the asset inventory daily.
• Turn on sudo I/O logging with remote log storage where no agent runs.
• Keep OT agentless unless the control system vendor approves an agent.
• Test break-glass and central-outage behaviour for each tier.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: SP 800-82 Rev. 3 Guide to Operational Technology Security
• NCSC: Protect your administration interfaces
• NCSC: Use privileged access management
• Microsoft Learn: Securing privileged access intermediaries
• Microsoft Learn: Remote Credential Guard
• Sudo project: sudoers manual
• OpenBSD: ssh_config manual

Related NHI Mgmt Group resources: Privileged Access Management Guide · Credential Vaulting vs Just-in-Time Elevation · Privileged Access Workstations Guide · Unix and Linux Privileged Access Guide · Privileged Remote Access Buyers Guide