I vibe-coded a PAM

This is the written-up version of a talk delivered by Sasha Le, Senior Engineer, Tide Foundation, at BSides Gold Coast. If you've read our earlier posts on Emergent Authority and KeyleSSH, this is a more technical walkthrough.

My name is Sasha, and I vibe-coded a PAM.

That should worry you. A Privileged Access Management system is, by design, the single most concentrated pile of risk in an organization. It centralizes every privileged credential you own into one place. It is the keys to the kingdom. So when an attacker got hold of an API key from PAM vendor BeyondTrust last year, the tool that exists to protect privileged access became the single point of catastrophic failure for at least 17 organizations, including the US Treasury.

But I can't blame them. They're fighting the same losing battle as all platform developers.

That's the paradox we keep coming back to. A PAM is built to guard the kingdom, but to do its job we hand it every key in the kingdom. Building one badly, by hand, over a few weekends, should be a recipe for disaster.

It doesn't have to be, and the reason why is the whole point of this post.

The problem doesn't get solved. It moves.

Start with the simplest possible remote access, a password SSH login. Your console opens a tunnel to the server, you type a username and password, the server checks them against its own copy, and you're in.

Look at what that costs you. The credentials have to map one-to-one to an account on the box. An admin has to remember to kill that account when the person leaves. And a copy of the password lives on the server, so anyone with read access can impersonate the user.

So best practice says don't use passwords, use PKI. Now the secret never leaves the user, authentication is zero-knowledge, and one account can be authorized by multiple keys. Better, genuinely better. But the problems didn't disappear. They moved. Now the user has private keys to manage. The admin still has to pull those keys when someone leaves, rotate them on a schedule, and keep a clean mapping of every public key to every user.

That adds plenty of admin overhead, but it doesn't fundamentally change the security situation. A key stored anywhere is a key exposed somewhere. Every honest attempt to secure SSH does the same thing. It relocates the secret to a slightly safer-looking box, a bastion, a vault, an HSM, and calls it progress.

The only way to win is to stop relocating the secret and remove the thing the attacker is reaching for.

Emergent Authority, in one move

The principle underpinning KeyleSSH is what we call Emergent Authority. The authority to perform a sensitive action sits completely outside the reach of any system or person using it, and emerges just in time, only because the right context and conditions have been met.

So the system's sensitive data, identities and access rights get locked with keys that no one, not us, not you, not your admins, will ever hold as a whole. Those keys are generated and operated in fragments across the Tide Cybersecurity Fabric, a decentralized network of nodes that perform partial operations on secrets without ever reconstructing them. Not even inside a Trusted Execution Environment. The signature is assembled from operating on those distributed pieces, and the key itself is never expressed anywhere.

Here is how that plays out in practice. When a sensitive operation is needed, KeyleSSH sends a simple API request out to the Fabric nodes. Each node, uses its own key fragment to perform just a small part of the operation, whether that's authentication, decryption, or signing, and hands back nothing more than its slice of the result.

What comes back from each node is a meaningless puzzle piece. Individually they reveal nothing. Only an authorized user can assemble the pieces into a meaningful result, which leaves everyone else in the blind and the key hidden forever, even from us. In the case of an SSH session, those partial signatures combine into a single valid Ed25519 signature, and the private key behind it is never reassembled anywhere.

None of this is magic, it's verifiable mathematics. The keys are born in fragments and stay that way, they never come together into a whole, anywhere. If you're familiar with threshold cryptography, secure multi-party computation, or zero-knowledge proofs, you'll recognize the shape of it. We call the framework Ineffable Cryptography, because the secret is never expressed, not even for an instant.

We've covered that cryptography in more detail elsewhere, so I won't relitigate it here. What I want to walk through is what it actually does to a live SSH session, because that's where it stops being a nice diagram and starts being load-bearing.

A session, start to finish

Login. The user logs into the KeyleSSH web app exactly like any browser login they've ever done. Username, password, enter. The interesting part is what didn't happen. No password left the device. There's no password database, and no server, not even during verification, ever sees the password. Authentication is a zero-knowledge proof against the Fabric, and the permissions granted for the session are fingerprinted to the device so they can't be replayed elsewhere.

Account assignment. Once authenticated, KeyleSSH maps the user to a pre-assigned SSH account representing their roles on the target server, and certifies that assignment for one ephemeral session using an organization master key that, again, sits outside anyone's reach. To stop a compromised KeyleSSH server or a rogue admin from quietly handing access to whoever they like, that assignment is only issued once a quorum of admins has cryptographically signed off on it. No single server and no single admin can forge it. This isn't application logic that a root admin can patch out. It's a constraint enforced by the signing network itself. If the threshold isn't met, the signature mathematically never forms.

