Adaptive identity for developers is becoming an NHI control layer

At a glance

What this is: SailPoint argues that identity security is shifting toward adaptive, code-driven governance for developers who must manage humans, machines, and AI through the same control plane.

Why it matters: For IAM, IGA, PAM, and NHI teams, this matters because code-based identity policy only works if visibility, remediation, and review extend across service accounts, bots, and AI agents.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read SailPoint's full blog on adaptive identity for developers and NHI governance

Context

Adaptive identity means treating access policy, identity context, and remediation logic as part of the software delivery process rather than a manual admin task. That matters because developers are now building systems that must govern service accounts, bots, AI agents, and human users through one operating model, not separate silos.

The governance gap is that most identity programmes still assume identities are comparatively stable, reviewable, and easy to place inside fixed lifecycle processes. Once identity decisions happen in code and runtime systems, visibility, least privilege, and offboarding all depend on whether the organisation can govern non-human identities with the same discipline it applies to human access.

For a broader baseline on service accounts, tokens, and workload identities, see the Ultimate Guide to NHIs.

Key questions

Q: How should security teams integrate identity controls into DevOps pipelines?

A: Start by moving identity checks to the earliest practical stage in delivery, such as pre-merge, build, or pre-deploy gates. Focus on the controls that most often create operational risk, including service account permissions, secret exposure, and deployment credentials. The goal is to make secure identity behaviour the default path for release, not a separate review step.

Q: Why do service accounts and AI agents need different controls from human users?

A: Service accounts and AI agents authenticate and act without the predictable patterns that human identity systems expect. They can operate across runtimes, scale quickly, and carry permissions into automated workflows. That means access decisions should consider workload context, runtime behaviour, and time-bound authority rather than relying only on user-centric IAM patterns.

Q: What do security teams get wrong about Shadow AI?

A: They often treat Shadow AI as an approval problem for software, when it is usually also an identity problem. The hidden risk can be an undocumented token, an over-permissioned service account, or an autonomous agent with unreviewed reach. Inventory the identity layer before you decide the tool is the issue.

Q: How do security teams know if just-in-time access is actually working?

A: Look for short-lived sessions, automatic revocation, and complete request-to-access logs. If approvals are still creating durable permissions, or if teardown depends on manual cleanup, then the programme is only partially ephemeral. Effective JIT should leave little or no reusable privilege behind after the task ends.

Technical breakdown

Identity-as-code in CI/CD pipelines

Identity-as-code means access policy, role assignment, and entitlement logic are versioned and deployed like application code. In practice, that shifts identity decisions into CI/CD pipelines, where peer review, test gates, and configuration drift detection can be applied before access reaches production. The hard part is that identity policy now depends on source control quality, pipeline integrity, and change discipline, not just IAM administration.

Practical implication: treat identity policy changes as code changes and require review, testing, and rollback control before deployment.

Real-time governance for service accounts, bots, and AI agents

Non-human identities behave differently from human users because they can be created in bulk, reused across environments, and left active long after their original purpose ends. Real-time governance therefore needs inventory, classification, and remediation workflows that can act on service accounts, API tokens, certificates, and bots before privilege becomes stale. For AI agents, the same model must account for runtime access patterns and tool use across multiple systems.

Practical implication: maintain a current inventory of non-human identities and connect it to automated review and revocation workflows.

Shadow AI discovery and remediation controls

Shadow AI is the unmanaged use of AI tools or agents that bypass formal governance and create hidden access paths to data and systems. Discovery alone is not enough. The security model has to pair detection with remediation logic that can disable, constrain, or reclassify the identity path carrying the AI workload. That makes shadow AI a governance problem as much as a monitoring problem.

Practical implication: monitor sanctioned and unsanctioned AI activity together and make remediation an automated response, not a ticket queue.

NHI Mgmt Group analysis

Identity-as-code is becoming the practical control surface for NHI governance. When access policy is defined in code, the real control is no longer the admin console but the delivery pipeline, version history, and review process. That shifts governance from periodic approval to continuous change control, which is where many IAM and IGA programmes still have weak coverage. Practitioners should treat code-defined identity as a first-class control plane, not a developer convenience.

