A technical guide for security teams running traditional security tools, who are discovering that cloud infrastructure has broken every assumption their PAM tool was built on, and what cloud-native privileged access actually looks like.
Traditional PAM tools solved a real problem in 2010. The problem is that cloud infrastructure has fundamentally changed every assumption they were built on, and most security teams haven’t caught up with the gap.
If your organization is operating in AWS, Azure, GCP, or any combination, you’ve likely felt this tension firsthand. The PAM tool that governs your on-premise estate (the one your team invested months deploying) doesn’t cover your cloud the way it covers your data center. And the gap is growing faster than most security programs can respond to.
This article covers:
- What traditional PAM was designed for and where it still fits
- The specific ways cloud infrastructure exposes its structural limitations
- What cloud-native privileged access actually requires in 2026
- A practical framework for closing the gap, including a deep dive on Cloudanix’s approach
Written for security architects, CISOs, and DevSecOps leads who are running/ evaluating PAM tools and need an honest assessment of where they break in cloud environments.
Traditional PAM vaults credentials. Cloud security requires eliminating credentials altogether. These are not the same goal — and the difference matters more than most teams realize.
What Traditional PAM Was Built For: A Fair Assessment
Before making any case for change, it’s important to acknowledge what traditional PAM genuinely solved. These tools were built by serious engineers for a real and pressing problem, and senior security professionals have invested years and significant budget in them. That context deserves respect.
What Traditional PAM Genuinely Solved?
- Password vaulting: Centralized, encrypted storage of privileged credentials for servers, databases, and network devices. This eliminated shared root passwords and sticky-note credentials across the enterprise.
- Session recording: Full keystroke and screen recording of privileged sessions for audit and forensic purposes.
- Privileged account discovery: Automated scanning for unmanaged privileged accounts across the estate.
- Credential rotation: Automated rotation of service account passwords on a schedule, reducing the window for credential-based attacks.
- Just-in-time checkout (traditional model): Time-limited credential checkout from the vault for specific sessions.
- Approval workflows: Human-in-the-loop approval for access to sensitive systems.
The Architecture It Was Designed For
Traditional PAM was built for a world that looked like this:
- Static, named infrastructure (physical servers, VMs with persistent IPs, on-premise databases).
- Windows Active Directory-centric identity model.
- Small number of privileged users (sysadmins, DBAs) accessing a relatively stable set of systems.
- Long-lived credentials that could be vaulted, rotated, and checked out.
- Network perimeter that bounded the blast radius of a compromised credential.
That was the right answer for that world. The challenge is that cloud infrastructure operates on fundamentally different principles.
Traditional PAM is excellent at managing secrets in a world where secrets need to exist. The cloud-native answer is eliminating the secret entirely — and that requires a different architecture.
How Cloud Infrastructure Broke Every PAM Assumption?
This is the core of the problem. Each gap below is a structural architectural mismatch, not a failure of PAM vendors. The right framing is: “PAM was built for X. Cloud is Y. X ≠ Y.”
Gap 1: Ephemeral Infrastructure - No Named Resources to Vault
Traditional PAM vaults credentials for named, persistent resources. Cloud infrastructure is ephemeral, lambda functions spin up and terminate in seconds, containers live for minutes, autoscaling groups create and destroy instances dynamically.
There is no persistent server to vault credentials for. The PAM model assumes something to point at. Cloud often provides nothing persistent enough to point at.
Gap 2: IAM Roles Are Not Passwords, But PAM Treats Everything Like One
AWS IAM roles, Azure managed identities, and GCP service accounts operate on a fundamentally different model than the username/password paradigm PAM was built around.
IAM roles are assumed, not checked out. STS tokens are generated on-demand. Vaulting a credential that doesn’t persistently exist is architecturally incoherent. And traditional PAM has no native model for time-bound role elevation across cloud IAM surfaces.
Gap 3: Developer Velocity vs. PAM Friction
Traditional PAM was deployed for a small population of privileged administrators: sysadmins and DBAs, who could tolerate workflow friction as the price of access governance.
Cloud environments democratize infrastructure access. Developers need cloud console access, database connections, and Kubernetes namespace access as part of daily work. PAM’s checkout-and-approval model, designed for a handful of privileged admins, creates unbearable friction at developer scale and engineers route around it.
When engineers route around your security controls, you don’t have a security program. You have a compliance theater.
Gap 4: Non-Human Identities Are Completely Outside PAM’s Scope
Modern cloud environments have more non-human identities than human ones. CI/CD pipelines, Lambda functions, Kubernetes service accounts, API keys, OAuth tokens, and increasingly, AI coding agents.
Traditional PAM has no architecture for governing NHI access at cloud scale. These identities operate with long-lived credentials, often hardcoded, often with excessive permissions, and PAM’s vault model simply wasn’t designed for them.
Gap 5: AI Coding Agents - The Gap No PAM Tool Has an Answer For
In 2026, AI coding agents such as Claude Code, Cursor, Copilot, Kiro, or Codex are operating in production engineering environments with live cloud credentials. They read repositories, call cloud APIs, and ship PRs.
A long-lived AWS key in a .envrc file accessed by an agent is the privileged session PAM was designed to control; except PAM has no model for an agent-initiated session, no on-host DLP to intercept credential exfiltration, and no MCP integration to broker JIT credentials to agents.
This is the newest and fastest-growing privileged access surface that no traditional PAM tool addresses today.
Gap 6: Multi-Cloud Identity Fragmentation
AWS, Azure, and GCP each have distinct IAM models (IAM roles, Entra ID, or Workload Identity) with no common privileged access primitive. Traditional PAM tools have bolt-on connectors for each cloud, but no unified identity model that spans them.
A privileged access event on AWS and the same user’s access on Azure are separate audit events in separate systems, with no cross-cloud correlation.
Gap 7: The Database Access Problem in Cloud
Traditional PAM vaulted database credentials and rotated them on a schedule. In cloud environments, this approach creates a new problem: shared, long-lived database credentials that any approved user can check out from the vault.
Dynamic PII masking at query time, destructive query prevention, and identity-attributed per-query audit trails. Things that make database access governable in a cloud-native way are outside PAM’s architecture entirely.
In a traditional data center, PAM needed to manage 50 privileged admins accessing 200 servers. In a cloud environment, it needs to manage 500 developers, 10,000 ephemeral resources, 50,000 NHI credentials, and now AI coding agents. The math doesn’t work — and neither does the architecture.
Where Traditional PAM Still Belongs?
Honesty builds trust. Traditional PAM is not wrong, it is scoped for a world that is shrinking. Here’s where it still earns its keep:
- On-premise legacy infrastructure: Physical servers, legacy databases, network devices with static credentials - PAM’s vault model is the correct control for these environments.
- Windows AD-centric enterprise environments: Active Directory privileged account governance, domain admin session control, and Windows-native credential rotation remain core PAM strengths.
- Contractor and vendor access to sensitive on-premise systems: Time-limited vault checkout with session recording remains the right model for external party access to legacy systems.
- Compliance in regulated industries with legacy infrastructure: HIPAA, PCI-DSS, and SOX controls for on-premise privileged access are well-mapped to traditional PAM capabilities.
The Honest Framing
Traditional PAM is not wrong — it is scoped for a world that is shrinking. The right enterprise security architecture for most organizations in 2026 is traditional PAM covering the on-premise estate and cloud-native JIT covering the cloud, container, SaaS, and AI-agent surface.
These are complementary controls, not competing ones — until the on-premise estate is gone.
What Does Cloud-Native Privileged Access Actually Requires?
If traditional PAM is the wrong architecture for cloud, what does the right architecture look like? Here are the seven requirements that define cloud-native privileged access in 2026.
1. Zero Standing Privilege by Design
The goal is not to vault credentials, it is to eliminate them. Cloud-native privileged access means no persistent admin credentials exist to steal. Every elevated session is time-bound, scoped, and auto-revoked. The absence of a credential is a better control than the best vault.
2. Multi-Surface JIT Coverage
Cloud-native JIT must cover every surface where privilege can be abused: cloud consoles (AWS/Azure/GCP), databases (MS SQL, Azure SQL, PostgreSQL, MongoDB), VMs, Kubernetes namespaces, SaaS applications, non-human identities, and AI coding agents.
A JIT solution that covers only cloud IAM roles is not solving the problem, it is solving 20% of it.
3. Developer-Native Approval Workflows
Access requests and approvals must live where engineers and security teams already work “Slack, Microsoft Teams” not in a separate PAM portal that creates friction and drives shadow access patterns. The workflow must be fast enough that JIT is not a blocker to engineering velocity.
4. Identity-Attributed Audit Trail Per Session and Per Query
Every elevated session must generate an identity-attributed audit record: who requested, who approved, what resource, what actions were taken, when the session ended. For database access specifically, this means per-query attribution, and not just session-level logging.
5. NHI and AI Agent Coverage
JIT must extend beyond human identities. CI/CD pipelines, service accounts, Lambda functions, and AI coding agents need the same time-bound, scoped credential model as human users. Long-lived NHI credentials are the standing privilege problem of 2026.
6. Unified with Posture and Identity Intelligence
Cloud-native JIT should not be a standalone tool. It should be integrated with the CSPM/CIEM asset graph, so the approval engine knows whether the resource being accessed has an open misconfiguration, an unpatched CVE, or anomalous access history. A JIT approval without that context is approving access in the dark.
7. Compliance Evidence Without Manual Assembly
Every JIT session should auto-generate audit evidence mapped to the relevant compliance control — SOC 2 CC6.3, ISO 27001:2022 Control 5.18, HIPAA access control requirements, DPDPA data access obligations. Evidence collection should not be a manual exercise at audit time.
The Cloudanix Approach: Cloud-Native JIT on a Unified CNAPP+ Graph
Cloudanix approaches privileged access not as a PAM replacement, but as a cloud-native JIT primitive built on top of a unified CNAPP+ asset graph. The difference matters architecturally: JIT that is integrated with posture, identity intelligence, and behavioral monitoring is fundamentally different from JIT as a standalone access broker.
JIT as a First-Class Primitive: Not a Feature
What this means in practice:
- JIT is not a module bolted onto a CSPM tool: it runs on the same asset graph as posture, identity, code, and data monitoring.
- The approval engine has full context: The resource being accessed, its current misconfiguration status, the identity’s risk score, historical access patterns, and any active threat intelligence on related assets.
- Coverage is genuinely multi-surface: cloud consoles (AWS/Azure/GCP/OCI), databases (MS SQL, Azure SQL, PostgreSQL, MongoDB), VMs, Kubernetes namespaces, SaaS applications, non-human identities, and AI coding agents via MCP.
- Approval brokered through Slack/Teams: one-click approval in the tool engineers already live in, with full context presented to the approver.
- Auto-revocation by design: No manual cleanup, no forgotten open sessions, no credential that outlives its purpose.
The NHI Problem Solved
Non-human identities are the standing privilege problem most PAM tools ignore:
- CI/CD pipelines, Lambda functions, Kubernetes service accounts, API keys, OAuth tokens; all operating with long-lived credentials.
- Cloudanix extends the JIT model to NHIs: scoped, time-bound credentials for automated workloads, with the same approval and audit trail as human access.
- The result: No long-lived service account credentials in your cloud environment for humans or machines.
The AI Coding Agent Surface: The Gap Only Cloudanix Closes
This is the 2026 privileged access problem no traditional PAM tool has answered:
- AI coding agents (Claude Code, Cursor, Copilot, Kiro, Aider) operate with live cloud credentials, reading repositories and calling cloud APIs during active sessions.
- Cloudanix’s Coding Agent Firewall: on-host DLP that intercepts credential and PII exfiltration before a token leaves the developer’s machine.
- Agentic JIT via MCP: Agents receive scoped, time-bound credentials rather than long-lived keys, the same zero-standing-privilege model applied to the newest identity surface.
- Full audit trail: What the agent accessed, what credential it used, what calls it made, when the session closed.
This capability ships today. No other CNAPP or PAM tool in the market has an equivalent.
Database Access Beyond Vaulting
Traditional PAM vaults database credentials. Cloudanix eliminates them:
- Keyless database access from the IDEs engineers actually use: DBeaver, DataGrip, TablePlus, pgAdmin - no shared passwords, no credential checkout.
- Dynamic PII masking at query time: Sensitive columns masked before they reach the querying user, regardless of their access level.
- Destructive query prevention blocks
DROP TABLE,DELETE *, and similar at execution. - Identity-attributed per-query audit trail stored in the customer’s own S3? Cloudanix never holds the audit data.
Customer proof point: Moneyview (FSI, India) — 100% elimination of standing privilege across cloud and database tiers via Cloudanix JIT.
Compliance Evidence Auto-Generated, Not Manually Assembled
Every JIT session and every database access event generates structured, identity-attributed audit evidence:
- SOC 2 CC6.3: (Logical and Physical Access Controls) time-bound access with approval trail and auto-revocation.
- ISO 27001:2022 Control 5.18: (Access Rights) provisioning, review, and revocation evidence per identity per session.
- HIPAA Access Control: Identity-attributed database access audit per query.
- DPDPA (India): Data masking, audit trail, and data sovereignty requirements addressed natively.
Customer proof point: Eversana (Healthcare, 80+ AWS accounts + Azure/GCP) — HIPAA audit prep reduced from weeks to hours.
The CNAPP+ Advantage: JIT in Context
What separates Cloudanix’s JIT from any standalone JIT or PAM tool:
- The approval engine queries the unified asset graph before approving a JIT request, Cloudanix knows whether the target resource has an active misconfiguration, a CVE on an adjacent workload, or an anomalous access history.
- UEBA v2 identity risk score (0–100) factors into access decisions. A high-risk identity gets escalated approval requirements automatically.
- 1.13M+ IOCs across 30 threat feeds inform access decisions in real time.
- All of this runs on one asset graph, not a JIT tool calling a separate CSPM API.
Deployment in 30 Minutes, Not 6 Months
Traditional PAM deployments run 3–12 months, require professional services, and impose agent footprint on every managed system. Cloudanix JIT:
- 30-minute agentless deployment: Read-only IAM connector, no agents for cloud/CIEM/posture coverage.
- First findings same day.
- JIT module enabled incrementally: Start with your highest-risk access, expand to full coverage.
- No rip-and-replace of existing PAM: For on-premise, extend cloud-native JIT alongside it.
Customer proof point: “Kapittx” 1-click onboarding across multi-cloud/multi-account, ~5 hours/week/resource saved, full coverage with minimal security headcount.
PAM vs. Cloud-Native JIT Side-by-Side
This comparison is not a dismissal of traditional PAM — it is an architectural clarity exercise. Both tools exist. Understanding where each applies is the foundation of a coherent privileged access strategy in 2026.
| Dimension | Traditional PAM (CyberArk, BeyondTrust, Delinea) | Cloud-Native JIT (Cloudanix) |
|---|---|---|
| Primary design era | On-premise, static infrastructure (2000s - 2010s) | Cloud-native, ephemeral infrastructure (2020s) |
| Credential model | Vault, rotate, checkout | Eliminate standing credentials entirely |
| Cloud IAM coverage | Connector-based, limited | Native: AWS/Azure/GCP/OCI role elevation |
| Ephemeral infra support | Minimal: assumes persistent named resources | Native: designed for ephemeral, dynamic resources |
| NHI / service account JIT | Not designed for this | Native coverage |
| AI coding agent coverage | None | JIT via MCP + Coding Agent Firewall |
| Database access model | Credential vault + session record | Keyless access + dynamic PII masking + per-query audit |
| Developer workflow integration | Separate PAM portal (high friction) | Slack/Teams approval (zero workflow change) |
| Deployment time | 3 - 12 months + professional services | 30 minutes, agentless |
| Agent footprint | Agent on every managed system | Agentless for cloud/CIEM/posture |
| Compliance evidence | Session recordings + checkout logs | Per-session + per-query identity-attributed audit, auto-mapped to frameworks |
| Multi-cloud parity | Connector-by-connector | Native unified model across AWS/Azure/GCP/OCI |
| Integration with posture/CIEM | Separate tool, no graph integration | Same asset graph as CSPM/CIEM/Code/DAM |
| AI agent support | None | Coding Agent Firewall + Agentic JIT via MCP |
| Pricing model | Per-seat, per-vault, high TCO | Modular, consumption-based |
The right question isn’t “PAM or JIT?” It’s “PAM for what, and JIT for what?” Traditional PAM governs the on-premise estate. Cloud-native JIT governs everything built after 2015, and everything being built today.
Building Your Privileged Access Strategy for Cloud: A Practical Framework
This is the action plan. Whether you’re the security engineer building the internal business case or the CISO evaluating your next investment, these six steps will get you from gap identification to coverage.
Step 1: Audit Your Current Privileged Access Surface
Map where privileged access actually lives in your environment today across four categories:
- Human privileged access: Cloud console admin, database DBA, Kubernetes cluster admin, SaaS admin.
- Non-human privileged access: CI/CD pipeline credentials, service accounts, Lambda execution roles, and API keys.
- AI coding agent access: Which agents are active, what cloud credentials do they use, are they long-lived keys or scoped tokens?
- Legacy on-premise privileged access: Servers, on-prem databases, network devices still covered by PAM.
Step 2: Identify Standing Privileges
For each category above, answer: Which of these identities has persistent, always-on access? Every standing privilege is a credential waiting to be compromised.
Step 3: Prioritize by Blast Radius
Not all standing privileges are equal. Start with: production database access, cloud console root/admin accounts, and any NHI with cross-account or cross-cloud permissions. These are your highest blast-radius credentials.
Step 4: Match the Right Control to the Right Surface
- On-premise, static infrastructure → traditional PAM stays in place
- Cloud consoles, databases, VMs, K8s, SaaS, NHIs → cloud-native JIT
- AI coding agents → Agentic JIT via MCP + Coding Agent Firewall
Step 5: Define Your Audit Evidence Requirements Before Selecting Tooling
Know which compliance frameworks you need to satisfy and what evidence they require. SOC 2 CC6.3, ISO 27001:2022 Control 5.18, HIPAA, and DPDPA all have specific access control evidence requirements that your JIT tooling must generate automatically, and not require manual compilation.
Step 6: Run a PoC on Your Highest-Risk Access First
JIT ROI is fastest when deployed against your most consequential standing privilege. Book a 30-minute assessment. Cloudanix connects agentlessly and surfaces your standing privilege picture on day one.
The Compliance Angle: What Auditors Are Now Asking For?
The compliance bar has shifted significantly beyond traditional PAM evidence. Here’s what each framework now requires, and where traditional PAM falls short.
SOC 2 (CC6.3 - Logical and Physical Access Controls)
Auditors now ask for evidence of time-bound access, approval trail per elevation, and auto-revocation, not just session recordings. Traditional PAM checkout logs satisfy this partially; JIT with per-session structured audit output satisfies it completely.
ISO 27001:2022 Control 5.18 (Access Rights)
The 2022 update requires documented evidence of access rights provisioning, periodic review, and revocation per individual identity. A PAM vault checkout log is not the same as a JIT session record with identity, scope, approver, duration, and auto-revocation timestamp.
HIPAA (Access Control — §164.312(a))
Identity-attributed audit of access to ePHI including database access at query level is required. Traditional PAM provides session recording; cloud-native DAM + JIT provides per-query identity attribution.
DPDPA (India: mid-2027 enforcement)
INR 250 crore penalty exposure. Data masking, identity-attributed database access audit, and data sovereignty are all mandated. Traditional PAM has none of these natively for cloud database access.
PCI-DSS v4.0 (Requirement 7 - Restrict Access to System Components)
Access to cardholder data on a need-to-know basis, standing database credentials directly fail this control regardless of whether they’re vaulted.
SOC 2 auditors don’t want to see your PAM vault inventory. They want to see that privileged access is time-bound, approved, and auto-revoked. Those are JIT evidence artifacts, not PAM evidence artifacts.
Decision Guide: Who Needs What?
Extend Traditional PAM If:
- You have significant on-premise infrastructure that is not moving to cloud in the near term.
- Windows AD-centric privileged account governance is a primary requirement.
- Contractor/vendor access to legacy on-premise systems requires session recording.
- Your security team has deep PAM expertise and the on-premise estate justifies continued investment.
Add Cloud-Native JIT (Cloudanix) If:
- You are operating on AWS, Azure, GCP, or any combination; and your PAM tool’s cloud coverage is connector-based and incomplete.
- Developers are complaining that privileged access workflows are slowing them down.
- You have NHI credentials (service accounts, CI/CD pipelines, API keys) without a JIT governance model.
- AI coding agents are active in your engineering environment.
- Your compliance frameworks require identity-attributed database access audit and dynamic PII masking.
- Your organization is under DPDPA, HIPAA, or ISO 27001:2022 obligations for cloud data access.
- You need JIT evidence auto-generated for SOC 2/ISO audit cycles, not manually compiled.
Replace Traditional PAM with Cloud-Native JIT If:
- Your infrastructure is cloud-only or cloud-dominant with minimal on-premise footprint
- The TCO of maintaining traditional PAM agents for a shrinking on-premise estate no longer justifies the cost
Conclusion
Traditional PAM solved a critical problem for the infrastructure world that existed when it was built. That world of static, on-premise, Active Directory-centric is still real for many organizations. PAM should stay where it earns its keep.
But cloud infrastructure which is ephemeral, multi-cloud, identity-centric, developer-velocity-driven, NHI-dominated, and now AI-agent-extended requires a different architecture. Vaulting credentials that don’t persist, applying checkout workflows to IAM roles, and deploying agents on autoscaling infrastructure are architectural mismatches. They don’t fail because PAM vendors built a bad product. They fail because the problem changed.
Cloud-native JIT built on a unified asset graph, covering human and non-human identities and AI coding agents, generating clean compliance evidence per session and per query is the privileged access control cloud infrastructure actually needs.
See your standing privilege picture in 30 minutes.
Cloudanix connects agentlessly with a read-only IAM role and surfaces your highest-risk standing privileges the same day! No agents, no lengthy deployment, no rip-and-replace of your existing PAM.
Explore the Cloudanix JIT Deep Dive →
People Also Read
- What is Just-In-Time (JIT) Access?
- Understanding Privileged Access Management: How PAM Secures Your Data
- From Static to Strategic: Modernizing Privileged Access for Cloud Infrastructure
- Unauthorized Privilege Escalation & Secure Elevation: A Blueprint for Cloud Security Leadership
- Streamlining Just-in-Time Access: Balancing Security and Developer Workflow Integration
- Database Activity Monitoring: Real-Time Data Security
- Understanding CIEM: Cloud Infrastructure Entitlement Management
- Migrating from Chaotic IAM to Streamlined, Role-Based Just-in-Time Access
