# FAQ > Answers to the questions people ask first about Agent NAS: what it is, how it differs from existing storage and memory tools, how it deals with security and privacy, and where the project stands. ## The basics ### What is Agent NAS? Agent NAS is network-attached storage designed around the run: every agent run works in an isolated branch and reaches data through a short-lived, narrow lease; every change can be traced and undone; and memory is plain files with provenance. It is served through mounts, Git, S3 and MCP. ### Is Agent NAS a product I can buy or download? Not yet. It is currently a concept with a draft specification (v0.2, November 2026). L0 and L1 can be built today from existing parts; the target for reference implementation v0 is the first half of 2027, and the plan after that is on the [roadmap](https://agentnas.com/roadmap/). ### How is it different from the AI agents that NAS vendors ship? The agents from vendors such as QNAP, Synology and TrueNAS manage the box. Agent NAS specifies how other agents work on the data inside the box: branches, leases, memory and forgetting. The two complement each other; see the [comparison](https://agentnas.com/compare/). ### How is it different from a vector database or a memory framework? Those are tools for retrieval and consolidation, whereas the truth in Agent NAS is plain notes with provenance. A vector store or memory framework can sit under [Agent Memory](https://agentnas.com/concepts/agent-memory/) as an indexer, and the index can always be thrown away and rebuilt. ### Is it open source? The specification and this site are licensed under CC BY 4.0. The reference implementation is planned as open source under Apache-2.0. ## Design and security ### Why files and Git rather than a database? Agents are converging on files: instructions in `AGENTS.md`, skills in `SKILL.md`, memory as Markdown, history in Git. Any tool and any model can read files, they are easy to compare, and easy to take with you. Databases and indexes are still used, but as a derived layer that can be rebuilt. ### What is the worst that can happen when a run goes wrong? The worst case is losing a disposable branch: the protected main line changes only through reviewed merges, deletes are soft, and snapshots are outside every lease. That holds when the mistake happens inside the NAS; an email already sent or an external API already called is something the NAS cannot undo. ### How does a lease relate to an OAuth token? A lease is an OAuth access token: requested by token exchange (RFC 8693) and describing paths and actions with Rich Authorization Requests (RFC 9396). What Agent NAS adds is the run-level convention, including branches, budgets and Rule of Two properties. See [Capability Lease](https://agentnas.com/concepts/capability-lease/). ### Why “notes plus a cache” for memory? So that it can be inspected, corrected, moved and forgotten. Notes are files; indexes, embeddings and summaries are computed from them with a documented recipe. If you change the embedding model, the system recomputes in the background. Notes written by a tainted session go into quarantine first and are not autoloaded until reviewed. ### Can Agent NAS stop prompt injection? No. Nothing outside the model can stop it completely. Agent NAS limits what an injected agent can do: [Trust Labels](https://agentnas.com/concepts/trust-labels/) keep a session that read external content from also holding sensitive data and an outbound channel, and consequential actions need a [Human Gate](https://agentnas.com/concepts/human-gate/). The honest limits are on the [security](https://agentnas.com/security/) page. ### How does it handle the “right to be forgotten”? Through [Cascade Forget](https://agentnas.com/concepts/cascade-forget/): it deletes summaries, embeddings and notes derived from a source along lineage, handles history by retention class, and destroys keys for the `sensitive` class (crypto-shredding). Its report explicitly lists what it cannot cover: copies outside the NAS, model-provider logs and model weights. It cannot make a model forget anything. ### Do I have to use MCP? No. MCP is just one of the control-plane interfaces; files, Git and S3 do not need it, and the protocol layer is designed to be replaceable. ## Adoption and the future ### Will it replace my existing NAS or cloud storage? No. The Overlay deployment form puts a gateway in front of an existing NAS, object store or Git host and manages only one directory or bucket within it. Cloud storage can also serve as the Store. ### Which agent frameworks and runtimes work with it? Any runtime that can mount a directory or use Git, S3 or MCP. The layout of an Agent Home follows open conventions (`AGENTS.md`, Agent Skills, Markdown with YAML frontmatter), so Claude Code, Cursor, Codex, OpenHands, LangGraph and homegrown frameworks are all candidates. ### Can I leave at any time? Yes. Everything can be exported as plain files and Git history. This is one of the four promises, not a feature. ### When should I not use Agent NAS? When you have one agent and data you can happily redo: a Git repository with an `AGENTS.md` is enough. More cases are in [use cases](https://agentnas.com/use-cases/). ### How do I cite it or contribute? Every page lists its canonical URL and a suggested citation. To contribute, open an issue or start a discussion on GitHub. Details are on the [about page](https://agentnas.com/about/). --- Canonical URL: https://agentnas.com/faq/ Updated: 2026-11-11 · Draft specification v0.2 · CC BY 4.0