How to Give AI Access to Files on a Windows File Server

By Dan Gordon

Last Updated: August 24, 2026

Most enterprise data still lives on Windows file servers. Decades of contracts, drawings, and project folders sit behind SMB shares and NTFS permissions. AI tools cannot see any of it by default.

That gap is now a daily request in IT queues. An analyst wants an AI assistant to summarize files on the H: drive. A developer wants to point a retrieval pipeline at a project share. Nobody wants to migrate 40 TB of data to a cloud service to make it happen.

The short answer: publish the file server through MyWorkDrive, mount the share as a mapped drive over HTTPS on the machine running your AI tool, and let the tool read files with the same NTFS permissions and audit logging that govern every other user. This guide walks through how that works and why the alternatives cost more than they look.

Why AI Tools Can't See Your File Server

AI assistants and LLM applications read local files and speak HTTPS. Windows file servers speak SMB on port 445, authenticated through Active Directory. There is no native bridge between the two.

That boundary exists for good reason. SMB was never designed for internet exposure, and an open port 445 is one of the fastest paths to ransomware. Any AI integration has to respect the same rules your users do: authenticated, encrypted, permission-scoped access with a log of everything that was touched.

So before picking a method, write down what it has to preserve:

• Files stay on your infrastructure. No bulk migration, no sync copies scattered across a cloud tenant.
• NTFS permissions remain the source of truth. The AI reads what its account can read, nothing more.
• SMB stays off the internet. Access rides HTTPS only.
• Every read is logged and exportable to your SIEM.

The MyWorkDrive Approach: A Mapped Drive Your AI Tools Can Read

MyWorkDrive publishes existing Windows SMB shares over HTTPS on port 443, with SMB, NetBIOS, and DNS ports closed to the outside. NTFS permissions are inherited, never elevated. Files are processed in memory and never persist on the MyWorkDrive server. Every file operation is logged and exportable to your SIEM.

The part that matters for AI: the MyWorkDrive mapped drive client presents those shares as a standard drive letter in Windows or macOS. To the operating system, and to any application running on it, the file server looks like a local drive. That includes AI applications.

Any tool that can read a local folder can read a MyWorkDrive mapped drive:

• MCP filesystem servers. Point a filesystem MCP server at the mapped drive path, and an AI assistant such as Claude can list, read, and search those files during a conversation. Access is scoped to what the logged-in user's NTFS rights allow.
• RAG and indexing pipelines. A crawler running on a workstation or server with the mapped drive client can chunk and embed documents into a local vector database, with the share reached over HTTPS instead of raw SMB.
• Desktop AI assistants and agents. Local AI tools that browse folders on the user's machine see the mapped drive like any other location.

Setting It Up

1. Deploy MyWorkDrive on a Windows server that can reach your file shares. Installation takes about 30 minutes and requires no changes to the file server itself.
2. Publish the shares you want AI-accessible. Home drives are available by default. NTFS and share permissions carry over as-is.
3. Create a scoped account for AI workloads. For indexing or agent workloads, use a dedicated AD account with read access limited to the folders in scope. Never index with a broadly privileged account.
4. Install the mapped drive client on the machine running the AI tool and sign in with that account over HTTPS.
5. Point the AI tool at the drive. An MCP filesystem server, a crawler, or a desktop assistant now reads the share through an encrypted, logged, permission-scoped channel.

Governance Stays On

The controls that protect human access apply to AI access with no extra work:

• Audit logging records every file the AI account opened, with SIEM export for review.
• DLP controls can restrict downloads, add watermarks, or enforce view-only access on sensitive shares you decide to keep away from AI workloads.
• Device approval limits mapped drive access to machines you have authorized, so an AI indexing box has to be explicitly allowed.
• SSO and MFA through Active Directory, Entra ID, or your SAML provider govern the accounts AI tools run under.

One honest caveat: reads over HTTPS carry more overhead than local SMB. For large initial indexing jobs, run the crawler on a machine close to the MyWorkDrive server, index selectively, and schedule incremental crawls rather than repeated full scans.

How the Alternatives Compare

Each alternative solves part of the problem. Migration gets you cloud AI features at the cost of moving and re-permissioning everything. A VPN with a service account works but extends network-level access to the machine running the AI tool and reopens the attack surface you were trying to close. Cloud search connectors such as the Microsoft Graph connector for file shares fit organizations standardized on Microsoft 365 Copilot, though the indexed content lives in the tenant and local AI tools cannot use it.

The mapped drive approach is the only one that keeps files in place, keeps SMB closed, keeps NTFS in charge, and works with any AI tool that reads a filesystem.

The Security Checklist Before You Connect Anything

Whatever route you take, get these right first.

Use a dedicated account with least privilege. The AI workload should read only the shares in scope. Never index with a domain admin account.

Fix oversharing before you index. AI is brutally effective at surfacing files people technically had access to but never knew existed. Audit share permissions before any AI tool touches them.

Confirm where file content goes. Content read by a cloud-hosted assistant leaves your environment with each request. Check your AI provider's data handling terms against the sensitivity of the share.

Log from day one. Route access logs to your SIEM during the pilot, not after an incident.

Keep sensitive shares out of scope. Use share-level publishing and DLP to draw a hard line around HR, legal, and other restricted data until governance catches up.

Frequently Asked Questions

How do I give an AI assistant access to files on a Windows file server?

Publish the share through MyWorkDrive, install the mapped drive client on the machine running the AI tool, and sign in with a scoped account. The share appears as a drive letter over HTTPS, so any AI tool that reads local folders, including MCP filesystem servers and RAG crawlers, can read it with NTFS permissions enforced and every access logged.

Can AI tools read a MyWorkDrive mapped drive?

Yes. The mapped drive presents published shares as a standard drive letter, so applications on that machine, including AI assistants, MCP filesystem servers, and indexing pipelines, read the files like any local folder. Access is limited to the signed-in account's NTFS rights.

Is it safe to give AI access to an SMB share?

It can be, with the right controls. Keep SMB closed to the internet and provide access over HTTPS, use a dedicated account with read access limited to the folders in scope, log every file operation, and audit share permissions for oversharing before any AI tool connects.

Do I have to migrate my file server to the cloud to use AI on my files?

No. A MyWorkDrive mapped drive gives AI tools direct read access to files where they already live. Self-hosted RAG pipelines can index through the same drive without content leaving your network. Migration is one option, not a prerequisite.

Will NTFS permissions still apply when AI reads my files?

Yes, if your access layer inherits them. MyWorkDrive cannot grant more access than NTFS already allows, so an AI workload signed in with a scoped account reads only what that account is permitted to read. Test with accounts at different permission levels before rollout.

Start a free trialBook a demoView pricing