Credential brokering & the proxy model

The Secret Is the Problem

Most privileged access incidents start the same way: a credential leaks. Not from a sophisticated attack — from a password in a shared drive, a key in a script, an admin account passed around in chat “just for this incident.”

The usual fix is a vault: store the secrets centrally and hand them out. But a vault still ends the same way — the secret lands in the user’s hands. Once a human has seen the credential, it can be written down, screenshot, reused, or forgotten. The blast radius of a single shared secret is every system it works on.

Credential brokering is different: the user authenticates, and the secret never reaches them.

Zero-Knowledge Credential Brokering

PDAccess brokers credentials zero-knowledge: the credential is held in the PDAccess platform, injected into the session by the proxy at the moment of connection, and removed when the session ends. The user gets access without ever seeing the secret.

What that means in practice:

• Users authenticate, not memorize. They prove who they are — with forced MFA, optionally Google login — and the platform proves the credential into the target.
• No shared accounts. Every session is tied to an individual identity, so “who was the admin account?” stops being a question.
• No secret sprawl. The credential exists in exactly one place, and it never appears in a clipboard, a browser password field, a ticket, or an email.
• Rotation is invisible. Rotate the credential and nothing else changes — because nobody downstream ever held it.

How the Proxy Model Delivers It

Brokering only works if the session flows through something you control. That’s where PDAccess’s proxy model comes in: the customer installs lightweight proxies in their own systems, network, or cloud, and every privileged session is brokered through one of them.

Proxy	Brokers
Web Based Terminal	Browser-based privileged shell sessions
Native SSH	Native SSH sessions
Native RDP/VNC	Native desktop sessions
Database (SQL client)	SQL client sessions
TACACS / RADIUS / LDAP / OAuth2	Identity for network devices, directories, and applications
Web content proxy	Secure browsing sessions
Client	Local port forwarding

The proxy sits between the user and the target. It authenticates the user, enforces policy, injects the credential into the session, and records the whole thing — text and video. The user experiences a normal session; the secret never crosses the boundary.

Every Session Recorded, Every User Accountable

Because the session is brokered, PDAccess can record it in full:

• Text recording for terminal and database sessions — every command, in order, with timestamps.
• Video recording for RDP/VNC and browser sessions — what the user actually saw and did.
• Identity attached to the session — the brokered session belongs to the person, not to a shared account.

When an incident happens, the answer to “who did what, and how” is a recording, not a guess.

Why This Beats the Vault-Only Model

A vault answers “where is the secret stored.” Brokering answers the harder question — “can the secret escape?” The difference:

• Vault: secret stored centrally, handed out, seen by the user.
• PDAccess brokering: secret stored centrally, injected by the proxy, never seen.

Combined with forced MFA at the front door and a zero-knowledge broker at the back, the credential becomes an internal detail of the session rather than something humans manage.

The Bottom Line

Credential brokering is the point: users authenticate, PDAccess brokers the credential through the customer’s own proxies, and the secret is never exposed. Zero-knowledge, recorded, and tied to a real person — that’s what the proxy model makes possible.

#PDAccess #PAM #CredentialBrokering #ZeroKnowledge #PrivilegedAccess