No agent on the target
Connectivity uses the protocols the system already exposes, which removes the deployment obstacle that stalls most rollouts.
Agentless RDP and SSH
Privileged sessions brokered through Zetect without installing anything on the target system.
Most privileged access programmes stall on deployment: an agent on every managed host means a change request, a patching obligation and an argument with whoever owns the server. Zetect brokers RDP and SSH sessions instead, so control sits in the path of the connection rather than on the machine at the end of it.
How Brokered Sessions works
The mechanics behind the capability — what the platform does, and where it does it.
RDP and SSH
Covers the Windows and Linux administrative paths that carry the majority of privileged work.
Credential injection
The vaulted secret is supplied by the broker, so the user is never in possession of it.
Control in the path
Because the session flows through Zetect, recording, monitoring and termination are possible without touching the host.
What it changes
Who feels the difference once Brokered Sessions is in place, and how.
IT operations
Rollout is not blocked
No change board approval for agents on production hosts means the programme can actually start.
Security
Nothing new to patch
An agent fleet is itself an attack surface and a maintenance burden; there is not one here.
Platform owners
Covers systems that cannot take agents
Appliances and locked-down hosts are governed on the same terms as everything else.
Audit
Consistent enforcement
The same controls apply to every brokered session, rather than varying with what was installed where.
See Brokered Sessions in context
It works because the other capabilities share the same identity fabric. The quickest way to judge that is to watch it run against your own use cases.