Cyber beyond humans: shadow AI and trusted AI governance

At a glance

What this is: This is a governance analysis of how shadow AI, agentic access, and non-human identity controls collide as organisations try to move from discovery to trusted AI.

Why it matters: It matters because IAM, PAM, and IGA teams now have to govern humans, NHIs, and AI agents under one access model without assuming static privilege or human-paced review cycles.

By the numbers:

• Discover how 77% of employees sharing secrets on ChatGPT jeopardizes enterprise security.
• NHIMG research shows that 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps.

👉 Read Oasis Security's analysis of shadow AI and trusted AI governance

Context

Shadow AI becomes an identity problem the moment employees use unsanctioned AI tools with enterprise data, credentials, or workflows. In that environment, governance cannot stop at user training or app blocking, because the real control gap is whether the organisation can see and constrain the identities behind the interaction.

The article frames trusted AI as the next stage after shadow AI, but the underlying issue is broader than AI alone. IAM and NHI programmes now have to account for people, service identities, and agent-like systems that can act on data and tools with very different accountability models.

Key questions

Q: How should security teams govern shadow AI without blocking business productivity?

A: Start by identifying the identities and credentials behind AI use, then classify each one by data sensitivity, connected systems, and business purpose. Governance works best when organisations control the access path rather than banning the tool outright. That means inventory, approval, monitoring, and revocation all need to follow the same identity path.

Q: Why do AI tools create new identity risks for IAM teams?

A: AI tools often inherit access through existing accounts, tokens, and integrations, which expands the attack surface without creating a new governance record. IAM teams should treat those inherited permissions as real identities with real blast radius, not as harmless app settings. The risk grows when access is broad, reusable, and poorly observed.

Q: What breaks when AI access is managed like normal application access?

A: Normal application access assumes stable ownership, predictable usage, and clear review cycles. AI-connected identities can change behavior faster than those cycles can detect, especially when tool use and data access happen in the same session. If teams rely only on point-in-time approvals, they miss the runtime risk.

Q: How do organisations decide whether an AI workflow needs stricter controls?

A: Use data sensitivity, action scope, and external reach as the first decision filters. If an AI workflow can move data, trigger downstream actions, or touch privileged systems, it needs stronger control than a read-only use case. The key is to match the control strength to the impact of the identity path.

Technical breakdown

Shadow AI, agentic access, and identity sprawl

Shadow AI usually starts as an employee productivity choice, but it becomes an identity risk when the tool is granted data access, tokens, or connected accounts. At that point, the problem is no longer just application use, it is delegated identity control across a stack of humans, OAuth grants, API tokens, and workflow connectors. The security boundary shifts from the user endpoint to the credential chain. That is why discovery and ownership matter before policy enforcement can be effective, especially when AI tools are embedded in business processes.

Practical implication: Map every AI-facing credential and connected account before attempting policy enforcement.

Trust models break when AI systems inherit access rather than earn it

Traditional IAM assumes access is requested by a known subject, evaluated, and then granted within a stable governance window. AI systems often inherit access through pre-authorised integrations, which means the blast radius is defined by what the integration can reach rather than what the operator intended. This is especially risky when the same token can be reused across multiple services or when a model can trigger downstream actions without a fresh approval step. That makes inherited trust the real issue, not simply AI capability.

Practical implication: Review every pre-authorised AI integration as if it were a standing privileged pathway.

Runtime guardrails matter more than static allow lists

Static allow lists and point-in-time approvals were built for slower, human-driven workflows. Trusted AI requires controls that can observe activity during execution, not just at setup, because tool use, data access, and task chaining can change fast once a system is live. This is where NHI governance and AI governance overlap: the access object is non-human, but the control problem is still about scope, monitoring, and revocation. Without runtime guardrails, policy is only documented intent.

Practical implication: Add runtime monitoring and revocation paths for AI-connected identities, not just pre-deployment reviews.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Shadow AI is now a governance discovery problem, not just an acceptable-use problem. Once employees use AI tools with enterprise data, the relevant question becomes which identities, secrets, and workflows were exposed. That moves the issue into NHI and access governance, because the risk lives in tokens, connectors, and delegated permissions rather than the chat interface itself. Practitioners should treat shadow AI as hidden identity surface area.

