Ask teams that have lived through a legacy PAM rollout what consumed the schedule, and the answer is rarely policy design. It is agents: packaging them, deploying them to thousands of servers, patching them, debugging their conflicts with other software, and discovering the platforms they cannot run on. Many PAM programmes achieve partial coverage and stall there - and partial coverage in privileged access means the riskiest systems are often exactly the ones left outside.
The enterprise challenge: control that requires touching every endpoint
Any security architecture that requires software on every controlled endpoint inherits the endpoint estate's full diversity: multiple operating systems and versions, network devices and appliances that accept no third-party software, legacy servers nobody dares modify, and client laptops under separate management. Each category adds deployment work, and each unfinished category is a hole in the control. The ongoing cost is equally real - every agent is one more component to patch, monitor and troubleshoot forever.
Why the agent model persists
Legacy PAM suites were architected in an era when interception at the endpoint was the available technique, and their deployment models - agents on targets, thick clients on administrator workstations - persist by inertia. The consequence shows up in timelines: multi-month rollouts are treated as normal, and the tooling shapes the programme rather than the other way around.
The Tanflow approach: a gateway, not an agent fleet
Tanflow PAM takes a different architectural position: no software on targets, no clients on laptops. A browser reaches SSH, RDP, VNC and database targets through one controlled gateway. The gateway terminates the user side of the session, connects to the target using vaulted credentials, renders the session in the browser, and applies recording and command control in the connection path.
Everything the agent model achieved by touching endpoints, the gateway model achieves by sitting between them:
- Credential protection: the vault injects credentials at the gateway; users never see passwords, and targets need no modification to make that true.
- Session recording: capture happens in the path, so coverage equals routing - if the session traversed the gateway, it was recorded.
- Command control: keystrokes are inspected in real time against policy at the gateway, with graduated verdicts from warning to blocking with session termination.
- Protocol breadth: because control lives in the gateway, adding coverage means supporting a protocol once - Tanflow PAM spans SSH, RDP, VNC, Kubernetes kubectl exec, Telnet for legacy devices, SFTP, HTTPS web admin consoles and more than fifteen database CLI and GUI clients.
One clarification worth making explicitly: zero-agent describes this deployment architecture - nothing installed on targets. It is unrelated to Zero Trust, which is a security architecture concept about never trusting network location. Gateway-mediated, authenticated, per-session access of this kind is a component organisations commonly use within a Zero Trust-style architecture, but the two terms should not be conflated.
Deployment characteristics that follow from the architecture
The absence of endpoint software changes the deployment shape. Tanflow describes its typical implementation as two to four weeks to production: discover targets, vault credentials, set policies, onboard teams. The platform deploys on-premises or in a private cloud - including air-gapped environments - so credentials and session recordings remain inside the organisation's perimeter. For resilience, it supports high availability with active-active nodes and replicas that converge in about a minute, and a single deployment scales from one team to the whole organisation.
Enterprise scenario
Consider a government IT environment with a mixed estate: recent Linux servers, ageing Windows hosts, and network equipment reachable only over SSH and Telnet. An agent-based control would cover the first category, struggle with the second and skip the third. A gateway architecture treats all three identically - they are targets the gateway connects to, with credentials vaulted, sessions recorded and commands policed, and nothing installed anywhere. The network devices, historically the least governed access in the estate, come under the same control as everything else on the first day they are routed through the gateway.
Security and audit implications
Architecturally enforced coverage is easier to attest than deployed coverage. The audit question shifts from "is the agent installed and healthy on all 3,000 servers" to "is direct access to targets restricted so sessions traverse the gateway" - one network-level control instead of thousands of endpoint states. Tanflow additionally provides an External Access Monitor that detects server logins that bypass the PAM gateway, closing the loop on the one assumption the architecture makes.
Conclusion
PAM programmes fail on friction more often than on policy, and agents are where the friction lives. The Tanflow zero-agent gateway removes that entire category of work: a browser on one side, the estate on the other, and every privileged doorway - servers, desktops, network devices, databases, Kubernetes - controlled, recorded and audited through one point in between.