IMO, for real file systems, just give a view via cgroups/namespaces.
Implementing a database abstraction as a file system for an LLM feels like an extra layer of indirection for indirection's sake: just have the LLM write some views/queries/stored procs and give it sane access permissions.
LLMs are smart enough to use databases, email, etc without needing a FUSE layer to do so, and permissions/views/etc will keep it from doing or seeing stuff it shouldn't. You'll be keeping access and permissions where they belong, and not in a FUSE layer, and you won't have to maintain a weird abstraction that's annoying/hampered with licensing issues if you want to deploy it cross platform.
Also, your simplified FUSE abstraction will not map accurately to the state of the world unless you're really comprehensive with your implementation, and at that point, you might as well be interacting directly in order to handle that state accurately.
Agree that to far fetched mappings to files don’t really make sense. The email example is more illustrative then real world inspired, thought it might be good to show how flexible the approach is.
I think there is a gap between “real file systems” and “non file things in a database” where mapping your application representation of things to a filesystem is useful. Basically all those platforms that let users upload files for different purposes and work with them (ex Google Drive, notion, etc). In those cases representing files to an agent via a filesystem is the more intuitive and powerful interface compared to some home grown tools that the model never saw during training.
LLMs can handle Google drive perfectly well with a service account, including the Google drive specific quirks through the API. It could be helpful to expose via a file system rather than a custom API if you wanted a different interface than Google already provides, but this wouldn’t be driven by the limitations of the LLM.
In terms of ergonomics, I’d say a filesystem is more intuitive for an agent than the Google Drive API even if it can handle both. Hard to argue without building an eval set and evaluating both, though.
I’ve been doing this recently and for the basics agents had no problem with the API apart from the weird behaviour of shared drives needing a special flag to handle them. This could probably be mapped to a file system in a way that wouldn’t trip up an agent, but at the expense of losing the Google drive specific functionality. A trade off, not much better or worse per se, but with the added complexity of the FUSE layer.
I've been getting into FUSE a bit lately, as I stole an idea that a friend had of how to add CoW features to an existing non-CoW filesystem, so I've been on/off been hacking on a FUSE driver for ext4 to do that.
To learn FUSE, however, I started just making everything into filesystems that I could mount. I wrote a FUSE driver for Cassandra, I wrote a FUSE driver for CouchDB, I wrote a FUSE driver for a thing that just wrote JSON files with Base64 encoding.
None of these performed very well and I'm sort of embarrassed at how terrible the code is hence why I haven't published them (and they were also just learning projects), but I did find FUSE to be extremely fun and easy to write against. I encourage everyone to play with it.
- agents tend to need (already have) a filesystem anyway to be useful (not technically required but generally true, they’re already running somewhere with a filesystem)
- LLMs have a ton of CLI/filesystem stuff in their training data, while MCP is still pretty new (FUSE is old and boring)
- MCP tends to bloat context (not necessarily true but generally true)
UNIX philosophy is really compelling (moreso than MCP being bad). if you can turn your context into files, agents likely “just work” for your use case
> My prediction is that one of the many sandbox providers will come up with a nice API on top of this that lets you do something like ... No worrying about FUSE, the sandbox, where things are executed, etc. This will be a huge differentiator and make virtual filesystems easily accessible to everyone.
I've done exactly that with the Filestash [1] virtual filesystem plugin [2] that can connect to any possible system be it some kind of filesystem with support for sftp, s3, gdrive, dropbox, ftp but not only with support for mysql and postgres where the first level folder is the list of databases, second level folder is the list of table within the DB and each row is represented as a form file generated from the underlying schema, ...
The whole thing is available as a MCP [4] and been published to the openai marketplace since around Christmas but somehow still pending for review.
I did a demo a few days ago where AD had a role information from which devs had mounts available as /dev/ /test/ /prd/ and compliance had access to many other folders as readonly. It tooks 5 minutes to configure, with 0 custom code
For ZeroFS [0], I went an alternate route with NFS/9P. I am surprised that it’s not more common as this approach has various advantages [1] while being much more workable than fuse.
Interesting! The network first point makes a lot of sense, especially bc you will most likely not access your actual datastore within the process running in the sandbox and instead just call some server that handles db access, access control etc.
I am so sick of the ‘sandboxed’ AI-infra meme. A container is not a sandbox. A chroot is not a sandbox. A VM is also not a sandbox. A filesystem is also also not a sandbox. You can sandbox an application, you can run an application in a secure context, but this is not a secure context the author is describing, firstly, and secondly they haven’t described any techniques for sandboxing unless that part of the page didn’t load for me somehow.
Didn’t mean to say this is a sandbox, it certainly isn’t, this is just an illustration on how to bridge the gap and make things available in a file system from the source of truth of your application.
There is tons of more complexity to sandboxing, I agree!
IMO, for real file systems, just give a view via cgroups/namespaces.
Implementing a database abstraction as a file system for an LLM feels like an extra layer of indirection for indirection's sake: just have the LLM write some views/queries/stored procs and give it sane access permissions.
LLMs are smart enough to use databases, email, etc without needing a FUSE layer to do so, and permissions/views/etc will keep it from doing or seeing stuff it shouldn't. You'll be keeping access and permissions where they belong, and not in a FUSE layer, and you won't have to maintain a weird abstraction that's annoying/hampered with licensing issues if you want to deploy it cross platform.
Also, your simplified FUSE abstraction will not map accurately to the state of the world unless you're really comprehensive with your implementation, and at that point, you might as well be interacting directly in order to handle that state accurately.
Agree that to far fetched mappings to files don’t really make sense. The email example is more illustrative then real world inspired, thought it might be good to show how flexible the approach is.
I think there is a gap between “real file systems” and “non file things in a database” where mapping your application representation of things to a filesystem is useful. Basically all those platforms that let users upload files for different purposes and work with them (ex Google Drive, notion, etc). In those cases representing files to an agent via a filesystem is the more intuitive and powerful interface compared to some home grown tools that the model never saw during training.
LLMs can handle Google drive perfectly well with a service account, including the Google drive specific quirks through the API. It could be helpful to expose via a file system rather than a custom API if you wanted a different interface than Google already provides, but this wouldn’t be driven by the limitations of the LLM.
In terms of ergonomics, I’d say a filesystem is more intuitive for an agent than the Google Drive API even if it can handle both. Hard to argue without building an eval set and evaluating both, though.
I’ve been doing this recently and for the basics agents had no problem with the API apart from the weird behaviour of shared drives needing a special flag to handle them. This could probably be mapped to a file system in a way that wouldn’t trip up an agent, but at the expense of losing the Google drive specific functionality. A trade off, not much better or worse per se, but with the added complexity of the FUSE layer.
The less juggling of concepts thr more effective any problem solver cam be.
I've been getting into FUSE a bit lately, as I stole an idea that a friend had of how to add CoW features to an existing non-CoW filesystem, so I've been on/off been hacking on a FUSE driver for ext4 to do that.
To learn FUSE, however, I started just making everything into filesystems that I could mount. I wrote a FUSE driver for Cassandra, I wrote a FUSE driver for CouchDB, I wrote a FUSE driver for a thing that just wrote JSON files with Base64 encoding.
None of these performed very well and I'm sort of embarrassed at how terrible the code is hence why I haven't published them (and they were also just learning projects), but I did find FUSE to be extremely fun and easy to write against. I encourage everyone to play with it.
Why not just MCP? Feels like easier to implement and doesn't need a filesystem/root/admin perms?
a few reasons:
- agents tend to need (already have) a filesystem anyway to be useful (not technically required but generally true, they’re already running somewhere with a filesystem)
- LLMs have a ton of CLI/filesystem stuff in their training data, while MCP is still pretty new (FUSE is old and boring)
- MCP tends to bloat context (not necessarily true but generally true)
UNIX philosophy is really compelling (moreso than MCP being bad). if you can turn your context into files, agents likely “just work” for your use case
Welcome back Plan9
> My prediction is that one of the many sandbox providers will come up with a nice API on top of this that lets you do something like ... No worrying about FUSE, the sandbox, where things are executed, etc. This will be a huge differentiator and make virtual filesystems easily accessible to everyone.
I've done exactly that with the Filestash [1] virtual filesystem plugin [2] that can connect to any possible system be it some kind of filesystem with support for sftp, s3, gdrive, dropbox, ftp but not only with support for mysql and postgres where the first level folder is the list of databases, second level folder is the list of table within the DB and each row is represented as a form file generated from the underlying schema, ...
The whole thing is available as a MCP [4] and been published to the openai marketplace since around Christmas but somehow still pending for review.
I did a demo a few days ago where AD had a role information from which devs had mounts available as /dev/ /test/ /prd/ and compliance had access to many other folders as readonly. It tooks 5 minutes to configure, with 0 custom code
ref:
[1]: https://github.com/mickael-kerjean/filestash
[2]: https://www.filestash.app/docs/guide/virtual-filesystem.html
[3]: https://imgur.com/Ewk3nAg
[4]: https://www.filestash.app/docs/guide/mcp-gateway.html https://github.com/mickael-kerjean/filestash/tree/master/ser...
I've implemented agentic framework exactly like this for my current employer.
It opens up absolutely bonkers capabilities.
For ZeroFS [0], I went an alternate route with NFS/9P. I am surprised that it’s not more common as this approach has various advantages [1] while being much more workable than fuse.
[0] https://github.com/Barre/ZeroFS
[1] https://github.com/Barre/ZeroFS?tab=readme-ov-file#why-nfs-a...
Interesting! The network first point makes a lot of sense, especially bc you will most likely not access your actual datastore within the process running in the sandbox and instead just call some server that handles db access, access control etc.
I am so sick of the ‘sandboxed’ AI-infra meme. A container is not a sandbox. A chroot is not a sandbox. A VM is also not a sandbox. A filesystem is also also not a sandbox. You can sandbox an application, you can run an application in a secure context, but this is not a secure context the author is describing, firstly, and secondly they haven’t described any techniques for sandboxing unless that part of the page didn’t load for me somehow.
Wait, can you provide the positive definition for "sandbox" you're relying on here?
Didn’t mean to say this is a sandbox, it certainly isn’t, this is just an illustration on how to bridge the gap and make things available in a file system from the source of truth of your application.
There is tons of more complexity to sandboxing, I agree!
Please brother may i have some pledge unveil