TL;DR: AI systems still depend on familiar identity primitives, but service principals, managed identities, access keys and OAuth consent are now spreading across pods, SaaS tools and third-party tenants, creating three overlapping blind spots for IAM teams according to Oasis Security. The real issue is not the AI label, but the assumption that identity flows remain visible, stable and centrally governable.
At a glance
What this is: This is a governance analysis of how AI, cloud-native, and traditional NHI patterns all expose the same identity blind spots through hidden credentials and fragmented lifecycle control.
Why it matters: It matters because IAM, PAM and NHI programmes have to govern service principals, tokens, and OAuth consent as one lifecycle problem rather than three separate technology stacks.
Context
Non-human identity governance breaks down when credentials outlive the systems and workflows they were created for. In this article, the problem is not a single tool or platform. It is the assumption that service accounts, managed identities, access keys and OAuth grants stay visible, stable and centrally governed as they move across cloud-native, SaaS and AI-driven environments.
That assumption no longer holds in practice. A support bot may use one service account for database access, another secret for an LLM call, and a third token for CRM writes, while a vendor-hosted add-on can exercise access through consent that is only visible in a log entry. The article treats these as three scenes of the same NHI control gap: unmanaged identity sprawl.
For IAM teams, the governance question is broader than AI readiness. It is whether lifecycle ownership, privilege scope and revocation still work when the identity chain crosses pods, platforms and third-party tenants.
Key questions
Q: What breaks when service accounts, tokens and OAuth grants are treated separately?
A: Governance breaks because the organisation loses the ability to see the full identity chain that powers one business action. A single workflow may span a pod secret, an LLM credential and a third-party tenant, so separate registers and reviews miss ownership, privilege scope and revocation dependencies. The result is hidden blast radius and offboarding gaps.
Q: Why do workflow automations increase risk for non-human identity governance?
A: Because they can change access at machine speed, often across multiple systems, before humans notice a mistake. If the workflow is over-permissioned or poorly segmented, it becomes a standing path for creating, sharing, or updating credentials without enough review.
Q: How do security teams spot shadow AI created by reused credentials?
A: Look for long-lived secrets copied into SaaS setup wizards, duplicated across tools, or embedded in pod variables and Helm charts. Those patterns usually indicate an unmanaged AI workflow with unclear ownership and weak revocation paths. Discovery should focus on reused credentials first, because reuse is what turns a local convenience into an enterprise blind spot.
Q: What should IAM teams do when OAuth consent happens in a third-party tenant?
A: Treat the consent event as the start of an external identity lifecycle, not the end of the control decision. IAM teams need to know what the vendor-owned service principal can still access, how that access is reviewed, and how revocation works when the execution lives outside their own tenant. Ownership and accountability must follow the delegated identity.
Technical breakdown
How NHI sprawl emerges across AI, cloud-native and SaaS workflows
The article shows three different operating contexts that all rely on the same machine identity primitives: traditional service accounts, cloud-native managed identities and access keys, and AI-era credentials embedded in SaaS or third-party integrations. In each case, the identity is not visible to the end user, and the control plane is fragmented across systems. That creates inventory gaps because the credential may live in a pod environment variable, a Helm chart, a SaaS wizard, or another tenant entirely. The technical pattern is not new identity machinery, but the same trust primitive being replicated in more places with less shared governance.
Practical implication: Map where each non-human credential is created, stored and consumed before trying to govern its privilege.
Why hidden credentials turn AI workflows into identity chains
The support-widget example is a useful model for how AI workflows inherit multiple NHIs in one request path. The bot fetches data with one service-account secret, calls an LLM with another service-principal secret, and writes back to a CRM with a third API token. Each credential serves a different system and trust boundary, yet the user experiences one action. That means the security issue is not only credential exposure, but also the composite blast radius created by chained identities. If any one token is over-scoped or unmanaged, the entire workflow inherits that weakness.
Practical implication: Treat AI-assisted business flows as multi-credential identity chains and govern each hop separately.
Why OAuth consent and third-party tenants complicate NHI governance
The third scenario shifts the identity boundary outside the organisation. A user grants OAuth access, but the real data retrieval is performed by the vendor’s own service principal in its tenant, not by a local workload. That means the visible consent event and the actual data movement are separated, which weakens traditional monitoring and offboarding assumptions. Identity governance must therefore account for delegated access that operates through another party’s cloud and another party’s lifecycle. The technical challenge is not only authorisation at the point of consent, but ongoing control over what that external identity can continue to do.
Practical implication: Track third-party delegated access as an active NHI lifecycle, not as a one-time approval event.
Threat narrative
Attacker objective: The objective is to exploit hidden or shared non-human credentials to access data and business workflows beyond the scope the organisation can easily observe or revoke.
- Entry begins when credentials are embedded in pods, Helm charts or SaaS setup wizards and then reused across workflows without strong visibility.
- Credential access expands as one secret powers multiple systems, including database access, LLM calls and downstream business applications.
- Escalation and impact follow when third-party tenants or shared tokens can pull more data than the original user intended, widening the blast radius of each identity.
- Impact is the loss of control over where NHIs live, who owns them, and which workflows they can still reach after deployment.
Breaches seen in the wild
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
- JetBrains Marketplace AI Plugin Campaign: 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
The real NHI governance problem is not AI, cloud, or traditional IT separately, but the identity estate that now spans all three. Once service principals, managed identities, API tokens and OAuth grants are treated as one operational fabric, the old compartmentalised governance model stops working. The practitioner implication is clear: inventory, ownership and lifecycle policy have to cross every runtime and tenant boundary.
Identity visibility fails when the credential is created in one system, consumed in another, and observed only indirectly in a third. That is why CSV inventories and periodic reviews miss so much of the risk surface. A live owner-mapped inventory is not a convenience feature here, it is the minimum condition for knowing whether an NHI still exists, where it is active and whether it can be revoked.
Shadow AI is an NHI governance symptom before it is an AI problem. The article’s examples show that unmanaged AI use often emerges from copied secrets and duplicated service identities, not from model complexity. The implication is that discovery and lifecycle governance must reach into SaaS setup paths, pod variables and third-party integrations before any AI-specific control discussion makes sense.
Delegated access through third-party tenants creates accountability drift. When the visible event is consent but the real actor is a vendor-owned service principal, ownership and revocation no longer line up cleanly. That breaks the assumption that access can be governed entirely inside one directory. Practitioners need to recognise that externalised execution changes where accountability actually lives.
Policy without lifecycle enforcement is not governance, it is documentation. The article’s provision, rotate, least-privilege, attest, decommission sequence is only meaningful if every identity path in cloud, SaaS and AI flows is subject to it. The practitioner conclusion is that non-human identity governance has to be continuous, not periodic.
What this signals
Identity governance has to move from application-by-application review to workflow-by-workflow control. A single user action can now traverse several non-human identities across cloud, SaaS and AI services, so the practical boundary is the workflow rather than the platform. That shifts programme design toward lifecycle visibility, ownership and revocation at the point where credentials are actually used.
Shadow AI is often just unmanaged NHI reuse in a new wrapper. The operational signal to watch is not whether a system is labelled AI, but whether copied secrets and shared tokens are expanding into new environments without a corresponding owner and decommission path. Once that pattern appears, the governance gap is already broader than the AI use case itself.
For practitioners
- Unify NHI inventory across all runtime surfaces Build one owner-mapped inventory for service accounts, managed identities, API keys and OAuth grants across cloud, SaaS and AI-connected workflows. Include where each credential is stored, which workflow uses it and who can revoke it.
- Trace every AI workflow to its underlying credentials Break each AI-enabled business flow into credential hops, then record the secret or token used at each hop and the business system it reaches. This exposes the real blast radius behind a single user-visible action.
- Treat SaaS setup wizards as credential injection points Review copy-and-paste onboarding paths for long-lived secrets placed into Salesforce, CRM or other SaaS integrations. Flag any workflow where one key is reused across multiple tools without rotation or separate ownership.
- Govern third-party consent as an active identity lifecycle Track vendor-hosted add-ons and delegated OAuth access as living non-human identities that require provisioning, review, revocation and decommissioning. If the tenant is outside your control, the lifecycle still has to be documented and enforced.
- Enforce lifecycle policy through existing directories and vaults Use one policy language for provision, rotate, least privilege, attest and decommission so the same control applies across legacy servers, pods and AI workloads. The goal is a single governance model, not separate exceptions for each environment.
Key takeaways
- AI, cloud-native workloads and legacy service accounts now share the same non-human identity control problem, even when the user sees only one interface.
- The most consequential failure mode is hidden credential chaining across pods, SaaS integrations and third-party tenants, which expands blast radius and weakens revocation.
- IAM and NHI programmes need one lifecycle model for discovery, ownership, privilege and decommissioning across every runtime where machine identities operate.
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, NIST SP 800-53 Rev 5 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-02 — Secret Leakage | The article centres on secrets embedded in pods, SaaS wizards and third-party tenants. |
| NHI-03 — Vulnerable Third-Party NHI | Vendor-hosted add-ons and external tenants are a core part of the governance problem here. | |
| NHI-05 — Overprivileged NHI | The article highlights broad access through shared tokens and service principals. | |
| Recommendation — Scan for exposed machine secrets across pods, SaaS onboarding and vendor integrations, then revoke any reused credential. Inventory third-party NHIs and tie every delegated access grant to an owner and revocation path. Reduce non-human privilege scopes to the minimum required for each workflow and tenant. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing machine entitlements across environments. |
| ID.AM-01 — Physical devices and systems are inventoried | A live inventory of service accounts and AI-connected identities is the first control gap discussed. | |
| Recommendation — Map every NHI entitlement to an owner and review its authorisation scope across environments. Extend inventory processes to machine identities and maintain a live owner-mapped register. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential storage, rotation and revocation are central to the examples and governance advice. |
| Recommendation — Enforce authenticator lifecycle controls for secrets, tokens and service credentials across all runtimes. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article shows how one credential can open multiple systems and widen downstream movement. |
| Recommendation — Hunt for reused machine credentials that enable credential access and lateral movement across cloud and SaaS. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud, SaaS and AI identity governance are all framed as one access-management problem. |
| Recommendation — Apply cloud identity governance to service principals, tokens and delegated access across all environments. | ||
Key terms
- 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.
- Service Principal: An application identity object in Microsoft Entra ID and Microsoft 365 that represents a specific app inside a tenant. It holds permissions, ownership, and configuration data that define what the application can do. In NHI governance, it is a high-value identity that should be reviewed like any other privileged account.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- 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 June 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org