File Access

Give the agent checked, audited access to specific files and folders outside the project, on local drives and network shares

File access lets the agent use specific files and folders that live outside the project, such as a report on a network share or a spreadsheet in your Documents folder. By default the agent sees only its own project folder. The user grants each extra file or folder in the Levee app, as read-only or read and write, and can revoke it at any time. Every read and change is checked against policy and recorded in the audit trail.

Why not copy the files into the project?

Copying loses track of where a file came from and who may change it. Opening a whole drive to the agent gives away far too much. File access sits between the two: you grant specific files and folders, and every open, read and write on them is checked, can require the user's approval, and is audited.

What does the agent see?

Granted items appear inside the sandbox on the Levee drive (by default L:), under a path that mirrors their real location:

• Only granted items exist. Everything else on the computer is absent from the drive. The agent cannot browse its way to a folder that was not granted.
• Mapped drive letters are resolved to their network path when the grant is made, so a grant for Z:\reports appears under L:\network\<server>\<share>\reports.
• Grants can change while the project runs. Adding or revoking a grant takes effect without restarting the project.
• The drive behaves like a normal Windows drive for everyday work (reading, writing, creating, renaming and deleting files, listing folders).

Your Windows permissions are the ceiling

Files are opened as the signed-in user. A grant can never give the agent access to something the user could not open themselves, and network shares are reached with the user's own credentials. Policy narrows the user's access; it never widens it.

How does a user grant a file or folder?

In the Levee app, open the project, go to its Access Policy tab, and use the File access section:

1. Choose Add file or Add folder and pick the item.
2. Check the host location Levee shows, and choose Read-only or Read and write.
3. Choose Grant access.

To remove a grant, choose Revoke next to it. The running project receives the change immediately. Other grants that cover the same path still apply. A grant that denies a path cannot be removed from this screen, because removing a denial may increase access.

Rules for what can be granted:

• A path on a local fixed drive (for example C:\ or D:\) or on a network share (\\server\share\...). A mapped drive is converted to its network path. Other locations are refused.
• Each grant and each revocation is recorded in the audit trail (grant.added, grant.removed).

Grants are kept by the Levee service in storage only the system can read (%ProgramData%\Vediram\Levee\grants\), not in the project folder. Editing files in the project folder cannot give the agent access to anything. Projects created with an earlier Levee version start with no active grants: the user grants the files again from the app.

Project grants are placed ahead of the organization-wide rules below, so they apply first.

For your IT team: organization-wide rules (proxies.fs)

Administrators can add rules that apply to every project in the proxies.fs section of the Levee policy. Use them to fence off sensitive folders, or to share a reference folder with every project.

{
  "proxies": {
    "fs": {
      "default": "deny",
      "rules": {
        "paths": [
          { "path": "C:\\Users", "access": "deny" },
          { "path": "\\\\corp-fs\\finance\\reference", "access": "read" },
          { "path": "\\\\corp-fs\\hr", "access": "deny" }
        ]
      }
    }
  }
}

If the fs section is malformed (for example, not an object), Levee replaces it with a deny-by-default section and logs an error. Each project then gets only its own grants.

How is access decided?

A denial always wins; otherwise the closest matching grant decides, and anything beyond it asks the user. In order:

1. Any matching deny wins, wherever it appears in the list. Use deny rules to fence off sensitive folders inside broader grants.
2. Otherwise the most specific (longest) matching path rule applies.
3. A request that goes beyond what the rule allows is sent to the user for approval, not silently refused:
   • Writing to a path granted read asks the user.
   • A path with no matching rule under default: "deny" asks the user.
4. If nobody can answer the prompt (for example, the Levee app is closed), the access is refused.

Approvals can be given for a single use (a short-lived grant, the default) or remembered until the next policy change. See Approvals.

What does the agent see when access is refused?

• A path that is denied outright behaves as if it does not exist (file or path not found). The agent cannot use refusals to discover which files are there.
• Other refusals, such as a declined approval, return Access denied.
• An attempt to follow a shortcut-style link (symbolic link or junction) out of a granted folder is refused.

The real reason for every refusal is in the audit trail, not in the error the agent sees.

Audit

Decision reasons use a fixed vocabulary, which makes them easy to filter and alert on:

Requirements and design limits

• Windows 11 Pro, Enterprise or Education. File access is not available on Windows Server.
• Documents and data only. Programs cannot be started from the Levee drive, and the files a program loads (such as DLLs) cannot be loaded from it. Provide tools to the agent as AI tools or plugins instead.
• Updating the Levee file system component requires a restart of the computer, like other file system drivers.
• The Levee drive reports a fixed size and free space figure, not the size of the underlying disks. Tools that check free space before writing see that figure.
• Features that only NTFS provides are not available on the Levee drive: alternate data streams, extended attributes, file locking ranges and NTFS security descriptors. Windows permissions are still enforced outside the sandbox, as the signed-in user.
• Paths longer than 1,024 characters are not supported.
• Endpoint security products. Levee's file system component is a file system driver. As with any such driver, test it alongside your endpoint detection and data loss prevention products before a broad rollout.

Related

• How Policy Works
• Projects
• Sharing files with a project
• Approvals
• Security Model and Limits