How to secure a Python project on Windows from domain administrators?

Question

Desired outcome:

1. I log into Windows Server 2019, that is domain-joined, using an Active Directory account, that is a local adminsitrator, but not a domain administrator.

2. I initiate launching of a Python 3 script, that runs as a service, a worker. It would be stopped only for maintenance. Python 3 is installed. Python 2 is not installed and I want to avoid installing it.

3. I am prompted to enter the password

4. If I enter the correct password, Python project is extracted from a password-protected, encrypted archive (of any format) directly into RAM, and then started there

The key requirement is to prevent people, that don't have the password for that Active Directory account and don't know the archive's password, from accessing the Python project files (scripts, dependencies, local database-like files, configuration).

5. Changes, made to archive database-like files, are persisted back to the password-protected archive, while the project is running

Reasoning: The project contains data, that cannot be trusted to the entire group of domain administrators. I cannot influence the permissions of domains administrators.

The question:

What options do I have for securing access to the project that way?

I have done a research and, apparently, a virtual local drive (ramdisk), mapped only to the current Windows user session, is the way to go (Dokan's memfs seems the fastest way). But maybe there are other ways to run Python scripts from RAM? I mean, apart from "exec" or python.exe's argument "-c" - the scripts are big and include references to other script files. MemFS from PyFilesystem project seems to support that only for Python 2. Creating a custom import hook for sys.path does not seem to be an option. Also, ideally, unpacking from the archive would need to be done directly into RAM, bypassing temp locations on the disk. It seems, that a local mount point (mapped local folder or drive letter, pointing to RAM) need to exist in Windows before the unpacking starts.

Abstracting sensible data away from the scripts also does not seem feasible, as the project is huge and that data is already all over the place.

Thanks