DEV Community

Vinod Patil
Vinod Patil

Posted on

Building an Agentless, AI-Assisted Privileged Access Gateway

#ai #devops #security #architecture

Traditional PAM leans on thick RDP/SSH clients, jump boxes and endpoint agents. In multi-cloud and containerised estates that means bootstrap latency on every host, exposed management ports, and audit gaps wherever an agent can't be installed. This post covers how ZenxPAM handles three of those problems: browser-native session streaming, on-prem AI session analysis, and tamper-evident audit evidence.

1. Zero-footprint interactive sessions

The operator opens a token-authenticated HTML5 client in an ordinary browser. There is no plugin, VPN client or local credential.

Browser (HTTPS / WSS)  ->  ZenxPAM gateway  ->  Apache Guacamole (guacd)  ->  RDP / SSH / VNC target
Enter fullscreen mode Exit fullscreen mode
  • Protocol translation. Apache Guacamole 1.6.0 with custom authentication turns the browser's WebSocket stream into RDP, SSH or VNC toward the target. Targets only need to accept connections from the gateway, so management ports stay off the operator's network.
  • Credentials never reach the browser. Secrets are injected from the vault server-side at connect time.
  • Recording is a side effect of the architecture. Because every byte passes through the gateway, Guacamole records the session in real time, with no endpoint monitoring driver.
  • Kubernetes consoles (kubectl, k9s, Lens) are brokered through a jump host with vaulted credentials and recording.

2. Local-first AI: no data leaves the perimeter

Session telemetry is sensitive, so the AI layer calls a self-hosted Ollama instance on the same Docker network as the services. No external LLM API is involved.

  • Per-command risk scoring. Commands in a live session get a risk score and level plus risk indicators, and high-risk commands can be blocked with a recorded reason.
  • Behavioural anomaly checks run against session activity, and sessions roll up to an overall risk level.
  • Post-session analysis. After a session ends, the commands, deviations and MFA events are summarised by the local model, including average and peak risk scores and the riskiest commands.
  • Natural-language search over audit and access data runs through the same local model.

3. Tamper-evident audit evidence

Each audit event gets a linked entry in an append-only chain:

  • Hash is SHA-256 over the entry's id, action, entity type, timestamp, block index and previous hash.
  • PreviousHash links to the prior entry, with a sequential BlockIndex per tenant. A Merkle root is stored for block verification.
  • The chain lives in PostgreSQL. The data layer rejects any update or delete of chain entries, the API is append-only, and a foreign key prevents hard-deleting a source log that has a chain entry.
  • A verification endpoint walks the chain and checks hashes, links and gaps, and a tamper-detection endpoint reports broken links.
  • Session recordings get a SHA-256 hash at upload, and evidence packs reference recordings with their integrity hashes. Recordings can be retained in Azure Blob, S3 or GCS.

The chain is tamper-evident, not tamper-proof: someone with raw database access can still rewrite rows, and verification is what catches it.

Next steps

Docs and a deployable demo are at zenxsys.com.

Top comments (0)