They should prioritise a full identity and access baseline before adding new automation or AI use cases. That means inventorying accounts, surfacing policy violations, removing orphaned access, and defining who owns each identity type. Without that foundation, AI assistants and research agents are likely to inherit the same weak controls that already exist in legacy identity processes.
Why IAM and PAM Modernisation Fails Without an Identity Baseline
CISOs and IT directors should treat IAM and PAM modernisation as a sequencing problem, not a tooling purchase. If account inventory is incomplete, ownership is unclear, and orphaned access remains hidden, automation simply accelerates bad state. The first priority is to establish a trustworthy baseline for every human and non-human identity, then remove obvious policy violations before layering AI-driven workflows or cloud expansion on top.
That baseline matters because cloud and AI adoption multiply the number of identities that can create, approve, query, or move data. In practice, the same weak control environment often governs service accounts, API keys, privileged cloud roles, and the assistants that now depend on them. Research from The 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or only match human IAM, and 59.8% see value in dynamic ephemeral credentials. Those gaps become more dangerous when AI is introduced before ownership and access scope are made explicit.
In practice, many teams discover their identity weaknesses only after a new cloud or AI use case has already inherited them, rather than during deliberate identity governance.
How to Sequence the First Modernisation Steps
The practical order is straightforward: inventory first, classify second, remediate third, then automate. Start by identifying every identity type in scope, including workforce users, administrators, service accounts, application credentials, API keys, machine identities, and emerging AI agents. Next, map each identity to a named owner and a business purpose. If an identity cannot be attributed to an owner or a function, it is already a control gap.
Once the inventory is visible, surface policy violations that are easy to prove and hard to argue with. Examples include standing privileged accounts, unused accounts, shared secrets, excessive role grants, and credentials that never expire. This is where PAM and IAM should converge: privileged access should not be treated as a separate island when the same cloud control plane can be reached by multiple identity types.
Cloud and AI adoption also require shorter-lived access patterns. Static credentials create long blast-radius windows, while ephemeral credentials and just-in-time elevation reduce the duration of misuse. The point is not to automate every grant immediately, but to make every grant explainable, time-bound, and revocable. If the organisation cannot answer who can assume a role, under what policy, and for how long, it is not ready to delegate that access to an AI workflow.
Framework guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls supports this sequence by tying access control, accountability, and configuration management to measurable control outcomes. For a broader NHI lens, the same baseline logic is reflected in The 2026 Infrastructure Identity Survey, which reports that 67% of organisations still rely heavily on static credentials despite the risk to agentic AI deployments.
These controls tend to break down when cloud teams, platform teams, and security teams each own different parts of the identity lifecycle because no single group maintains the full access picture.
What to Fix Before AI Use Cases Get a Free Pass
Tighter identity control often slows early delivery, so organisations have to balance speed against the cost of amplifying existing privilege sprawl. The common mistake is to approve an AI pilot because it appears low risk, then let it inherit broad cloud roles, long-lived secrets, and undocumented service access.
The most important edge case is that not every identity should be handled the same way. Human users, privileged admins, workloads, and AI agents require different policies, but they all depend on the same governance basics: ownership, least privilege, monitoring, and revocation. Best practice is still evolving for agentic systems, yet current guidance clearly favours short-lived credentials and real-time access decisions over static entitlement inheritance.
Another frequent failure is assuming PAM can compensate for weak IAM. PAM can reduce exposure for privileged sessions, but it cannot repair an incomplete inventory or a broken ownership model. Likewise, AI security controls are not effective when the underlying accounts, tokens, and roles are already over-permissioned. Prioritise the identities that can change production systems, access sensitive data, or mint further credentials, because those are the paths that turn a governance gap into an operational incident.
Practitioner takeaway: Modernisation should begin where blast radius is largest, not where automation is most available. If identity ownership and privilege scope are still unclear, AI and cloud adoption will expose that weakness faster rather than fixing it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Directly addresses inventorying, least privilege, and access governance before automation. |
| 5 — Account Management | Applies to orphaned accounts, ownership, and lifecycle control across identity types. | |
| 8 — Audit Log Management | Supports surfacing policy violations and verifying privileged access behaviour. | |
| Recommendation — Inventory identities and remove excess access before expanding cloud or AI usage. Assign ownership and lifecycle responsibility for every account and identity type. Enable logging that proves who accessed what and when during modernisation. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Covers identity baseline, access scope, and privileged access governance. |
| GV.OV — Governance Oversight | Fits executive prioritisation, ownership clarity, and control accountability. | |
| Recommendation — Establish identity governance and least privilege before adding new AI workflows. Define ownership and oversight for identity risk before delegating automation. | ||
| NIST Zero Trust (SP 800-207) | 4 — Access Control Principles | Aligns with zero trust access decisions and reducing implicit trust in cloud estates. |
| Recommendation — Move access decisions toward explicit, context-based verification and minimal privilege. | ||
| NIST AI RMF | GOVERN — Govern AI Risk | Relevant because AI adoption should be governed before autonomous use cases expand. |
| Recommendation — Set AI governance guardrails before allowing agentic access to production systems. | ||
| OWASP Agentic AI Top 10 | A1 — Excessive Agency | Applies when AI assistants inherit overly broad permissions and autonomous reach. |
| Recommendation — Constrain agent permissions so AI cannot inherit broad standing privileges. | ||
