Three frontiers, one identity challenge for NHI governance

At a glance

What this is: This is an analysis of how AI, cloud-native and traditional systems all rely on the same non-human identity mechanics, with credential sprawl creating shared governance blind spots.

Why it matters: It matters because IAM, PAM and governance teams have to treat AI workloads, cloud runtimes and legacy machine identities as one control plane, not three separate problems.

👉 Read Oasis Security's analysis of three AI and NHI identity frontiers

Context

Non-human identity sprawl now spans three environments that teams often manage separately: traditional IT, cloud-native workloads and AI systems. The common failure is the same in each case. Credentials are embedded, duplicated or delegated in places where ownership, rotation and visibility do not keep pace with actual usage, which leaves governance weaker than the architecture suggests.

For identity teams, the key question is no longer whether AI introduces a new identity model. It is how existing service accounts, service principals, managed identities and OAuth grants behave once AI systems start consuming data, generating actions and chaining access across platforms. The article frames that problem clearly, and it is typical of the kind of blind spot many programmes still carry.

Key questions

Q: How should security teams govern AI applications that depend on multiple non-human identities?

A: They should map the full access chain, not just the visible app. A single AI workflow may rely on several credentials across databases, model endpoints, SaaS connectors and third-party tenants. Governance has to cover ownership, rotation, scope and offboarding for each identity, because the security failure often sits in the connections between them, not in one secret alone.

Q: Why do copied API keys and access tokens create long-term risk in AI and SaaS workflows?

A: Because they detach access from the original business use case. Once a key is embedded in a wizard, database or shared configuration, it can be reused across tools and replicas without lifecycle control. That creates hidden persistence, unclear ownership and a blast radius that expands beyond the team that first entered the credential.

Q: What do teams get wrong about third-party OAuth integrations?

A: They often treat consent as if it were the control, when consent is only the start of the access path. The real governance issue is the vendor’s downstream execution in another tenant, where a service principal can pull data long after the approving user has lost sight of the transaction.

Q: How do IAM teams decide whether an AI use case needs new controls or better NHI hygiene?

A: Start with the identity mechanics. If the use case depends on service principals, managed identities, access keys or delegated OAuth grants, it needs NHI governance first. If it also makes runtime decisions about actions and tool use without approval gates, then autonomous behaviour adds another layer of control analysis.

Technical breakdown

Service principals and secrets hidden inside AI workflows

AI assistants often appear to be a single application, but they are usually a chain of identities. A chat widget may call a database with one service-account password, send prompts to an LLM with a second service-principal secret, and write results back through a third token. Each credential has different ownership, rotation requirements and blast radius. The governance problem is not the model itself. It is that the full transaction is split across multiple non-human identities, making attribution and control harder than in a conventional application flow.

Practical implication: map each AI workflow to the exact credentials it uses, then verify ownership, scope and rotation for every one of them.

Shadow AI from copied access keys

Bring-your-own-model and plugin-style integrations often create shadow AI because a single pasted key can live far beyond the setup moment. Once a long-lived credential is stored in a vendor database or reused across multiple SaaS tools, the identity ceases to be tied to the original use case. That breaks the normal assumption that one access decision maps to one bounded workload. The result is persistent, unattributed access that can spread across tools without passing through the controls identity teams expect to see.

Practical implication: treat every copied API key or access token as a potential fleet-wide dependency until proven otherwise.

Third-party OAuth consent and invisible downstream access

A delegated OAuth grant can look small on the customer side while enabling much broader access in a third-party tenant. In that pattern, the external service principal lives outside the customer boundary but still uses the customer’s consent to pull emails, CRM objects or transcripts. This creates a governance gap between consent logging and actual data movement. The important issue is not just who approved access, but where the real execution happens and which identity owns the downstream activity.

Practical implication: review third-party OAuth grants as active machine identities, not as one-time user approvals.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Credential sprawl is now the dominant control problem in AI-enabled identity estates. The article shows the same pattern across traditional IT, cloud-native systems and AI workflows: invisible credentials sit inside configs, charts, pods and third-party tenants. That means the control failure is not lack of a single tool, but lack of a coherent identity inventory across every non-human execution path. Practitioners should treat visibility across NHIs as a baseline security requirement, not an optimisation.

