Nash Is Now Open Source 🎉
Big news: Nash is now open source.
You can find the repo here 👉 github.com/Backboard-io/nash
Nash started as an internal tool to make AI actually usable day-to-day — not a chat window bolted onto a model, but a real workspace. As of this release, it's open for anyone to use, fork, self-host, contribute to, or build on top of.
Alongside open-sourcing the project, we're also shipping a major release that pulls Nash's features into a single, connected experience. Here's what's new.
🎨 Image Generation, End-to-End
Image generation is now integrated end-to-end inside Nash.
Go from a rough idea → a first draft → iterations → a finished image without ever leaving the conversation. No context switching, no copying prompts between tools, no losing your thread.
Create, iterate, and keep working from the same experience.
📄 Reliable Document Creation
Whether you're turning an idea into a draft or generating a document as part of a larger workflow, Nash can now carry that process through from request to finished output.
Ask for a PDF, a spec doc, a Word file, a code file — and Nash treats it as a first-class output rather than a side effect of chat.
🔌 MCP Connectivity (Including Google MCP)
This release adds support for MCP (Model Context Protocol), including Google MCP, expanding what Nash can access and work with as part of your workflows.
Instead of keeping your AI isolated from the rest of your work, MCP gives Nash a way to connect with the systems around it — the tools, data, and services you already use every day.
If you've been waiting for an assistant that actually plugs into your stack instead of living beside it, this is the update for you. And since Nash is open source, you can wire up your own MCP servers, extend the integrations, or contribute new ones back to the project.
🖼️ A Library for Your Generated Images
Ever generated the perfect image and then lost it three conversations later? Same.
Nash now has a Library where your generated images are stored automatically, giving you one place to browse and access previous creations directly. Nothing to configure — it just works.
The Bigger Picture
This release is about making Nash feel less like a collection of AI features and more like one connected workspace:
- End-to-end image and document generation means outputs feel first-class.
- MCP means Nash lives inside your ecosystem, not next to it.
- The Library means your work sticks around.
And now, all of it is open source. You can read the code, self-host it, extend it, or ship a fork of your own.
Get Involved
We'd love your help shaping where Nash goes next:
- ⭐ Star the repo: github.com/Backboard-io/nash
- 🐛 Open issues for bugs, ideas, or feature requests
- 🔧 Send PRs — integrations, MCP servers, UI improvements, all welcome
- 💬 Try it live at hellonash.ai
Ask for something. Create it. Connect the tools you already use. Come back to your work later.
Say hello to your new AI workspace. 👋
Top comments (3)
Congrats on the open-source release: the combination of a persistent workspace and MCP connectivity is particularly interesting.
One security question I’d be curious to see covered as Nash evolves: how do you enforce trust boundaries between the workspace, MCP servers, and the model?
Once MCP can access external systems and the Library persists generated/connected data, the security model becomes more than just “what can the model generate”. You have tool authorization, data access, persistence, and potentially untrusted content all crossing the same agent boundary.
In particular, I’d be interested in how Nash approaches per-user/workspace isolation, MCP permission scoping, credential boundaries, and prompt injection from tool-returned content.
Making the project open source is a great opportunity here too, because those boundaries can become part of the architecture that the community can inspect and reason about.
Congrats again, and thanks for open-sourcing it. Looking forward to seeing how the security model develops alongside the MCP integrations. 🔐
Hi Marco, you can give it a try in production at HelloNash.ai.
Quick rundown of how we're thinking about it:
Trust zones. Three of them: user/workspace (trusted, strictly per-user), the model (semi-trusted, anything it reads can try to manipulate it), and MCP servers (untrusted by default, even ones we wrote ourselves). Rule of thumb is data from a lower-trust zone never inherits privileges of a higher one.
Workspace isolation. Hard tenant boundary at the DB layer, not just app logic. Workspace ID comes from the server-side session, never from tool args or the model.
MCP scoping. Explicit allowlist per server, install-time consent for capabilities, runtime confirmation for anything destructive or that sends data out. Short-lived capability tokens instead of ambient auth.
Credentials. Never in the model context. The runtime injects them at the edge when a tool actually gets called. Per-workspace keys in a proper secret store.
Tool-returned content. This is the big one. Anything a tool returns is attacker-controlled (webpages, emails, issues, whatever). We're leaning on structural separation of data vs instructions in context, egress gating after untrusted reads (kills the classic "read email then send email" injection chain), and provenance tags on every chunk.
Persistence risk. Since the workspace sticks around, an injection written into memory today can fire weeks later. Memory writes go through a policy layer, memories carry trust labels (user-authored vs tool-derived), and users can audit or purge anytime.
Nothing formal written up yet, but the repo is open, jump in and PR anything you think should be tighter. More eyes means better boundaries.
Open-sourcing Nash is interesting because an AI workspace becomes much more useful when you can see how it works, adapt it, and potentially connect it with your existing workflow. The bigger shift is toward AI tools becoming everyday workspaces rather than simple chatbots. Brainator sits in a similar practical-AI space, focusing on tools that turn AI capabilities into useful, task-specific workflows.