I use AI applications fairly regularly. They help me inspect repositories, review and write code, reason through architecture, search project history, summarize information, and move through work much faster than I could if every step stayed manual. That does not mean I want every one of those applications to inherit every permission my Windows account has.
The more capable these tools become, the stranger that default starts to feel. A coding assistant may only need access to one repository and the Internet, but if I launch it normally, Windows may treat it exactly like any other application running as me. If I can open a file, there is a good chance the application can open it too.
That is the problem that eventually became Scylla.
The issue is not whether I trust the model
Most conversations about AI security immediately turn into a debate about whether a company is trustworthy, whether a model would intentionally read something it should not, or whether a vendor promises not to use local data in some particular way.
Those are reasonable questions, but they are not the question I was trying to solve. My question was much simpler:
Why does this application have access to things it does not need?
If I open a coding tool against A:\drivefolder\scylla, it does not need my grocery list. It does not need another client’s source code, my SSH directory, unrelated drives, browser profiles, or every other project I have touched in the last decade. Good security usually starts by reducing unnecessary authority. I wanted the same principle applied to AI applications.
Windows normally gives the application my identity
On a normal desktop, applications are generally launched using the Windows identity of the person running them. That is convenient because software can immediately use your files, preferences, application data, credentials, and other resources. It is also why most desktop software feels seamless after installation.
The problem is that convenience creates a very broad trust relationship. If my account can read five hundred directories and I launch an AI application as my account, the application may inherit access to those same five hundred directories. The fact that I only intended to use it with one of them does not create a security boundary.
Intent and permission are two very different things.
My first approach was a real application container
The first version of Scylla tried to solve this with Windows AppContainer. The idea was straightforward: create a restricted application identity, give it access to a small list of directories, allow the capabilities it needs, and deny everything else by default. For compatible applications, this works well.
Scylla could launch a process into that restricted environment, grant read/write access to one project, perhaps read-only access to a reference directory, and leave the rest of the machine outside the application’s reach.
That gave me the model I wanted:
Application
Allowed:
RW A:\drivefolder\scylla
RO A:\notherfolder
Everything else:
not granted, get lostThe UI followed the same idea. Pick the application, add the folders it is allowed to use, choose read-only or read/write, and click RUN APP.
That part was easy to understand. Windows compatibility was less cooperative.
“Full trust” changed the problem
Some Windows applications are packaged in a way that expects a normal, full-trust Windows process. The Microsoft Store version of ChatGPT was the case that forced the next architectural change. It would run normally as my Windows account, but Windows would not let me force that particular application into the AppContainer boundary I had built.
At that point there were two possible responses. The first was to weaken Scylla until the application launched and then pretend the result was still isolated.
That was not acceptable.
The second was to stop trying to make every application fit the same containment mechanism. That turned out to be much more useful.
Full trust does not have to mean full trust as me
The key distinction is that “full trust” describes the process relative to the Windows user running it.
It does not mean the application has to run as my user. So I created another account on the machine:
ScyllaUserIt is a normal local Windows user. It is not an administrator, it does not have my SSH keys, it does not have my browser profile, it does not own my project directories, and it does not inherit my personal application state.
It has its own ordinary Windows profile:
A:\Users\ScyllaUserThat means an application can still have everything it expects from a normal Windows session. It gets its own AppData, temporary directory, registry profile, local application state, and user environment. It just gets those things as ScyllaUser, not as me. That changes the entire trust model.
Scylla stays me, the application does not
I still run the Scylla application normally from my account. Scylla acts as the wrapper and launcher. When I tell it to start an application in Isolated User Mode, the target process is created using the ScyllaUser identity instead of my own.
Conceptually it looks like this:
My Windows account
|
+-- Scylla
|
+-- ChatGPT.exe
User: ScyllaUserScylla then verifies that identity after launch. If the target process somehow starts as my account instead, the session is considered a failure rather than quietly continuing. The same verification applies to child processes. If an application starts helpers, workers, terminals, or other subprocesses, Scylla can verify that those processes are also running under the isolated identity.
That matters because the parent window is not the only process that can touch the filesystem.
Files are granted deliberately
A separate Windows account gives Scylla a much cleaner filesystem boundary. For example, I can keep a data drive accessible to my user, Administrators, and SYSTEM while giving ScyllaUser no rights at the drive root. Scylla can then add a temporary permission to one specific project when I launch an application.
A session might look like this:
ChatGPT
Identity:
ScyllaUser
Filesystem:
RW A:\drivefolder\scylla
RO A:\reference
Other private drives:
no accessWhen the application stops, Scylla removes the temporary permissions it added. The isolated user remains on the system because applications need somewhere to keep their own settings and login state. The project permissions do not need to remain open. That separation is important. The user identity is persistent, the access grants are intentional and temporary.
Windows permissions still have nuance
There is one important complication: Windows permissions are cumulative. A folder may already grant access to broad groups such as Users or Authenticated Users. Because ScyllaUser is a normal standard account, it can inherit rights through those groups even if Scylla never explicitly granted them.
That means Scylla cannot honestly say, “this application can only access these two folders,” simply because those are the two folders shown in the UI. It has to check.
The next part of the design is an ambient-access audit. Scylla distinguishes between access it explicitly granted and access the isolated Windows identity already had because of existing folder permissions. That lets the application report something much more useful:
Identity:
VERIFIED
Explicit grants:
RW A:\drivefolder\scylla
Ambient access:
RO A:\shared
Allowlist:
DEGRADEDI would rather have the software tell me the boundary is imperfect than display a reassuring green icon that is technically false.
This is an application wrapper, not a magic shield
Scylla is intentionally becoming an application wrapper rather than a single sandbox technology. For an application that behaves correctly inside AppContainer, Scylla can use the stronger AppContainer path. For an application that requires a normal full-trust desktop environment, Scylla can run it under the isolated Windows identity instead.
The operator experience can stay simple:
1. Choose the application.
2. Choose the folders it may use.
3. Choose read-only or read/write.
4. Run the application.Scylla handles the ugly Windows details underneath that interaction. It can discover known installed tools, including applications installed through different Windows mechanisms, while still allowing a normal executable to be selected through Explorer. The application does not need to know Scylla exists.
From its perspective, it is simply running on Windows.
Why this matters more as AI tools become more capable
An AI application that can only generate text is one thing. An AI application that can inspect files, edit code, execute commands, launch subprocesses, call APIs, interact with repositories, and retain local state is something else entirely. Those capabilities are useful precisely because they allow the software to act on the machine.
That also means the consequences of unnecessary access are larger. This does not require assuming malicious intent. Software has bugs, models misunderstand requests, agents make poor decisions, plugins behave unexpectedly, and users occasionally approve something they did not fully inspect. The safer default is not “trust the application to ignore everything else.”
The safer default is:
Do not make everything else available.
There are still boundaries Scylla does not solve automatically
A separate Windows identity is a strong and useful boundary, but it is not the same thing as placing the entire application inside a virtual machine. Network access is a separate problem. If an application can reach the Internet, it can transmit anything it is actually able to read, so filesystem isolation still matters. Windows also has shared desktop behavior, system-wide resources, public locations, and permissions that may already be broader than expected. Scylla needs to verify those conditions rather than assuming that creating another user account magically fixes every security problem.
That is why I am building the verification into the product instead of treating account creation as the finish line. The important security questions remain visible:
Who owns this process?
Which files did Scylla grant?
What could this user already access?
Did every child process keep the same identity?
Were temporary permissions removed when the application stopped?Those questions are much more useful than simply asking whether the application is “sandboxed.”
The same principle applies on a Mac
Scylla is a Windows application because Windows is where I work, and I do not make applications for Mac people. The underlying security idea is not Windows-specific, though. macOS has its own application sandbox, permission system, user accounts, filesystem permissions, and privacy controls, all built around the same basic concept: software should only receive access to the resources it actually needs.
Apple’s App Sandbox is, in some ways, an even cleaner example of this philosophy. A sandboxed Mac application gets its own container, and the operating system can extend access when the user deliberately selects a file or folder. macOS can distinguish between read-only and read/write access, while its normal Unix permissions and ACLs still apply underneath that sandbox.
A separate low-privilege user can also provide the same broader identity boundary I am using with ScyllaUser. The application gets a normal home directory, preferences, caches, and application state under that account, while another user’s files remain separate unless permissions explicitly make them available. The implementation details would obviously be different from Scylla, but the model is the same: give the application a constrained identity first, then deliberately extend access to the data it needs.
Someone could absolutely build a Mac version of this idea. It probably just will not be me. The important part is that the operating system already provides enough separation primitives that “the application runs on my computer” does not have to mean “the application inherits everything I can access.”
I am not trying to make AI difficult to use
There is a version of security that makes a system technically safer by making it miserable. That is not the goal here. I want to open Scylla, choose Cursor, Codex, ChatGPT, or another local tool, select the project directories that matter, and start working. The wrapper should handle the isolation without turning every session into a security administration exercise.
The ideal result is boring.
The application works normally. It can read the files I gave it. It can write where I allowed it to write. It can keep its own local application state. It simply does not get the rest of my computer for free.
Scylla is still early
I am building Scylla in public github.com/nrek/cxl-scylla. Parts of the implementation are still being hardened as I test different application types and Windows behaviors. The goal is not to publish another checkbox-heavy “AI security” product before the underlying boundaries are proven.
What interests me is the general use case. There are a growing number of people who want powerful AI applications on their own computers while remaining cautious about how much of the machine those applications can touch. They should not have to choose between useful local software and unrestricted access to their digital life.
The principle is older than AI
None of this is a new security philosophy. Operating systems have been separating users, privileges, processes, and resources for decades. Least privilege is not an AI concept, and neither is isolating software from data it has no reason to access. AI simply makes the old principle feel urgent again because the software is becoming much more active.
The more an application can do for me, the less interested I am in granting it permissions based on convenience alone.
Scylla came out of that tension. I want capable tools. I also want a clear answer when I ask:
Why can this application see that?
If the answer is “because your Windows account can,” that is no longer good enough.