You have no doubt heard by now that Microsoft is bringing Python to Excel.

And if you hadn't heard that news, you no doubt heard a strange noise in the distance as data scientists collectively rejoiced and infosec teams collectively groaned.

But before you jump to any rash conclusions on either side, let's understand some things about it.

Cut to 2023, August 22, specifically, and Microsoft announced that Python scripts will now be supported in Excel. Given the aforementioned macro history, its clear to see why there's both skepticism and rejoicing. Python is an incredibly powerful scripting language, making use of an unimaginable number of libraries to create and automate just about anything you can dream up. But that means you can also do some REALLY... err... creative things with it.

it's at this point that the astute reader will say "oh boy, I see where this is going."

But, Microsoft thought of this. Maybe. Hopefully.

The implementation of Python in Excel makes use of a few controls that should make it mostly safe. We should all know better by now than to believe that its safe but it's at least safe-adjacent.

The first thing to know is that, at least by design, any Python executed in Excel is run in isolated containers in Azure. This means that it will not have access to your local system or account. According to documentation (and this point is admittedly a bit confusing for me) it also will not have network access. The code does not have access to, and cannot call other formulas, charts, macros, etc. Also, taking a page out of the macro history book, Excel's protected view applies in the same way with Python content as with macro content. That is to say, if you load a worksheet with Python that was downloaded from the internet or other untrusted source, the code will not run without your acknowledgement and acceptance. Additionally, and with perhaps uncharacteristic foresight, Microsoft also designed this process such that if a user accepts the risk and allows the external content, this content will still be executed in a separate, isolated Azure container, thus eliminating any potential interaction between code from that sheet, and any code from any other sheets a user may have open at the time. They've also committed to a routine patch management process to ensure that the Python environments are kept up to date.

And there is one last, considerably important measure that Microsoft put in place to ensure safety, which is that they limited the functionality at the library level. By partnering with Anaconda, the implementation of Python in Excel limits it to a specific set of curated libraries. Now before I get any hate mail, I fully understand that the Python codebase is still perfectly capable on its own. But, limiting the available libraries is another step, one which I would argue will go a long way, in limiting low-effort attacks.

Finally, there is one additional control you can enforce yourself - a simple registry key, allowing you to display a warning, or block Python in Excel execution entirely.

To do this, create a new DWORD named PythonFunctionWarnings in HKCU\software\policies\microsoft\office\16.0\excel\security

Available values are:
0 - Disable warnings
1 - Temporarily block and display a banner to users when Python formulas are present, allowing users to enable content if they choose to
2 - Disable all Python functions from running in Excel

If you would like to script this, you can simply use the following commands:

Disable warnings
reg add HKCU\software\policies\microsoft\office\16.0\excel\security /v PythonFunctionWarnings /t REG_DWORD /d 0 /f 

Security Prompt
reg add HKCU\software\policies\microsoft\office\16.0\excel\security /v PythonFunctionWarnings /t REG_DWORD /d 1 /f 

Python in Excel Disabled
reg add HKCU\software\policies\microsoft\office\16.0\excel\security /v PythonFunctionWarnings /t REG_DWORD /d 2 /f



Hope this helps! Stay safe out there!