What breaks when PAM is built mainly around SSH proxies in cloud environments?

Why This Matters for Security Teams

SSH proxy models were built for a world where privileged access was mostly human, interactive, and easy to funnel through a bastion. Cloud environments are different: the real privilege surface is now spread across IAM roles, service accounts, APIs, CI/CD jobs, and ephemeral automation. That means a proxy can still control a shell session while leaving the broader system of action authority untouched. NHI Management Group’s reporting shows 88.5% of organisations say non-human IAM practices lag behind or merely match their human IAM controls, which is a warning sign for teams relying on legacy PAM assumptions. The 2024 Non-Human Identity Security Report and the NIST Cybersecurity Framework 2.0 both point toward governance that is broader than session brokering alone.

The failure mode is not just visibility loss. Proxy-centric PAM often creates a false sense of control while cloud-native workloads continue to authenticate elsewhere with tokens the proxy never sees. In practice, many security teams encounter lateral movement and privilege creep only after an incident has already traversed the identity plane, rather than through intentional design of access boundaries.

How It Works in Practice

In cloud operations, the question is not only “who opened an SSH session?” but “what identity was used to modify storage, rotate keys, deploy code, or assume another role?” Proxy-based PAM can help for break-glass access or tightly controlled administrative shells, but it does not govern workload identity, cloud-native APIs, or agentic automation. That is why current guidance increasingly treats PAM as one control in a larger identity architecture, not the center of gravity.

Effective cloud governance usually combines session controls with identity-native enforcement:

• Use cloud IAM and workload identity as the primary control plane for service accounts, roles, and tokens.
• Issue just-in-time, short-lived credentials for specific tasks instead of long-lived static secrets.
• Evaluate access at request time with policy-as-code, so permission depends on context, not just a predefined proxy route.
• Log and correlate actions across SSH, API calls, and automation pipelines to preserve auditability.
• Reserve proxying for privileged interactive access, not as the mechanism that defines all authorization.

This is especially important in cloud compromises like the Snowflake breach and the 230M AWS environment compromise, where identity misuse and token exposure matter more than whether an SSH bastion was present. For workload identity and ephemeral access patterns, the current state of practice aligns more closely with cloud-native governance than traditional PAM. These controls tend to break down when ephemeral automation can assume roles outside the proxy path because the bastion never becomes the point where privilege is actually granted.

Common Variations and Edge Cases

Tighter SSH brokering often increases operational overhead, requiring organisations to balance audit simplicity against the speed and scale of cloud automation. That tradeoff is real, especially in environments where operators still need shell access for incident response or legacy administration. The mistake is assuming that because SSH is covered, the privilege problem is solved.

There is no universal standard for this yet, but best practice is evolving toward layered governance: PAM for interactive elevation, identity governance for cloud roles, and runtime policy for autonomous workflows. That distinction matters when teams run Kubernetes, serverless functions, or AI agents that never touch SSH but still hold powerful permissions. The Azure Key Vault privilege escalation exposure and the BeyondTrust API key breach are reminders that secrets and API authority can matter more than terminal access.

Where teams rely on proxy-only PAM in hybrid estates, the model also struggles with cross-account cloud access, non-interactive service meshes, and temporary roles chained by automation. In those cases, the practical control objective shifts from “broker the session” to “prove and constrain every privilege grant.”

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• Why do non-human identities create audit risk in modern environments?
• How should organizations prioritize environments for NHI management?