Trusted AI depends on controlling inherited access, not trusting the model to behave well. The article’s framing points to a larger identity truth: AI systems are often given access through existing accounts and integrations instead of being governed as distinct entities. That creates a policy blind spot where the system can act within another identity’s rights. Practitioners need to re-evaluate who actually owns the entitlement, not just who clicked approve.

Purpose-bound access is the right named concept for this problem space. The organisation needs access that is tied to a specific task, scope, and time window, because AI-connected identities can otherwise accumulate broad and reusable reach. This aligns with OWASP-NHI and zero trust thinking, but the field should name the problem as purpose-bound access drift. Practitioners should measure whether AI-linked identities still only do the job they were created to do.

Human, NHI, and agentic controls are converging into one control plane. The article shows why governance can no longer be split into separate conversations about employee misuse, machine secrets, and AI tools. Each of those domains now shares the same control questions: who can act, what can they reach, and when can that access be removed. Practitioners should build one access model that spans all three actor types.

Static trust assumptions are the weakest part of current AI security programmes. Policies that assume fixed scope, fixed owners, and fixed execution paths will not hold once AI systems are wired into business workflows. That does not mean every AI tool is autonomous, but it does mean the identity boundary is moving faster than many governance processes can follow. Practitioners should assume the trust model will be the first thing to fail.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, which shows this is a live governance problem rather than a theoretical one.
• That is why the Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs matters for teams trying to move from discovery to controlled ownership and offboarding.

What this signals

Purpose-bound access: the practical next step for AI governance is to stop treating permissions as a one-time approval and start treating them as a task-scoped control. When AI tools can inherit broad rights, the governance programme needs a cleaner boundary between intent, execution, and revocation.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the control problem already extends beyond internal users and into delegated access chains. That is why IAM and NHI teams need a shared inventory view, supported by the 52 NHI Breaches Analysis and zero trust access principles.

The programme signal to watch is whether AI-linked identities are reviewed as identities or merely as applications. If ownership, purpose, and revocation are unclear, the organisation is managing software adoption rather than identity risk.

For practitioners

• Inventory every AI-connected identity Build a live register of employee-used AI tools, OAuth grants, API keys, and service accounts that can reach enterprise data or execute workflows. Include shadow AI use cases, not just sanctioned platforms, and assign an owner to each identity path.
• Separate approval from execution Require a second control point before an AI-connected identity can trigger data movement, external calls, or workflow actions. The goal is to prevent pre-authorised access from becoming unchecked runtime authority.
• Define purpose-bound access rules Limit AI-related entitlements to a specific task, dataset, or workflow, then revoke or re-evaluate them when the purpose changes. Treat broad reusable access as a defect, not a convenience.
• Monitor delegated access paths continuously Watch for unusual combinations of identity, tool, and data access across connected AI systems. Alert on access paths that expand beyond the original business purpose or that persist after the task is complete.

Key takeaways

• Shadow AI becomes an identity governance issue once tools can reach data, tokens, or workflows.
• Inherited access is the main control weakness, because AI systems often act through pre-authorised identities.
• Purpose-bound access and runtime revocation are the controls that separate trusted AI from unmanaged AI use.

Key terms

• Shadow AI: Shadow AI is the use of AI tools or services inside an organisation without formal visibility, approval, or governance. In practice, the risk comes from hidden data flow, unmanaged accounts, and delegated permissions that security teams cannot inventory or control.
• Purpose-bound access: Purpose-bound access is permission limited to a defined task, dataset, or workflow, with revocation when that purpose ends. For AI systems, the control matters because broad reusable access creates unnecessary blast radius and blurs accountability across people, tokens, and connected systems.
• Delegated access path: A delegated access path is the chain of identities, tokens, connectors, and approvals that lets one system act through another. It becomes a governance concern when the path outlives the original approval or can be reused for actions beyond the intended business purpose.
• Runtime guardrail: A runtime guardrail is a control that evaluates and constrains behaviour while a system is executing, not only before it starts. In AI governance, this matters because the risk often appears during tool use, data access, and chained actions, after static approval has already been granted.

Deepen your knowledge

AI identity governance and purpose-bound access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring shadow AI and non-human access under one control model, it is worth exploring.

This post draws on content published by Oasis Security: Cyber Beyond Humans: From Shadow AI to Trusted AI. Read the original.