Permissions

Swarmfile's permission model is built from access control lists (ACLs) applied to folders and files, layered on top of a per-project mode that decides what happens when no grant exists at all.

Read, write, admin#

Every grant is one of three levels, and each level can be either an allow or a deny:

A grant is set on a specific folder or file and is inheritable down the tree beneath it. You don't have to re-grant access at every nesting level - set it once on a parent folder and everything under it inherits the grant unless something more specific overrides it further down.

How resolution works#

When Swarmfile decides whether you can do something to a file, it walks up the ancestor chain from that file to the project root, collecting every grant that applies to you along the way.

Deny always wins. If a deny shows up anywhere in that ancestor chain, it overrides any allow found elsewhere in the chain - no matter which one is "closer" to the file. This is a deliberate, conservative default: a broad deny placed high up in a folder tree is a reliable way to lock something down, and nobody can accidentally punch a hole in it with a more specific allow lower down.

Org owners bypass ACLs entirely. An owner can always get into any project, folder, or file in their org, regardless of what grants exist. ACLs govern members; they don't govern the owner.

Open vs. protected projects#

Each project runs in one of two modes, set at the project level:

• Open mode (default) - access is permissive by default. ACLs function as additive grants layered on top of general access, useful for restricting specific sensitive folders without having to explicitly grant everything else.
• Protected mode - access is default-deny. Nothing in the project is accessible without an explicit grant. Use this for projects where you want to enumerate exactly who can see what, rather than opt specific things out.

Switching a project's mode doesn't rewrite existing grants - it changes what happens when no grant matches at all. See Organizations, Projects & Members for project lifecycle and mode selection.

Windows DACL projection#

On Windows, Swarmfile projects the effective ACL permissions it's enforcing down onto the actual NTFS-style DACL that Windows and Explorer see on the mounted drive. That means the Windows-native permission dialogs - and any Windows software that inspects file ACLs directly - see something consistent with what Swarmfile is actually enforcing. Permissions aren't just an app-level restriction invisible to the rest of the OS; they show up as real Windows ACL entries on the mount.

Plan requirements and downgrades#

Folder ACLs and Windows DACL projection are Pro plan and above. They're enforced server-side - the tenant checks a forwarded entitlements header before honoring an ACL operation, so this isn't a client-side toggle that a modified client could bypass.

If an org is later downgraded below the tier that supports ACLs, existing grants keep working and nothing is silently opened up. The only thing that changes is:

• Revoking or narrowing a grant - always available, on any plan. You can never be stranded unable to fix an over-broad permission just because the org downgraded.
• Adding a new grant - blocked on a downgraded plan, until the org upgrades again.

This mirrors the downgrade behavior for identity features - see Identity - and is intentional: a downgrade should never leave you less secure, only less able to add new access.

For the broader security model - tenant isolation, storage namespacing - see Security.