Semantic Kernel .NET 1.82.0 rewrites file access: the breaking change hiding in a consolidation

Microsoft released Semantic Kernel .NET 1.82.0 on November 7, 2026, and buried in the changelog is a line that will matter to anyone whose agents touch the filesystem: ".Net: [BREAKING] Consolidate file access". If your .NET code uploads files through Semantic Kernel's Microsoft Graph cloud drive connector, or saves code-interpreter session downloads to disk, expect compile errors or outright denials after upgrading. The short version: uploads now take caller-owned streams instead of local file paths, local session downloads are denied unless you explicitly configure allowed directories, and every plugin's file handling now routes through one shared helper that validates paths before opening anything. The change is not a response to a published vulnerability. It is a consolidation with a security payoff, and it will break real code.

What actually breaks in 1.82.0

The breaking surface, per the merged pull request (#14679, 24 files changed, +2527/-325):

• Cloud drive uploads change contract. ICloudDriveConnector uploads moved from local file paths to caller-owned streams. The OneDrive connector now uploads the stream you hand it without taking ownership, so your code opens the local file, keeps and disposes the stream, and passes it in. Any call site passing a path string will not compile.
• Session downloads go deny-by-default. The code interpreter's SessionsPythonSettings now documents that saving local downloads requires allowed directories. If your agent saves files from a hosted Python session to disk and you never configured allowed directories, those saves will be denied after the upgrade.
• Document access tightens. DocumentPlugin now passes allowed directories into its filesystem connector and uses creation status when appending. The connector contract (IFileSystemConnector) now defines restricted reads and atomic open-or-create updates instead of loose path-based operations.
• The core FileIOPlugin switched to secure reads with atomic overwrite protection, and the web download plugin uses shared path normalization with secure destination opening.

Why Microsoft consolidated this

The stated motivation is plain: different plugins each carried their own file checks and file access code. The pull request replaces all of that with one shared component, an internal SecureFileSystem helper that validates allowed directories and opens files using platform-specific handles. Reads, writes, downloads, and uploads across the plugins now go through that single path, and Microsoft added regression tests plus a dedicated workflow that runs the filesystem tests on Windows, Linux, and macOS.

One consolidated, tested path is easier to audit than five hand-rolled ones. The same release also hardens structured data mutation boundaries (#14718) and binds validated HTTP addresses to connections (#14719), and removes the migrated .NET Milvus connector (#14682). Read together, 1.82.0 is a hardening release that happens to break APIs while doing it.

What I would check

These are my untested suggestions, based on the change description, not a migration I have run:

• Before upgrading, pin the Semantic Kernel plugin packages to the version you currently run and upgrade deliberately, not as part of a bulk dependency bump.
• Grep your solution for ICloudDriveConnector and upload call sites that pass file paths. Rewrite them to open the file yourself and pass a stream you own.
• If agents save session downloads locally, decide the allowed directories now and configure them explicitly. Deny-by-default is the right posture, but it will silently fail workflows that assumed open access.
• Re-test anything involving symlinks, overwrite races, and path normalization; those are exactly the cases the new tests target, which tells you where behavior changed.
• Run your test suite on more than one operating system. The new platform-specific handle code is precisely where Windows-only testing will lie to you.

What I would not conclude

Do not treat this as an emergency patch. I found no security advisory or CVE attached to 1.82.0, so this reads as proactive hardening, not an active exploit fix. I also would not assume the consolidation landed clean: during review, automated review flagged two issues, Linux uploads failing beneath searchable but non-listable ancestor directories, and filesystem resolution errors being exposed for paths outside the upload allow-list instead of returning the normal denial. I could not verify whether both were resolved before the merge, so watch the repository's issue tracker if you hit odd Linux upload failures. Finally, the release tag also lists many Python commits; those belong to the separate Python SDK versioning and do not change the .NET packages.

Frequently asked questions

Does Semantic Kernel .NET 1.82.0 break existing plugin code?

Yes, if you use the affected surfaces. Uploads through the cloud drive connector moved from file paths to caller-owned streams, so existing call sites will not compile. Session downloads without configured allowed directories will be denied at runtime. Code that only chats and calls tools without touching local files is unaffected.

Is this a fix for a known vulnerability?

Not that I could verify. There is no CVE or security advisory tied to 1.82.0 in the sources I read. Microsoft's stated reason is consolidation: each plugin had its own file checks, and they are now unified behind one validated path.

Which packages are affected?

The .NET plugin packages in the 1.82.0 wave: Plugins.MsGraph for cloud drive uploads, Plugins.Core for FileIOPlugin and the code interpreter session plugins, Plugins.Document for document access, and Plugins.Web for file downloads. The Python SDK versions separately and is not affected by this release.

How do I keep the old behavior while I migrate?

Stay on the Semantic Kernel version you were running before the upgrade and schedule the migration deliberately. There is no documented compatibility switch in the sources I read; the contract change is the point.

Do local file reads still work without allowed directories?

The direction of the change is that allowed directories are becoming the gate for local file access. Session downloads are explicitly deny-by-default without them, and the document plugin now passes allowed directories into its connector. Assume you need to configure them anywhere your agent touches local paths.

What were the two issues flagged during review?

Automated review on the pull request flagged Linux uploads failing under directories that are searchable but not listable, and error messages leaking filesystem resolution details for paths outside the upload allow-list instead of a clean denial. Both were flagged before merge; I could not confirm their final status.

Does this affect Semantic Kernel for Python?

No. The Python SDK shipped 1.46.0 separately and has 1.47.0 in preparation. The breaking file access consolidation is .NET-only.

Sources

• Semantic Kernel releases: dotnet-1.82.0 - read November 8, 2026. Release date (November 7, 2026), the version bump, the breaking-change line, the structured-data and HTTP hardening entries, and the Milvus connector removal.
• [Pull request 14679: .Net: [BREAKING] Consolidate file access](https://github.com/microsoft/semantic-kernel/pull/14679) - read November 8, 2026. Motivation, the shared SecureFileSystem helper, caller-owned stream uploads, deny-by-default session downloads, the per-file change list, the cross-platform test workflow, and the two issues flagged during automated review.

Not read: the full diff of #14679 beyond its summary and file table, and the individual pull requests for #14718 and #14719. I have not run the 1.82.0 upgrade against a real project; the migration suggestions above are reasoned from the change description, not from hands-on testing.