Folders and Permissions in MITO: Who Can See What
Two settings, one toggle. The useful part is that it shows you the consequences before you commit to them.
Start with the thing that trips everyone up.
Public does not mean published on the internet. A public folder or project is shared through your workspace, with the people already in it, at the roles they already hold. Nothing about it is visible to the outside world. The word is doing a smaller job than it looks.
Private is the other setting: the folder or project stops taking its access from the workspace and runs off its own list instead.
Where access comes from
Access arrives from up to three places, and they stack rather than override each other. This is the whole model, and it is easier seen than read.
Three people, three different versions of the same screen. Each one is a different route in.
The workspace reaches everything that is public. A private folder stops it at the edge.
A folder invitation reaches that folder’s public projects, including ones added later. It does not reach a private project sitting inside the folder, which is why Ana gets Project A and a locked card where Project B should be.
A project invitation goes straight to one project and ignores the folder entirely. Ben can open Project B without ever seeing the folder it lives in, or anything else in it.
The useful consequence: a private folder is how you fence off a body of work, and a direct project invitation is how you let one person through for one thing.
Doing it
Folders, then permissions, end to end.
Folders sit above your projects on the Projects page. New folder, name it, then either pick the folder from a project’s menu or drag the project card onto it. The folder’s own menu has open, copy link, rename, settings and delete. Privacy lives under General access in folder settings.
When you switch a folder to private, MITO lists everyone who currently has access and says what each of them will see afterwards, some losing it outright and others left with a locked card. You tick who keeps access before anything happens.
The parts that catch people out
Everything starts public. New folders and new projects are public by default. A project you create inside a private folder is itself public, and it is the folder keeping it in. Move it out and it is open to the workspace.
A public project in a private folder is still private in practice. The folder is doing the work. Making that project public changes nothing while it sits there, because the folder still decides.
Access stacks, so removing one grant does not remove the others. Take someone off a folder and a separate project invitation still lets them in. Take them off a project and workspace or folder access may still cover it. If you need someone out, check every route rather than the one you remember.
Moving a project changes its audience without changing its setting. Move a public project out of a private folder and it is suddenly open to the workspace. Move it between private folders and it swaps audiences. A private project stays private wherever it goes. The move dialog does not warn you about any of this, so it is worth a thought before dragging things around.
Deleting a folder does not delete the projects. They come back out to the top level. Anyone who only had access through that folder loses it.
There are no nested folders. One level, which is a constraint worth knowing before you plan a structure around it.
The two doors that are easy to miss
Privacy settings are not the only way work gets out, and these two surprise people.
A project link is not an invitation. Forwarding a URL grants nothing. Whoever opens it still needs access by one of the three routes above. That is the good news.
An asset share is a separate door, and it stays open. Anyone with editing rights on a project can share an individual asset publicly, and opening the Share panel on a finished asset can create that public link in the act of looking. Changing the project’s privacy afterwards does not retire it. Removing the person who made it does not retire it. It has to be set back to private on the asset itself.
That is the one to remember. A private project can still have a public asset hanging off it, and nothing about the folder will tell you.
Who can do what
| Role | Can |
|---|---|
| Owner | Everything, including privacy and invitations |
| Editor | Open, edit and generate |
| Commenter | See and comment. Cannot spend credits |
| Viewer | See only |
Workspace roles are Owner, Editor and Commenter. There is no separate Admin.
Two details worth holding on to. Editing is not administration: being an Editor on something does not let you invite other people or change its privacy. And guests, meaning people invited to a folder or project without workspace membership, can hold Editor on a project, while folder Editor access needs a workspace role that can edit.
The Commenter role is the one most teams underuse. A client or a reviewer in that seat can see the work and respond to it and cannot run a single generation against your balance.
Setting it up for real work
One private folder per client. Everything for that client in it, the client invited as a Commenter. They see their own work, nothing else, and they cannot spend your credits looking at it.
A private folder for work that is not ready. The locked card is the point: people can see something exists without seeing a draft you would rather they did not.
Direct project invitations for one-off collaborators. A freelancer who needs one project gets that project, not the folder around it. When the job ends you remove one grant.
Folders for volume. Past a certain size, everyone seeing everything stops being openness and becomes noise.
Folders for anything holding a Document. Brand rules and tone of voice are usually the most sensitive thing in a project, and folder permissions are what keep them to the right people.
How to check who can actually see something
Do not read the Private label and stop. Three things decide it:
- The project’s own invitations
- The folder it sits in, and the workspace around that
- Any public asset shares created from inside it
The third is the one people forget, and it is the only one that survives everything else you change.
The short version. Public means shared with your workspace, not with the world. Private means the folder or project runs off its own list. Access stacks from the workspace, the folder and the project, so removing someone takes removing every route. And a public asset share outlives the privacy setting that was supposed to cover it.
This walkthrough and the rest of our tutorials are inside MITO too, under Tutorials in the sidebar.
Frequently asked
- Does a public folder mean it is on the internet?
No, and this is the thing most people get wrong. Public means shared through your workspace, with the people already in it, at the roles they already hold. Nothing about it is visible outside your workspace.
- What is the difference between a public and a private folder?
A public folder takes its access from the workspace. A private folder runs off its own list, and only the people on that list can open it.
- If I am invited to a private folder, can I see everything in it?
You can see its public projects, including ones added later. You cannot see a private project sitting inside it unless you were invited to that project directly.
- Can someone open one project without seeing the folder it is in?
Yes. A project invitation goes straight to that project and ignores the folder, so the person never sees the folder or anything else in it. That is the right way to bring in a freelancer for one job.
- Is a project created inside a private folder private?
No. New folders and projects are public by default, and a project made inside a private folder is public with the folder keeping it in. Move it out and it opens to the workspace.
- I removed someone from a folder but they can still open a project. Why?
Access stacks. A separate project invitation, or workspace access, survives the folder change. To remove someone properly, check all three routes rather than the one you remember.
- Does moving a project change who can see it?
It changes the audience it inherits, not its own setting. Moving a public project out of a private folder opens it to the workspace. A private project stays private wherever it goes. The move dialog does not warn you, so check before dragging.
- What can a Commenter do?
See the work and comment on it. MITO states the part that matters on the invite itself: a Commenter cannot spend credits. That makes it the right seat for a client or a reviewer.
- How do I check who can actually see a project?
Three things decide it, not the Private label. The project’s own invitations, the folder and workspace around it, and any public asset shares made from inside it. The third is the one people forget and the only one that survives the others.
- Does making a project private retire a public asset link?
No. An asset share is a separate door. It has to be set back to private on the asset itself, and changing the project’s privacy or removing the person who made it does not close it.
The AI tool for cinematic video.
Generate, direct, and publish professional videos — powered by the best AI models.
More posts
