dictionary · Allowed Root
What Is an Allowed Root? Limiting AI File Access
Learn how Allowed Root limits AI file access to approved folders, with lessons from OGINAU Remote Windows tests and move-operation boundaries.
Conclusion first
An Allowed Root is a security boundary that limits the files an AI or external Tool can operate on to a specified folder and its descendants.
If you want AI to work in a project folder on your PC, you do not need to grant access to the whole computer. The execution component should enforce the folder boundary; merely prompting an AI to avoid other folders is not sufficient.
Definition
“Root” here means the starting folder for approved operations, not necessarily a drive’s system root. Consider this illustrative Windows path:
C:\Users\Example\Documents\AI-Workspace\| File location | Expected boundary |
|---|---|
| Meeting notes inside AI-Workspace | Eligible for permitted operations |
| A subfolder of AI-Workspace | Eligible for permitted operations |
| Another folder in Documents | Outside the boundary; reject |
| Windows system folder | Outside the boundary; reject |
The example does not imply that all actions within the folder are authorized. Read, write and other operation permissions remain separate.
How it works
A typical design follows five steps:
- Choose the allowed workspace. A user or administrator defines the permitted folder.
- Receive an AI request. For example, read notes or save a document.
- Validate the requested path at the executor. Do not rely on the AI’s own choice.
- Execute only permitted operations. Reject out-of-root requests before accessing the target.
- Return a clear outcome. Distinguish success, rejection and missing files.
File moves require checking both ends
For reading, the source matters; for saving, the destination matters. Moving or renaming a file involves both its source and destination. Allowing a move from an approved folder to an unapproved destination would cross the intended boundary.
Why string matching is not enough
Path containment is not safely implemented with a simple text prefix test. Implementations must account for parent references such as .., similarly named sibling folders, symbolic links or Windows reparse points, and file-system changes around execution time.
Path checks must reflect the operating system’s actual resolution behavior.
Why the boundary matters
A request such as “summarize yesterday’s estimates” does not necessarily require searching the entire PC. Restricting the operation to the approved workspace makes the task boundary clearer.
However, an Allowed Root cannot prevent all mistakes inside the permitted folder. Write, delete and other operations may need separate controls.
Commonly confused concepts
What Is OAuth Scope? explains how Scope expresses permissions delegated to an external app. An Allowed Root answers a different question: which file locations on a PC may be accessed?
| Control | Main question |
|---|---|
| OAuth Scope | Which kinds of access were delegated? |
| Allowed Root | Which filesystem area is in scope? |
| Tool permissions | Which operations may be performed? |
| OS access control | Can the executing identity access that file? |
These are complementary, not interchangeable.
How this relates to OGINAU
OGINAU Remote is being developed to connect AI applications with files on a user’s Windows PC. Its development work distinguishes whether a file operation works from whether an out-of-bound operation is refused.
Real Windows execution
An initial end-to-end test series recorded five passing checks for requests reaching the Windows computer and returning results, including file-related operations. That established more than Tool discovery: actual execution results were returned.
Both source and destination are checked
OGINAU Remote’s documented design applies Allowed Root validation to both sides of a file move or rename. A move outside the approved workspace crosses the boundary, even if the source file was originally inside it.
Negative-test evidence is separate
OpenAI reviewer test materials also include out-of-root rejection cases alongside permitted read, write and move actions. A documented test case is not itself proof that every rejection test has passed on every device. Initial live E2E results, development smoke-test results and reviewer test plans are distinct types of evidence.
The practical takeaway is that both successful authorized execution and refusal of unauthorized operations must be tested. This article does not disclose private file paths, credentials, internal authorization steps or sensitive infrastructure details.
Frequently asked questions
Is an Allowed Root just a prompt telling AI to stay in one folder?
No. It must be enforced by the component performing file operations.
Can AI edit or delete everything inside the allowed folder?
Not necessarily. Operation permissions and OS access controls still apply.
Can more than one folder be allowed?
A system may support multiple allowed areas, but actual capabilities depend on the implementation.
Does an Allowed Root automatically protect all secrets?
No. Sensitive files inside the allowed area still require proper permissions and handling.
Sources and primary information
-
Microsoft Learn: Naming Files, Paths, and Namespaces: Windows filesystem paths.
-
Microsoft Learn: Reparse Points: reparse points in Windows.
-
OWASP: Path Traversal: risks of directory escape.
-
OGINAU Remote development records: initial five passing live Windows E2E checks, validation of move source and destination, public smoke tests, and documented reviewer out-of-root scenarios.
Summary
An Allowed Root restricts AI file operations to an explicitly approved area of the filesystem.
Enforce it at execution time instead of relying on prompts. Check both ends of a move. And verify not only that approved operations work, but also that disallowed requests are rejected.