The tunnel. Now the session builds an end-to-end secure channel. HTTPS from the browser to the KeyleSSH proxy, then SSH from the proxy onward to the server. The whole thing is encrypted with an ephemeral session key that only the user's terminal and the server ever hold. To trust the connection, the server checks exactly one thing, the single public key of KeyleSSH's master key, and then honors the signed account assignment for that session only.

Here is the part worth sitting with. The proxy is an oblivious converter. HTTPS in, SSH out. It cannot see into the tunnel and it cannot touch it. Breach this PAM and you find an empty shell. There is no vault to aim at, because the authority to open the session was never in the proxy to begin with. Bribe your way into it and the best you get is the compromised user's already-scoped access, with automatic throttling the moment behavior looks off. And it looks off quickly, because every action requires the Fabric's approval. Nothing bypasses policy, and the Fabric keeps an immutable audit trail, so accountability is baked into every action. Even a disgruntled insider has cause to pause.

That's the difference between a PAM and an oblivious proxy. One holds the kingdom's keys and tries very hard not to lose them. The other never holds them, so there is nothing to lose.

Making the internet as oblivious as the proxy

Everything so far is already a hermetic model for SSH. But at scale there's a question we haven't reached yet. What happens when there's an internet between the two ends?

Exposing an SSH server to the internet is its own category of pain. You're opening or forwarding a port, standing up firewalls, issuing an SSL certificate, managing ACLs tied to the user's source address, and then maintaining all of it, forever. Beyond the operational headache, every one of those seams is a place a new vulnerability can open up. Most "secure access" products spend the bulk of their complexity here, and most breaches find their foothold here.

KeyleSSH skips the whole thing. It can be hosted anywhere the user can reach it, including as a cloud-hosted service, and you drop a small Punch'd gateway inside the server's network. It's the same oblivious proxy as before, with one addition. It punches an outbound hole through the router out to the KeyleSSH infrastructure, the same idea as a Zscaler or a Cloudflare tunnel, except you don't have to trust it. No inbound ports. No firewall choreography. No public certificate. A session request from the user now has somewhere to land, the gateway's waiting outbound connection.

From there the two ends negotiate a direct, point-to-point tunnel. It runs over WebRTC's UDP transport, and the gateway converts it back to plain SSH at the server edge. The tunnel inside stays end-to-end encrypted with keys only the user's terminal and the server ever hold. Which means the traffic doesn't even route through KeyleSSH. And in the case where it does, say the Punch'd gateway is fully compromised, it is still completely blind to everything flowing through it. An oblivious man-in-the-middle by construction, not by policy.

It isn't only SSH

I started with SSH because a PAM is one of the hardest, highest-stakes things you could pick. But the model isn't specific to SSH. It's specific to authority, and authority is everywhere.

So the same edges now carry more protocols. There's a secure reverse web proxy for internal sites. There's browser-based remote desktop, where the RDP server authenticates with a JWT instead of a password, far less to attack. And there's network-layer VPN access into internal infrastructure. Each one works the same way. The proxy converts protocols at the edge and stays blind to the contents, while the authority lives in the Fabric, not the code. We'll dig into each of these in their own posts soon.

Trial by fire: the ceiling on secure vibe coding

Now, back to where I started. If you wanted to know whether vibe coding can ever be secure, a PAM is the hardest place to ask the question. The entire platform, SSH, RDP, VPN, the reverse proxy, all of it, I vibe-coded in three weekends. So I can promise you it is full of horrific bugs.

None of them can touch the cryptography at the edges.

The authority simply isn't in the code to steal. There's no key in memory, no secret in a config, no vault behind the app. So the software has exactly two states. It works securely, or it breaks completely. It fails closed. A bug can't leak the kingdom, because the kingdom's keys were never in the building. Neither can malicious code, for that matter, and that distinction is getting more important by the month as supply-chain attacks through dev repos become routine. A poisoned dependency that would hand an attacker the keys in a traditional PAM finds the same empty shell everyone else does.

This is what changes the math for the next few years. Frontier AI models will find the vulnerabilities in your software, faster than any human review can keep up, across the 85% of production code that's now AI-generated. Your admins will eventually be socially engineered. Those aren't risks you patch your way out of. They're virtual certainties.

The only durable answer is to make the breach inconsequential. To build systems where the worst day still yields nothing, because the authority an attacker is reaching for was never there for the taking. That's cyber immunity.

See how it works

KeyleSSH is open source. Here's the source code, and a demo if you'd rather just watch it run.

• Source: github.com/tide-foundation/keylessh-m2
• Live demo: demo.keylessh.com

We pointed Emergent Authority at a PAM on purpose, because it's the hardest target we could think of. But the architecture applies to anything that holds authority, which is why we're now maintainers on Red Hat's Keycloak for identity and access, and contributing the same model to Bitwarden and other open-source projects.

The breach was always inevitable. The catastrophic damage is now optional.