TL;DR: Cloud complexity, feature bloat, and consultant-led implementations outpace most organisations’ ability to turn bought controls into working governance, according to Admin By Request. The real issue is not PAM itself but the gap between purchased capability and operational oversight.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Admin By Request's blog post: PAM complexity is increasingly a deployment and governance problem, with feature bloat and stalled rollouts leaving controls partially or never used.
Why it matters: PAM programmes only reduce risk when privileged access controls are actually deployed, governed, and measured across humans, workloads, and emerging agentic use cases.
By the numbers:
- Some estimates put machine identities at 100:1 against human users.
- Others push that to 2,000:1 or higher.
Context
Privileged access management is supposed to turn elevated access into something governed, reviewable, and bounded. In practice, many programmes fail when the control set becomes so complicated that teams cannot finish deployment, cannot operate it consistently, or cannot tell which features are actually in use.
That creates a governance gap rather than a technology gap. A purchased PAM platform that is only partly rolled out leaves privilege distributed across the estate without the oversight model the programme assumed. For organisations that also have service accounts, cloud admin paths, and just-in-time access ambitions, the problem is not the label on the tool but whether the operating model can support it.
The article’s examples are not unusual. As privileged estates expand and implementation work gets pushed into specialist hands, the common failure mode is a control that exists on paper but not in day-to-day access administration.
Key questions
Q: How can teams tell whether their PAM programme is actually complete?
A: A PAM programme is complete only when it covers the resources people and vendors actually use, not just the entry protocol. If access to databases, Kubernetes, cloud CLIs, and internal apps is handled elsewhere, the programme is partial even if server sessions are fully controlled and logged.
Q: Why do PAM implementations stall in large environments?
A: PAM implementations stall when account inventory, role design, and entitlement cleanup cannot keep up with the pace of change. Shared admin accounts, stale service accounts, unmanaged secrets, and exceptions for third-party access create more work than the control set grows faster than the team can standardise, so vaulting, session recording, JIT elevation, and regular recertification must be sequenced by business-critical privilege first.
Q: When does shadow AI become an access governance problem?
A: Shadow AI becomes an access governance problem as soon as the agent can authenticate to enterprise systems with real credentials. At that point, the issue is no longer only discovery. It is privileged access, revocation, and auditability, especially if the agent can reach production or sensitive data.
Q: What is the best way to prioritise privileged access controls in cloud estates?
A: Start with the highest-risk privileged paths: cloud admin roles, root-equivalent permissions, and identities that can create or change access, networking, and secrets. Then apply least privilege, separate standing admin from JIT elevation, enforce MFA, and review service accounts and automation roles that can bypass human approval. Prioritise controls where a single compromise would expose the widest set of subscriptions, workloads, or data.
Technical breakdown
Why PAM feature bloat breaks deployment
PAM platforms often start as a small set of controls around vaulting and elevated access, but enterprise rollouts accumulate session management, workflow, approvals, analytics, and cloud extensions. Each extra layer adds configuration, training, and exception handling overhead. When the implementation model depends on consultants to finish and tune the platform, the control becomes difficult to own internally. The result is not just a slower rollout but a weaker governance boundary, because the organisation cannot reliably state which privileged paths are actually controlled and which remain outside the intended process. See the PAM Buyer's Guide.
Practical implication: Treat feature scope as an operational burden, not a procurement advantage, and validate that the control set can be run by the team that will own it.
What happens when privileged access is bought but not deployed
A non-deployed PAM platform creates a false sense of coverage. The organisation may believe privilege is centralised while passwords, exceptions, and admin workflows continue outside the tool. That is a governance failure, because the control never becomes part of the actual access path. From an identity perspective, the issue is not whether a product was purchased; it is whether access decisions, credential handling, and review points were brought under a single operating model that can be audited. Absent that, the environment behaves as though PAM does not exist. See the Privileged Access Management Guide.
Practical implication: Inventory which privileged access flows remain outside the active PAM process and treat those gaps as live control failures.
Why shadow AI changes the privilege model
The article draws a useful distinction between sanctioned agents and shadow activity created by users outside formal governance. That shifts PAM thinking from static administrator accounts to runtime access points that can appear through endpoints, browsers, and local tools. For AI-enabled workflows, the privilege question is no longer only who has admin rights. It becomes which user-initiated activities can create or extend privileged reach without a reviewable approval chain. That is a different control problem from classic vault-centric PAM, and it forces identity teams to think about access origination, not just access storage. See the Privileged Session Management Guide.
Practical implication: Map where user-initiated AI activity can create privileged reach and decide which of those paths must be governed at the endpoint or session layer.
Threat narrative
Attacker objective: The objective is to preserve or exploit unmanaged privileged access paths that the organisation believes are already governed.
- Entry occurs through an under-governed privileged access stack, where complex rollout or partial deployment leaves important admin paths outside the intended control plane.
- Escalation follows when users, consultants, or shadow workflows continue to operate with access patterns the PAM programme was meant to centralise or constrain.
- Impact is persistent privilege sprawl, because the organisation cannot reliably prove which elevated paths are controlled and which remain exposed.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
PAM complexity is now a governance failure mode, not a feature debate: When a privilege programme grows beyond the team’s ability to deploy and operate it, the control boundary becomes unreliable. The issue is not whether the product exists in the procurement catalogue. It is whether access handling, approvals, and auditability are actually enforced in production. Practitioners should judge PAM by operating reality, not by purchased capability.
Feature bloat creates control drift: Every additional layer of approvals, reporting, cloud integration, or session handling raises the chance that only parts of the platform are switched on. That turns PAM into a partial control with uneven coverage across privileged paths. The field needs to treat deployment completeness as a first-class governance issue, especially where organisations rely on external expertise to finish implementation.
Vault-first thinking is no longer enough for modern privilege estates: The article’s strongest point is that many estates now contain sanctioned automation, cloud privilege, and user-created AI workflows that do not behave like classic human admin accounts. That means a privileged access management programme has to account for how privilege is introduced and used, not only where passwords are stored. Practitioners should re-evaluate whether their PAM model still matches how access is actually consumed.
Shadow AI exposes the limits of account-centric oversight: User-driven agent creation can introduce privileged behaviour without ever passing through a formal identity governance workflow. That does not mean every AI tool needs the same treatment as a domain admin account. It does mean the governance model must recognise where user activity becomes a new access path. Teams should align endpoint, identity, and PAM controls so the first sign of unauthorised privilege appears before the access expands.
Governance maturity will be measured by operational coverage, not platform size: Large installations with many features do not automatically mean strong privilege control. The market signal here is that buyers will increasingly need to ask which workflows are actually enforced, which are manual, and which are aspirational. Practitioners should expect platform sprawl to become a compliance concern when controls are purchased but not lived.
From our research library:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- Read next: PAM Buyer's Guide
What this signals
Control coverage will matter more than platform breadth: Procurement decisions are likely to shift from feature comparisons toward proof of operational enforcement. When privileged access controls are only partially active, the organisation still carries the risk, but without the visibility or auditability that justifies the programme.
Agent-driven access will push PAM beyond vault-centric design: As user-created agents and sanctioned automation proliferate, the control point moves closer to the session, the endpoint, or the workflow origin. Organisations that keep treating privilege as a static account problem will miss where access now begins.
Implementation completeness is becoming the real maturity signal: A PAM stack that is deployed, monitored, and consistently used is materially different from one that exists mainly as an installed product. Practitioners should expect future governance reviews to focus on coverage, ownership, and enforced workflow rather than feature lists.
For practitioners
- Audit deployed versus purchased PAM coverage List every privileged access flow the programme is meant to govern, then identify which flows actually pass through the live control set and which still rely on manual handling or exceptions.
- Reduce feature scope to what operations can own Strip out features that create training, tuning, or exception overhead unless they are required for the core privileged access workflow and can be supported by the internal team.
- Inventory privileged paths outside the vault Trace direct admin access, break-glass use, cloud console elevation, and sanctioned automation to find where privilege still bypasses the intended PAM process. See the Service Account Security Guide.
- Add endpoint visibility for shadow AI activity Use endpoint and device policy controls to spot user-created agents or AI-enabled workflows that may create privileged reach outside formal identity governance.
- Define ownership for every privileged workflow Assign a named operational owner to each elevated access path so the programme can be measured by control coverage rather than by platform purchase status.
Key takeaways
- PAM complexity becomes a control problem when the organisation cannot fully deploy or operate the platform it bought.
- Partial rollouts and feature bloat leave privileged access paths outside the intended governance model.
- The practical test is whether the team can prove enforcement across real privileged workflows, not whether the platform has been purchased.
Related NHI Mgmt Group resources: PAM Buyer's Guide · Privileged Access Management Guide · Service Account Security Guide · Privileged Session Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | PAM complexity often leaves excessive privilege in place when controls are only partially deployed. |
| NHI-07 — Long-Lived Secrets | Vault-centric PAM exists to reduce persistent credential exposure, which this post treats as a governance failure when undeployed. | |
| Recommendation — Review privileged paths for overprivilege and remove any access that remains outside enforced PAM controls. Shorten credential lifetime and ensure rotation actually occurs inside the live PAM workflow. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The post is fundamentally about elevated access that is broader or more persistent than required. |
| Recommendation — Enforce least privilege on every privileged workflow, including cloud admin and automation paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The governance issue is whether privileged entitlements are correctly controlled and enforced in practice. |
| Recommendation — Validate that privileged entitlements are authorized, tracked, and removed when they are no longer needed. | ||
| MITRE ATT&CK | TA0004;TA0008 — Privilege Escalation; Lateral Movement | Uncontrolled privileged paths create conditions for escalation and broader movement once access is abused. |
| Recommendation — Map unmanaged privileged paths to escalation and lateral movement opportunities in detection and review. | ||
Key terms
- Privileged Access Management: Privileged Access Management is the discipline of controlling who can use powerful accounts and what they can do with them. It governs administrator and service access through least privilege, approval workflows, session controls, credential rotation, and auditing, reducing the risk of misuse, lateral movement, and unauthorized changes across systems.
- Just-in-Time (JIT) Access: Just-in-Time (JIT) Access grants permissions only when needed and removes them after use. In IAM and PAM, it reduces standing privilege by issuing time-bound access based on approval, context, or policy, limiting exposure for humans, service accounts, and non-human identities while improving auditability and control.
- Zero Standing Privilege: A control model in which an identity does not keep persistent access unless it is actively needed. For NHIs, this means credentials and permissions are issued for a narrow task and then removed. It reduces the time window and reuse value of stolen access.
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org