Visibility gaps remain the limiting factor for non-human identity security. The article is right to centre service accounts, bots, and AI agents together because the governance failure is the same: organisations cannot protect what they cannot inventory or classify. Full-spectrum identity visibility is still the prerequisite for lifecycle governance, remediation, and blast-radius reduction. The practitioner conclusion is simple: classification must precede automation.

Shadow AI creates an identity governance problem, not just an acceptable-use problem. Unmanaged AI tools and agents can introduce hidden identity paths, data exposure, and policy bypass outside conventional approval flows. That makes discovery, containment, and remediation part of identity governance, not a separate security side project. Teams need to treat unmanaged AI as an identity population with lifecycle obligations.

Adaptive identity only works when just-in-time access is enforced across every actor type. The article's emphasis on just-in-time and just-enough access is directionally correct because standing privilege remains the common failure mode across human and non-human estates. But the value comes from applying the same access philosophy to service accounts, bots, and developer workflows, not from isolating it to one team or one platform. Practitioners should align privileged access, IGA, and NHI governance around the same runtime policy model.

Adaptive identity broadens the developer's role from building software to governing access behaviour. That is the structural shift this article points to. Developers are no longer only consumers of IAM controls; they are now the people encoding identity policy, remediation logic, and workflow enforcement into applications and pipelines. Security teams should respond by giving developers governed primitives rather than expecting manual identity administration to scale.

From our research:

• From our research: 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For a forward view on exposure and lifecycle control, the 52 NHI Breaches Analysis shows how missing offboarding and stale access turn governance gaps into incidents.

What this signals

Identity-as-code will push more organisations to move governance decisions out of human approval queues and into automated delivery paths. That will expose weak classification, weak change control, and weak revocation faster than traditional IAM reviews can keep up.

Adaptive identity gap: the real challenge is not whether organisations can create policies for humans, machines, and AI, but whether they can enforce those policies consistently when access is created by code and consumed at runtime. Teams that still separate IAM, PAM, and NHI operations will struggle to maintain one coherent control model.

The next programme maturity test is whether identity teams can prove that non-human access is owned, time-bound, and revocable across environments. That is where the Ultimate Guide to NHIs becomes a practical baseline, especially when paired with the breach patterns in the 52 NHI Breaches Analysis.

For practitioners

• Embed identity policy into delivery pipelines Require access policy changes to move through source control, peer review, automated tests, and deployment gates before they reach production identity systems.
• Build a complete non-human identity inventory Track service accounts, API keys, tokens, certificates, bots, and AI-related identities across on-prem and multi-cloud environments, then classify each by owner, purpose, and expiry.
• Automate remediation for shadow AI and stale access Connect discovery signals to workflows that can disable, quarantine, or reissue access when unsanctioned AI activity or unowned non-human identities appear.
• Align PAM, IGA, and NHI controls around runtime access Use one policy model for just-in-time access, privileged approvals, and entitlement reviews so that standing access is removed wherever the actor is non-human.

Key takeaways

• Developer-led identity engineering is now a governance discipline, not just a delivery pattern.
• The hardest part of adaptive identity is not policy design, but proving that non-human access is inventoried, owned, and removed at runtime.
• Organisations that cannot govern service accounts, bots, and AI agents through one lifecycle model will keep accumulating hidden access risk.

Key terms

• Identity as Code: An identity management approach that expresses users, groups, policies, entitlements, and access profiles in versioned configuration files. It brings software-style change control to IAM so teams can review, test, deploy, and recover identity state more consistently across environments.
• 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.
• Adaptive Identity: An identity governance approach that changes access decisions as context changes. Instead of relying only on fixed review cycles, it uses current risk, role, behaviour, and application sensitivity to decide whether access should continue, be reduced, or be revoked.

What's in the full article

SailPoint's full blog covers the operational detail this post intentionally leaves for the source:

• Developer-facing workflow examples for using SailPoint CLI and SDKs in identity-as-code pipelines
• Operational framing for SailPoint Agentic Fabric and how it connects identity context to broader security workflows
• Examples of Shadow AI Remediation in practice, including discovery and automated remediation paths
• Details from the SailPoint Developer Community, including API documentation, forums, and builder resources

👉 The full SailPoint post covers the developer workflow, agentic fabric context, and shadow AI remediation details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.