Notifications
Clear all
Topic starter
09/06/2026 11:19 pm
TL;DR: Shadow AI now slips through trusted SaaS, IDE, MCP, and CI/CD paths, with AI agents inheriting service account permissions and bypassing traditional gateways, according to Orca Security. The governance gap is structural: controls built for human-paced, visible application access do not contain continuous non-human identity activity.
NHIMG editorial — based on content published by Orca Security: The Bring Your Own AI crisis and shadow AI detection in cloud environments
By the numbers:
Questions worth separating out
Q: How should security teams detect shadow AI hidden inside trusted cloud and SaaS tools?
A: Start with identity, not network traffic.
Q: Why do non-human identities make shadow AI harder to control?
A: Non-human identities let AI tools inherit standing permissions that were issued for another purpose.
Q: What breaks when AI features are embedded inside approved SaaS and CI/CD systems?
A: Traditional gateway controls lose their edge because the traffic looks like normal application use.
Practitioner guidance
- Map every AI-capable non-human identity Inventory OAuth applications, service accounts, API keys, and bot identities that can route data to AI services.
- Scan SaaS, IDE, and pipeline surfaces for embedded AI Review Slack, Notion, VS Code, Cursor, GitHub Actions, GitLab CI, and Jenkins for hidden AI features, extensions, or steps.
- Separate read exposure from write authority Classify each shadow AI use case by what it can read and what it can change.
What's in the full article
Orca Security's full article covers the operational detail this post intentionally leaves for the source:
- A step-by-step framework for mapping NHI sprawl across cloud, SaaS, and API-connected AI features.
- Specific audit checks for IDE extensions, CI/CD pipelines, and model dependencies that may hide shadow AI.
- The platform context behind Orca Security's unified visibility approach across identity, data, and workload signals.
- Practical examples of how an OAuth token can connect a personal AI assistant to production data.
👉 Read Orca Security's analysis of shadow AI detection in cloud environments →
Shadow AI and NHI sprawl: what IAM teams need to detect?
Explore further
10/06/2026 1:37 am
Shadow AI is an identity problem before it is an AI problem. The most important failure mode is that approved identities are increasingly used as transport layers for unapproved AI behaviour. OAuth apps, service accounts, and API keys can all legitimise AI processing inside otherwise trusted environments. Practitioners should treat visibility into non-human identities as the first control plane, not a downstream audit step.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which shows how immature the visibility problem remains across machine identities.
A question worth separating out:
Q: Who is accountable when shadow AI uses corporate credentials to process sensitive data?
A: Accountability sits with the identity owners, the platform owners, and the governance function that approved the underlying access. If a service account or OAuth app can reach regulated data and an AI feature uses that path, the organisation is responsible for the resulting exposure and audit trail.
👉 Read our full editorial: Shadow AI bypasses traditional gateways through NHI sprawl
