TL;DR: Developers are being asked to treat identity as code, unify visibility across humans, machines, and AI, and enforce just-in-time access as software systems and non-human identities proliferate, according to SailPoint. The governance challenge is no longer whether identity can be automated, but whether lifecycle, policy, and remediation can keep pace with runtime behaviour.
At a glance
What this is: This is a developer-focused identity security blog arguing that adaptive identity is becoming a control layer for non-human identities, AI usage, and code-driven access governance.
Why it matters: It matters because IAM, IGA, and PAM teams increasingly have to govern machine and AI access as engineering practices, not just as admin workflows.
Context
The core problem is that identity governance is being pushed into software delivery and runtime operations. As machines, service accounts, bots, and AI agents multiply, access decisions can no longer depend on manual administration or periodic review alone.
In the article’s framing, developers are moving from using identity tools to embedding identity controls into code, pipelines, and remediation workflows. That shifts the governance question from who can log in to how access is issued, monitored, and corrected as systems change.
Key questions
Q: How should security teams implement identity as code in developer workflows?
A: Start by moving access policy definitions, approval logic, and remediation triggers into version-controlled workflows that can be tested and reviewed before deployment. Keep the policy source separate from ad hoc admin changes, then tie releases to change control so identity decisions follow the same discipline as application code.
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 breaks when shadow AI is not included in identity governance?
A: When shadow AI is excluded, the organisation loses discovery, ownership, and enforcement at the same time. Unmanaged local agents can access cloud and SaaS resources without being enrolled in policy, which means no one can attest to their privileges or revoke them cleanly. The first failure is visibility, and the second is accountability.
Q: How can teams tell whether adaptive identity is actually improving control?
A: Look for evidence that access decisions, anomaly detection, and remediation are happening in the same operational flow rather than in separate manual queues. If policy changes still depend on ticket backlogs or periodic cleanup, the programme is automating administration but not governance.
Technical breakdown
Identity as code turns access policy into deployable control
Identity as code means access rules, policy logic, and remediation behaviour are managed like application code, with version control, peer review, and automated deployment. In this model, policy is no longer an after-the-fact admin setting. It becomes part of the software delivery path, which makes identity governance more repeatable but also more dependent on pipeline integrity and data quality. The article frames least privilege as something enforced through code-driven workflows rather than isolated approval steps. Practical implication: treat identity policy changes as controlled releases, not ad hoc configuration edits.
Practical implication: treat identity policy changes as controlled releases, not ad hoc configuration edits.
Adaptive identity extends governance to service accounts, bots, and AI agents
The article’s governance model is broader than human access management. It extends visibility and remediation to non-human identities, including service accounts, bots, and AI agents, which behave differently from users because they operate continuously and often at machine speed. That matters because standing access, hidden service identities, and ungoverned automation can create exposure that traditional user-centric review cycles miss. Real-time anomaly detection and automated remediation are positioned as the operational answer to that velocity gap. Practical implication: inventory and classify non-human identities as first-class subjects in the identity programme.
Practical implication: inventory and classify non-human identities as first-class subjects in the identity programme.
Shadow AI creates an identity governance problem, not just a data policy problem
Shadow AI here is not just an application usage issue. It is an identity and access problem because unmanaged AI tools may receive data, permissions, or contextual access outside approved governance paths. The article ties discovery of sanctioned and unsanctioned AI usage to automated remediation, which reflects a broader shift from blocking tools to governing their identity footprint. That is a meaningful distinction for IAM and security leaders because the control objective becomes trustworthy access enforcement, not simple prohibition. Practical implication: govern AI tool usage through identity controls, approval paths, and remediation triggers.
Practical implication: govern AI tool usage through identity controls, approval paths, and remediation triggers.
NHI Mgmt Group analysis
Identity governance is becoming a software delivery discipline. When access policy is version-controlled and deployed through CI/CD, the control plane moves from console administration to engineering workflow. That changes how teams should think about drift, review, and enforcement because the governance boundary is now code quality as much as policy design. Practitioners should treat identity engineering as part of the release system, not a separate back-office function.
Non-human identity visibility is now a prerequisite for modern governance. Service accounts, bots, and AI agents are not edge cases once they become core execution identities across on-prem and multi-cloud environments. The article reflects a structural reality: user-only visibility leaves a large part of the access estate unmanaged. The implication is that identity programmes must govern machine identities with the same operational seriousness once reserved for privileged human access.
Shadow AI is an identity problem because unmanaged tools create unmanaged access paths. Discovery alone is not enough when sanctioned and unsanctioned AI usage can both move data outside expected control boundaries. The named concept here is runtime identity governance: identity controls that operate at the point of execution rather than after periodic review. Practitioners should recognise that AI adoption is now testing whether their governance model can act at runtime.
Least privilege becomes enforceable only when sensitivity context is attached to issuance. The article’s emphasis on real-time data sensitivity shows why static entitlement models are not enough for dynamic engineering environments. Access decisions must reflect current task scope and asset sensitivity, especially when humans, machines, and AI are all interacting in the same environment. Practitioners should align entitlement controls with live context, not just role assignment.
Developer identity tooling is now part of the security operating model. The article links developer communities, APIs, CLI tooling, and support resources to operational identity control, which signals that governance is being built into the developer experience itself. That is not a convenience issue. It is a recognition that policy adoption rises when identity control becomes native to engineering practice. Practitioners should evaluate identity programmes on how well they fit developer workflows, not just on administrative completeness.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Identity Security Programme Guide
What this signals
Runtime identity governance: The article points to a model where identity controls have to operate at the moment of execution, not just at provisioning or review time. That shift matters for developer programmes because machine identities and AI tools can create access decisions faster than manual governance can observe them.
Developer security teams should expect identity policy to move closer to code review, pipeline controls, and remediation automation. When that happens, the programme stops being a set of admin tasks and becomes part of the engineering control plane.
The practical test is whether your identity controls still depend on human-paced cleanup. If access for service accounts, bots, or AI tools is not governed in the same delivery path as code, the gap will keep widening.
For practitioners
- Embed identity policy in delivery pipelines Version-control access rules, require peer review for policy changes, and deploy them through the same release process used for application code.
Key takeaways
- Developer-led identity governance is shifting from console administration to code-driven control, which changes where policy is written and enforced.
- Non-human identities and shadow AI expand the access estate beyond what human-centric review cycles can reliably cover.
- The control question is whether identity policy, visibility, and remediation are part of the execution path, not whether automation exists at all.
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 CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The post centres on governing service accounts, bots, and other non-human identities with least privilege. |
| NHI-10 — Human Use of NHI | Developer workflows and shadow AI can blur who is using non-human access paths and for what purpose. | |
| Recommendation — Map machine and service access to NHI-05 and remove standing privilege from non-human identities. Separate human and machine use of NHI credentials and block shared access paths. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The article discusses hidden identities, remediation, and access paths that can lead to misuse and impact. |
| Recommendation — Hunt for exposed non-human credentials and constrain the blast radius of any identity abuse. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core governance theme is entitlement control across human and non-human identities. |
| Recommendation — Apply entitlement review and authorization controls to all developer-managed access paths. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article describes cross-environment governance of identities in cloud and multi-cloud operations. |
| Recommendation — Extend cloud IAM controls to service accounts, bots, and AI-facing access flows. | ||
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.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
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 August 17, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org