Shadow AI hides risky access and malware in encrypted traffic

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WatchGuard's blog post: Shadow AI and encrypted TLS traffic can combine to hide both risky authorizations and malicious content from standard security visibility.

Why it matters: IAM, NHI and security teams need to govern both the permissions granted to AI-connected services and the traffic those services exchange, or hidden access paths and hidden threats will persist.

By the numbers:

• The WatchGuard Global Threat Report H1 2026 says 95% of the malware observed on the network arrived via encrypted TLS connections.
• The WatchGuard Global Threat Report H1 2026 says only 20% of Fireboxes were inspecting that traffic.

Context

Security awareness has to cover more than phishing and password hygiene. When employees are allowed to bring new AI services into work without clear governance, the result is not just shadow IT but shadow AI, where permissions, data sharing and service-to-service connections drift outside security visibility.

In identity terms, these services often inherit trust through corporate accounts and delegated authorizations rather than through a formal onboarding process. That makes the access path itself the problem, especially when AI tools can act on mail, files or calendars with broad permissions.

Key questions

Q: How do teams govern access granted to AI integrations?

A: Teams govern access to AI integrations by treating each integration as a delegated identity with a defined owner, scope, approval path and revocation method. Use least privilege, short-lived OAuth tokens or API keys where possible, and log every tool invocation so the governed access path can be reviewed, rotated or removed when the underlying agent changes.

Q: Why does shadow AI create more risk when organisations try to prohibit it?

A: Prohibition often shifts usage underground, which reduces visibility and weakens logging, data control, and accountability. Once employees move to hidden tools, the organisation loses the ability to see which identities are active or what information is being exposed. That makes the risk harder to detect and more expensive to remediate.

Q: How should security teams inspect encrypted traffic from cloud services?

A: Security teams should inspect encrypted traffic selectively by terminating or mirroring TLS at controlled inspection points, then re-encrypting traffic before it reaches the destination. This is usually applied to sanctioned egress paths, using policy exceptions for sensitive workloads, certificate trust controls and logging to avoid blind spots and unnecessary exposure.

Q: What should employees do before granting an AI tool access to work data?

A: Employees should confirm the tool is approved, check the requested data scope, and verify whether the access is read-only, limited to the inbox, file or calendar access needed for the task. They should also review the consent screen for the signing account, because broad OAuth permissions can expose mail, files and scheduling data beyond the intended use.

Technical breakdown

How shadow AI inherits trust through corporate authorizations

Shadow AI emerges when employees connect chatbots, extensions or AI integrations to corporate accounts without an approved governance path. The risk is not only the application itself, but the authorization chain it creates. OAuth-style consent, inbox delegation, file access and calendar access can all let a tool act with the user's privileges. Once that linkage exists, the service can persist as an unmanaged identity-like access path even if the tool is not sanctioned centrally.

Practical implication: Inventory every external AI authorization and revoke any connection that cannot be justified by business need.

Why encrypted TLS traffic reduces detection fidelity

TLS protects data in transit by encrypting the payload between endpoints, but that same protection also limits what perimeter controls can inspect. If traffic is not decrypted at a control point, security tools can see destination, volume and some metadata, but not the malicious content inside the session. The result is a visibility gap between knowing an application exists and knowing what it is sending or receiving.

Practical implication: Review where TLS inspection is enabled and confirm that exclusions do not cover high-risk application paths.

Why permissions review must follow the service, not just the account

A connected AI service can become riskier over time as scopes expand, configurations change or the user’s role shifts. That is why one-time approval is not enough. The governance problem is lifecycle drift: the authorization that was acceptable on day one may no longer fit the data the service can reach, the commands it can issue or the business context in which it operates.

Practical implication: Reassess granted scopes on a fixed schedule and remove any authorization that is broader than the current use case.

Threat narrative

Attacker objective: Exploit trusted integrations and encrypted channels to access data or actions that should never have been exposed to an external service.

1. Entry occurs when employees connect unsanctioned AI services or extensions to corporate accounts through granted authorizations.
2. Credential access follows when those services inherit tokens, delegated permissions or session access that let them operate on the user's behalf.
3. Escalation happens when broad permissions expose email, files or calendars beyond the task the user intended.
4. Impact is organisation-wide visibility loss, with malicious content or misused access slipping past normal oversight.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is an identity problem before it is an AI problem. The core governance failure is that employees can create trusted connections to external services without those services passing through the same lifecycle controls as other accounts. That means access can exist outside inventory, outside review and outside revocation discipline. Practitioners should treat every AI integration as a governed access path, not as a harmless productivity add-on.

Delegated AI access creates a new form of privilege drift. Once a chatbot or agent can read email, files or calendars, it is no longer just consuming information, it is acting within an identity boundary. The risky assumption is that the original user intent still limits the service after consent has been granted. In practice, broad scopes and changing use cases make that assumption fragile, so authorizations need continuous review.

Shadow AI visibility gap: unmanaged AI services create a blind spot between approved usage and actual access scope. That gap matters because security teams can no longer rely on application approval alone to understand where corporate data is going. The control question shifts from whether a tool is sanctioned to whether its permissions, outputs and connectivity still match the business need.

TLS inspection is now part of AI-era control coverage. If encrypted sessions are not inspected where appropriate, defenders can know that traffic exists without knowing what it carries. That leaves a detection gap that adversaries can exploit, especially when malicious content is wrapped inside ordinary application sessions. Practitioners should align inspection policy to the data and application paths that matter most.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Shadow AI governance will increasingly look like authorization governance. The practical question is no longer just which applications are approved, but which ones retain access to sensitive systems after the original use case has changed. That makes consent review, scope review and revocation part of the same control family.

Encrypted traffic inspection needs a data-driven policy, not a blanket rule. Organisations will have to decide where decryption is justified, where exclusions are acceptable and where metadata alone is not enough. The control objective is visibility into what remote services exchange, not simple coverage for its own sake.

For practitioners

• Audit all AI-related authorizations Build an inventory of chatbot, extension and integration authorizations granted from corporate accounts, then flag anything that can reach email, files or calendars.
• Tighten consent review for delegated access Require approval for any service that requests permissions beyond a single-user task, especially where inbox, file or calendar scopes are involved.
• Expand security awareness to AI use cases Train employees to check whether the data shared with an AI service matches the job to be done and whether the service can act on their behalf.
• Review TLS inspection coverage Map where HTTPS inspection is active, then identify excluded application paths that could conceal malware or suspicious callbacks.

Key takeaways

• Shadow AI becomes a governance issue when external services inherit corporate trust through user authorizations and can act on mail, files or calendars.
• The article pairs access visibility with network visibility, showing that approved services can still hide risk when encrypted traffic is not inspected.
• Practitioners need to manage both the lifecycle of AI-connected permissions and the inspection of the traffic those services generate.

Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · MFA Guide · Security Awareness and Human Risk Management Guide

Key terms

• 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.
• 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.
• TLS Inspection: TLS inspection is a security technique where an appliance intercepts encrypted HTTPS traffic, decrypts it for analysis, and then re-encrypts it for the client. Because this changes the certificate chain seen by the browser, organisations must deploy the inspection root correctly or users will see certificate warnings on legitimate sites.
• OAuth Consent: The approval that allows an application to access resources on behalf of a user or tenant. In practice, consent can create durable access paths that outlive the original interaction if permissions are broad, unmanaged, or never reviewed. For security teams, it is both an access decision and a lifecycle event.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management. It helps practitioners connect access control decisions to the broader identity risks that modern programmes now face.