Agentless PAM Architecture: Trade-offs, and Why It Matters at Scale
DataDike Security Research
PAM Research & Field Engineering
Pick up any two PAM vendor brochures and one will say "agentless" and the other will say "endpoint agent for full visibility," and both will frame their choice as the obvious right answer. In practice the architecture decision has long-lived consequences for deployment time, supported platform diversity, the blast radius of platform bugs, and the speed at which the security team can keep up with the rest of the estate. This article walks the trade-offs we see in the field.
What "agentless" actually means
A genuinely agentless PAM intermediates the privileged session at the network layer using the native protocol the target speaks. Windows targets are reached through native RDP or WinRM; Linux through SSH; databases through their respective wire protocols; web applications through HTTPS. No software is installed on the target. The PAM appliance is the visible peer for the operator and a transparent proxy for the target.
The implication: onboarding a new target system requires only that the protocol be reachable from the PAM appliance and the credential live in the vault. There is no roll-out window, no patch cadence to maintain, no agent-version drift, and no per-target compatibility matrix to track.
What an agent buys you
Agents are not bad. They are a specific bet that the operational cost of running agents at scale is repaid by capabilities that are only possible with code running on the target. The honest list of those capabilities is narrower than vendors imply, and most of it is about endpoint-side activity rather than session-side activity.
- Process-level activity capture (what the user actually ran, including processes they did not type)
- Local privilege elevation without going back to a directory (e.g. ephemeral local-admin tokens)
- Offline session enforcement (when the agent can decide policy without contacting the PAM control plane)
- Endpoint application control tied to PAM identity
These are real and sometimes load-bearing. The question is whether your operational model needs them, and whether the cost of running agents across a heterogeneous estate is worth the marginal capability.
The trade-off table
| Dimension | Agentless | Agent-based |
|---|---|---|
| Time to onboard a target | Minutes (credential + network reach) | Days (package, deploy, validate) |
| Heterogeneity tolerance | High — every OS that speaks the protocol | Constrained to platforms the agent supports |
| Patch / version drift | None on targets | Per-target — agent versions drift |
| Network requirements | PAM-to-target reachability | Agent-to-control-plane reachability |
| Capability ceiling | Session-level controls | Session + endpoint-level controls |
| Failure blast radius | Loss of session proxy only | Loss of agent can affect endpoint stability |
| Vendor lock-in | Lower (open protocols) | Higher (custom agent) |
Where each model wins
Three scenarios make agentless the clear right answer:
- Heterogeneous estates with many target types and version diversity. A bank with 30-year-old AIX boxes, Solaris jumphosts, Windows 2012 R2 servers awaiting upgrade, and modern Kubernetes pods cannot rationally maintain an agent fleet across that span.
- Vendor-managed targets where you have no admin rights to install agents. Third-party hosted databases, SaaS administrative interfaces, managed Kubernetes are common examples.
- Air-gapped or regulated environments where any agent deployment requires a change-board approval cycle measured in weeks per target.
And three scenarios where an agent-based component is worth the cost:
- Endpoint-focused use cases (Workstation Admin Lite, application control, browser isolation on the workstation itself). The agent is on the workstation, not on the servers; the cost is bounded.
- Local-elevation flows that need to work offline. Field engineers, factory-floor operators, retail terminals.
- Process-level visibility for forensic granularity beyond what session recording provides.
Field observation
In nearly every engagement, an agentless deployment goes live in two to four weeks for the first wave. Agent-based deployments at the same scope routinely run six months to first wave because of the rollout machinery.
Where DataDike stands
DataDike is agentless by design for the server, database, and network estate — and that is not a marketing posture, it is a constraint the platform leans into. Targets are reached through their native protocols (SSH, RDP, SFTP, VNC, native database wire protocols, HTTPS); credential injection happens inside the protocol stream; session recording happens at the proxy. Onboarding a new target is a vault entry plus a network rule, not a deployment project.
For the narrow workstation-focused use cases where an agent earns its keep — local admin elevation, browser isolation, application control — we ship optional endpoint components that are scoped to those workflows rather than required for the platform to function. The defaults stay agentless; the option exists when the use case justifies it.