Shadow AI is an identity governance problem before it is an AI governance problem. When a copied key is reused across multiple SaaS tools, the risk is not only exposure. It is loss of lifecycle control, because the credential now outlives the business process that created it. This is the kind of lifecycle drift that conventional recertification rarely sees, and it belongs in OWASP-NHI and ZT-NIST-207 thinking, not in a separate AI-only silo.

Third-party consent creates an accountability split that many IAM programmes still under-model. The customer sees an approval event, but the actual data access happens through the vendor’s service principal in another tenant. Visible consent is not the same as governed execution: the identity owner, the data controller and the runtime executor are no longer the same party. Practitioners should re-evaluate how they assign ownership when access leaves their tenant.

AI workloads force IAM teams to manage identity as a graph, not as a list. One chat session can rely on three independent NHIs, each with separate privilege and lifecycle rules. That turns isolated secrets reviews into an incomplete control pattern because the exposure is in the connection between identities, not only in each credential. The discipline now is to govern the chain of access end to end.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• That same research found only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which shows the governance gap is broader than one workflow.
• For the lifecycle angle, see Ultimate Guide to NHIs , The NHI Market for how practitioners are structuring NHI security programmes around inventory, policy and ownership.

What this signals

Visible AI usage is not the same as governed AI usage: once identities are embedded in pods, setup wizards and third-party tenants, the programme that only tracks human logins has already lost the real control surface. The practical shift is toward identity graph thinking, where machine access is traced end to end across environment boundaries.

With 1.5 out of 10 organisations highly confident in securing NHIs, the market signal is clear: IAM teams are still under-instrumented for the volume and distribution of machine identities now attached to AI-enabled work. That makes inventory quality, lifecycle ownership and consent governance the next operational priorities.

When a single workflow can consume three independent credentials, teams need to link policy to execution rather than to application labels. The control question becomes whether each identity is owned, reviewed and retired on its own terms, with clear evidence for NIST AI Risk Management Framework alignment where AI-specific decision-making is involved.

For practitioners

• Build a complete NHI inventory for AI workflows Map every service account, service principal, access key and OAuth grant used by AI-assisted processes, including hidden dependencies inside pods, wizards and third-party tenants.
• Separate copied keys from controlled identities Flag any access key or token that has been pasted into a SaaS setup flow, shared across replicas or reused across tools, then assign an owner and renewal path.
• Review third-party consent as machine access Reassess OAuth approvals and vendor-hosted integrations as active non-human identities with downstream data access, not as one-time user actions.
• Tie remediation to the full credential chain When an AI application is retired or changed, decommission every associated secret, service principal and delegated token in the order they are actually used.

Key takeaways

• AI workflows are not identity-light. They often hide several non-human identities inside one user-facing task, which makes inventory and ownership the first governance problem.
• Copied keys and delegated consent create persistence outside the original control point. That is why lifecycle management, not only detection, determines whether the access remains governable.
• IAM teams should treat AI, cloud-native and legacy machine identities as one control domain. The right response is a complete NHI graph with ownership, rotation and offboarding tied to each access path.

Key terms

• Non-Human Identity: A non-human identity is any credentialed entity used by software rather than a person, including service accounts, API keys, tokens, certificates and workload identities. In AI environments, the same concept covers model connectors, vendor tenants and orchestration accounts that act on behalf of a process.
• Shadow AI: Shadow AI is AI activity that operates outside approved governance, usually because a team has pasted in credentials or enabled a third-party integration without full inventory or oversight. The security problem is not only the model, but the unmanaged identity and data paths attached to it.
• Service Principal: A service principal is an application identity used for machine-to-machine access in cloud and SaaS systems. It carries permissions like a user account but is intended for software execution, which makes its scope, ownership and retirement critical in AI-enabled workflows.
• Delegated OAuth Access: Delegated OAuth access is permission granted by a user or admin that allows a third-party application to act on resources through an access token. In practice, the real risk is the vendor’s downstream execution and the persistence of access after the original approval event.

Deepen your knowledge

NHI inventory, secret sprawl and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is already dealing with AI-assisted workflows and shadow credentials, it is worth exploring.

This post draws on content published by Oasis Security: Three frontiers, one challenge. Read the original.