Topic starter
24/10/2026 8:51 pm
TL;DR: Shadow AI creates an access and data-exit path that can expose sensitive information before teams notice, according to Todyl. SASE has to enforce policy at the point of transfer, or unapproved destinations and downloads can keep widening exposure.
Editorial analysis by NHI Mgmt Group, based on content published by Todyl: “How SASE Reduces Your Clients' Attack Surface and Blocks Shadow AI”.
Key questions
Q: Why does shadow AI increase data leakage risk in engineering teams?
A: Because developers often paste code, secrets, or internal diagrams into external tools to move faster, and those inputs can leave the enterprise boundary without the logging or deletion guarantees teams expect.
Q: What are the signs that shadow AI controls are failing in practice?
A: Shadow AI controls are failing when sensitive data moves through copy-paste, uploads, or API calls outside sanctioned workflows, yet the organisation has no alerting or enforcement at the point of transfer.
Q: What breaks when shadow AI is not detected at the traffic layer?
A: When shadow AI is invisible at the traffic layer, security teams lose the ability to stop live data from reaching external models, prove which model handled which payload, or enforce consistent policy.
Practitioner guidance
- Block unapproved AI and LLM destinations Use web filtering to deny access to consumer AI services that are outside approved workflows, and maintain a policy list that reflects actual business use rather than broad category labels.
- Enforce identity-bound access at the session layer Tie access decisions to explicit user identity and least privilege so corporate credentials cannot be reused to create unsanctioned AI accounts or sessions.
- Inspect encrypted sessions for sensitive uploads Enable SSL inspection where appropriate so encrypted traffic cannot hide sensitive data moving into AI tools through legitimate-looking domains.
Bottom line: Shadow AI is not just an acceptable-use issue. It creates an access and data-exit path that can expose sensitive information before teams notice.
Glossary terms: Shadow AI, SASE, ZTNA, Shadow IT
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 7 days ago by NHI Mgmt Group
25/10/2026 11:12 am
Shadow AI governance is now an access-control problem, not just an acceptable-use problem: unapproved AI tools create a pathway where users can move sensitive information outside governed workflows before any review happens. That shifts the control question from policy wording to whether network, identity and device enforcement can stop the session at the point of use. For identity teams, the relevant boundary is who can initiate a connection and what that connection is allowed to carry.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should security teams balance SASE controls with AI usage policy?
A: Use SASE to enforce the policy, not replace it. The policy defines what is approved, but SASE makes that decision real through blocking, inspection and identity-bound access. Without that enforcement layer, AI use policy becomes guidance rather than control, which leaves shadow AI to grow unnoticed.
👉 Read our full editorial: SASE can shrink shadow AI exposure, but governance still matters
This post was modified 7 days ago by NHI Mgmt Group