# Agent NAS: documentación completa > Agent NAS es almacenamiento conectado en red diseñado en torno a la ejecución (run): cada ejecución de un agente trabaja en una rama aislada y accede a los datos mediante una concesión estrecha y de corta duración; cada cambio se puede rastrear y deshacer; y la memoria son archivos normales con procedencia. Habla lo que los agentes ya hablan: archivos, Git, S3 y MCP. Estado: concepto y borrador de especificación v0.2, noviembre de 2026. Todavía no hay implementación de referencia. Contenido bajo licencia CC BY 4.0. --- # Agent NAS: almacenamiento conectado en red para agentes de IA > Agent NAS es almacenamiento conectado en red diseñado en torno a la ejecución (run): cada ejecución de un agente trabaja en una rama aislada y accede a los datos mediante una concesión estrecha y de corta duración; cada cambio se puede rastrear y deshacer; y la memoria son archivos normales con procedencia. Habla lo que los agentes ya hablan: archivos, Git, S3 y MCP. **Donde los agentes trabajan y tú conservas el control.** Un NAS que toma la ejecución como unidad básica: cada ejecución recibe su propia rama y su propia concesión, cada cambio se puede rastrear y deshacer, y la memoria son notas que puedes leer, editar y llevarte contigo. ## De un vistazo - **Categoría**: Almacenamiento conectado en red para agentes de IA, también llamado almacenamiento nativo para agentes (agent-native storage). - **Idea central**: La unidad de acceso es la **ejecución** (run), no la cuenta: una ejecución trabaja en una rama, accede a los datos mediante una concesión y deja un registro. - **Cuatro promesas**: Acotado, recuperable, atribuible e inspeccionable. - **Sustantivos centrales**: Tree, Commit, Principal, Run, Lease y Record. - **Conceptos**: Nueve conceptos con nombre en tres grupos: Trabajo, Autoridad y Conocimiento. - **Interfaces**: Plano de datos: montaje, Git, S3, WebDAV. Plano de control: MCP, HTTP, CLI. - **Especificación**: Borrador v0.2 con niveles de conformidad desde L0 Files hasta L4 Sync, cada uno con pruebas de aceptación ejecutables. - **Estado**: Fase de concepto y especificación, todavía sin implementación de referencia. L0 y L1 se pueden construir hoy con piezas existentes. - **Licencia**: Contenido bajo CC BY 4.0. ## Por qué ahora En el último año han ocurrido cuatro cosas. - **Los agentes trabajan con archivos.** [AGENTS.md](https://agents.md), [Agent Skills](https://agentskills.io/specification), la memoria respaldada por Git ([Letta Context Repositories](https://www.letta.com/blog/context-repositories/)) y el [descubrimiento dinámico de contexto](https://cursor.com/blog/dynamic-context-discovery), que escribe las salidas largas en archivos, han convertido los archivos en el medio de trabajo de los agentes. - **Los errores son rápidos y caros.** En abril de 2026 un agente de programación usó un token demasiado amplio que encontró en un archivo sin relación y [borró en 9 segundos la base de datos de producción de una empresa y las copias de seguridad que estaban en el mismo volumen](https://www.theregister.com/software/2026/04/27/cursor-opus-agent-snuffs-out-startups-production-database/5224442). - **Las personas no pueden revisar cada paso.** Anthropic informa de que los usuarios aprueban [entre el 93 % y el 97 % de las solicitudes de permiso](https://claude.com/resources/articles/auto-mode-default-in-claude-code); en su experimento controlado, las personas detectaron solo el 13,6 % de los comandos peligrosos introducidos a propósito. - **La memoria se ha convertido en superficie de ataque.** [Varios estudios de 2026](https://arxiv.org/abs/2606.04329) muestran que una instrucción maliciosa escrita en la memoria persistente sobrevive entre sesiones y que defender solo en la entrada o en la recuperación sirve de poco. Los fabricantes de almacenamiento también se han movido: [QNAP QuAgent](https://www.qnap.com/en/software/quagent), [Synology DSM Agent](https://www.synology.com/en-us/beta/2026_DSM_Agent_1_0_Beta/release_note) y [TrueNAS MCP](https://truenas.github.io/truenas-research-labs/) permiten que un agente administre el equipo. Pero, por lo que podemos ver, sigue sin existir un contrato abierto, autoalojado y verificable sobre cómo trabajan con seguridad otros agentes sobre los datos que hay dentro. Consulta [cómo se compara Agent NAS con los enfoques existentes](https://agentnas.com/es/compare/). ## Cuatro promesas | Promesa | Significado | Lo cumple | | --- | --- | --- | | Acotado | Una ejecución solo puede tocar lo que nombra su concesión, y la concesión deja de funcionar a tiempo; una sesión que ha leído contenido no fiable no puede tener además datos sensibles y un canal de salida. | [Capability Lease](https://agentnas.com/es/concepts/capability-lease/), [Trust Labels](https://agentnas.com/es/concepts/trust-labels/) | | Recuperable | Las escrituras llegan primero a una rama; los datos protegidos solo cambian mediante fusiones revisadas; los borrados son lógicos; las instantáneas quedan fuera de cualquier concesión. | [Agent Branch](https://agentnas.com/es/concepts/agent-branch/), [Human Gate](https://agentnas.com/es/concepts/human-gate/) | | Atribuible | Cada cambio puede responder: quién lo hizo, en nombre de quién, con qué concesión y qué se leyó. | [Flight Recorder](https://agentnas.com/es/concepts/flight-recorder/) | | Inspeccionable | La memoria son notas normales con procedencia, los índices se pueden tirar y reconstruir, y todos los datos se pueden exportar. | [Agent Home](https://agentnas.com/es/concepts/agent-home/), [Agent Memory](https://agentnas.com/es/concepts/agent-memory/), [Budgeted Reads](https://agentnas.com/es/concepts/budgeted-reads/), [Cascade Forget](https://agentnas.com/es/concepts/cascade-forget/) | ## Nueve conceptos, tres preguntas Agent NAS propone nueve conceptos con nombre. Cada uno tiene su propia página: una definición que puedes citar, un mecanismo, una forma de empezar en pequeño, un esbozo de interfaz, lo que la especificación le exige y sus límites honestos. ### Trabajo ¿Dónde ocurre el trabajo y qué pasó? - AN-01 [Agent Home (hogar del agente)](https://agentnas.com/es/concepts/agent-home/): Un directorio por rol, con historial. Archivos normales que puedes llevarte contigo. - AN-02 [Agent Branch (rama del agente)](https://agentnas.com/es/concepts/agent-branch/): Cada ejecución trabaja en una rama copy-on-write. Solo una fusión revisada llega a la línea principal. - AN-03 [Flight Recorder (registrador de vuelo)](https://agentnas.com/es/concepts/flight-recorder/): Un registro por ejecución, encadenado por hashes, que incluye lo que la ejecución leyó. ### Autoridad ¿Quién puede hacer qué, y por orden de quién? - AN-04 [Capability Lease (concesión de capacidad)](https://agentnas.com/es/concepts/capability-lease/): Una autorización estrecha para una ejecución, con caducidad y presupuestos. Las concesiones hijas solo pueden ser más estrechas. - AN-05 [Human Gate (compuerta humana)](https://agentnas.com/es/concepts/human-gate/): Aparece solo antes de acciones irreversibles, hacia el exterior o que elevan privilegios, y muestra el diff real. - AN-06 [Trust Labels (etiquetas de confianza)](https://agentnas.com/es/concepts/trust-labels/): Dos etiquetas pequeñas más la contaminación de sesión hacen cumplir la Rule of Two. ### Conocimiento ¿Qué sabe el agente, cómo lee y cómo olvida? - AN-07 [Agent Memory (memoria del agente)](https://agentnas.com/es/concepts/agent-memory/): Las notas que puedes leer y editar son la verdad. Los índices son una caché que puedes tirar. - AN-08 [Budgeted Reads (lecturas con presupuesto)](https://agentnas.com/es/concepts/budgeted-reads/): Lee un archivo como esquema, sección, rango de líneas o completo, degradando para ajustarse al presupuesto. - AN-09 [Cascade Forget (olvido en cascada)](https://agentnas.com/es/concepts/cascade-forget/): Borra los derivados siguiendo el linaje, trata el historial por clase de retención e informa de lo que no pudo hacer. ## Cuatro capas, seis sustantivos La capa Store usa almacenamiento maduro tal cual. Todas las capas que hay encima se pueden reconstruir a partir de ella, y el núcleo son solo seis sustantivos: Tree, Commit, Principal, Run, Lease y Record. No inventamos un motor de almacenamiento; la innovación está en el contrato. - **Interface (interfaz)**: Proyecta las capacidades en interfaces que los agentes, las personas y las herramientas ya usan. Las pasarelas no tienen estado y nunca deciden quién puede hacer qué. (Montaje (POSIX), Git, S3, WebDAV/SMB, MCP, HTTP, CLI, A2A (opcional)) - **Trust (confianza)**: El único punto de autorización. Política determinista, sin ningún modelo en la decisión. (Sujetos y ejecuciones, Capability Lease, Motor de políticas, Human Gate, Trust Labels, Credential Broker, Flight Recorder) - **Memory (memoria)**: Convierte las notas en conocimiento consultable. Todo se puede reconstruir a partir de la capa inferior. (Agent Memory, Budgeted Reads, Cascade Forget, Índices, Tareas de mantenimiento, Linaje) - **Store (almacén)**: Un árbol con historial, sobre instantáneas maduras del sistema de archivos, Git o almacenamiento de objetos versionado. (Tree, Commit, Agent Branch, Instantáneas del sistema de archivos, Git, Almacenamiento de objetos) - **Sync (sincronización, opcional)**: Replicación y uso compartido entre nodos. Va al final a propósito: primero hay que dejar bien un solo nodo. (Remotos de Git, Transferencia de instantáneas, Enlaces de concesión, Paquetes de traspaso) [Leer la arquitectura](https://agentnas.com/es/architecture/). ## El recorrido de una ejecución 1. **Pedir una concesión.** El orquestador del agente de investigación Cleo pide una [Capability Lease](https://agentnas.com/es/concepts/capability-lease/) para esta ejecución: leer `/shared/launch`, proponer cambios, válida durante cuatro horas. El sobre de políticas que fijó el propietario la aprueba de forma automática. 2. **Empezar a trabajar.** El NAS crea la ejecución y su rama `cleo/run_91ab`; el sandbox monta la rama como un directorio normal. Cleo lee `AGENTS.md` y su memoria revisada desde su [Agent Home](https://agentnas.com/es/concepts/agent-home/). 3. **Leer dentro de un presupuesto.** Lee un informe largo con [Budgeted Reads](https://agentnas.com/es/concepts/budgeted-reads/): primero un esquema de 400 tokens y después, según haga falta, rangos de líneas concretos. Cada lectura se añade al manifiesto de lectura de la ejecución. 4. **Trabajar en una rama.** Los cambios llegan a una [Agent Branch](https://agentnas.com/es/concepts/agent-branch/). La rama compartida `main` no cambia en absoluto por ahora. 5. **Encontrar una compuerta.** Cleo ha leído una página web, así que las [Trust Labels](https://agentnas.com/es/concepts/trust-labels/) marcan su sesión con contaminación `external`. Cuando propone fusionar en `main`, la política exige una [Human Gate](https://agentnas.com/es/concepts/human-gate/): el propietario ve en el móvil el diff real calculado por el NAS y la fuente no fiable, y aprueba. 6. **Dejar un registro.** La fusión crea un commit con procedencia. Lo que se leyó, lo que se escribió y quién aprobó qué van al [Flight Recorder](https://agentnas.com/es/concepts/flight-recorder/), encadenado por hashes. 7. **Asentar la memoria.** Cleo anota algunos hechos nuevos. Como esta sesión leyó contenido externo, estas notas de [Agent Memory](https://agentnas.com/es/concepts/agent-memory/) pasan primero a cuarentena: se pueden recuperar, pero no se cargarán automáticamente hasta que una persona las revise. 8. **Olvidar.** Semanas después, un cliente pide que lo olviden. [Cascade Forget](https://agentnas.com/es/concepts/cascade-forget/) borra siguiendo el linaje los resúmenes e índices relacionados y emite un informe que dice lo que no pudo cubrir. ## Habla lo que los agentes ya hablan No hace falta ningún SDK nuevo para empezar. Cualquier agente que sepa leer y escribir archivos, usar Git o S3, o llamar a herramientas MCP puede usar Agent NAS. La sesión de abajo solo ilustra la línea de comandos prevista. *Sesión ilustrativa* ```bash $ nas lease create --role cleo --paths "/shared/launch/**" --actions read,write,propose --ttl 4h lease lse_7Qk3 · run run_91ab · branch cleo/run_91ab · expires 16:00 $ nas mount --lease lse_7Qk3 ~/work # plain files, on a branch $ ./draft-release-notes.sh # the agent works with ordinary tools $ nas propose --into main gate gt_2Mx4 waiting for approval: merge cleo/run_91ab into main (4 files) $ nas gate approve gt_2Mx4 # the owner, from another terminal or a phone merged · commit 91ce3a7 · record 18211 ``` [Ver todas las interfaces](https://agentnas.com/es/interfaces/). ## Nuestras apuestas Un diseño que aspira a resistir años debería decir qué apuesta y qué pasa si pierde la apuesta. - **Los agentes seguirán usando los sistemas de archivos y Git como su principal medio de trabajo.** Si no, Agent Home se degrada a un formato de exportación y los demás conceptos siguen en pie. - **“Una ejecución” seguirá siendo la unidad natural de autorización y de rendición de cuentas.** Si aparecen procesos autónomos de larga vida, las concesiones pasan a ser renovaciones continuas con presupuestos. - **La inyección de prompts no se erradicará en la capa del modelo en un futuro previsible.** Si se erradica, las Trust Labels pasan a ser una capa barata de defensa en profundidad. - **La atención humana seguirá siendo escasa.** Si la automatización total llega a ser lo bastante fiable, una Human Gate dejará paso a una política de autorización previa, y el rastro de auditoría se mantiene. Las siete apuestas están en los [principios de diseño](https://agentnas.com/es/principles/). ## Este sitio también lo pueden leer los agentes Cada página tiene un gemelo en Markdown, el sitio publica `llms.txt` y ejecuta un pequeño servidor MCP de solo lectura. Pruébalo desde una terminal: *Terminal* ```bash curl -H "Accept: text/markdown" https://agentnas.com/what-is-agent-nas/ curl https://agentnas.com/llms.txt curl -X POST https://agentnas.com/api/search \ -H "content-type: application/json" \ -d '{"query": "capability lease", "limit": 5}' ``` Para añadir el servidor de documentación a un cliente MCP: *mcp.json* ```json { "mcpServers": { "agentnas-docs": { "url": "https://agentnas.com/mcp" } } } ``` ## Las preguntas que más se hacen ### ¿Qué es Agent NAS en una frase? Almacenamiento conectado en red diseñado en torno a la ejecución: cada ejecución de un agente trabaja en una rama aislada y accede a los datos mediante una concesión estrecha y de corta duración; cada cambio se puede rastrear y deshacer; y la memoria son archivos normales con procedencia. ### ¿Hay software que pueda descargar? Todavía no. Agent NAS es por ahora un concepto y un borrador de especificación (v0.2). L0 y L1 se pueden construir hoy con Git, instantáneas del sistema de archivos y una pequeña pasarela; el objetivo para la implementación de referencia v0 es la primera mitad de 2027. Consulta la [hoja de ruta](https://agentnas.com/es/roadmap/). ### ¿En qué se diferencia de los agentes de IA que incluyen los fabricantes de NAS? Esos agentes administran el equipo. Agent NAS especifica cómo trabajan otros agentes sobre los datos que hay dentro del equipo: ramas, concesiones, memoria y olvido. Se complementan, y el equipo de un fabricante puede ser la base de un despliegue Overlay. ### ¿Sustituye a mi almacenamiento actual? No. La forma de despliegue Overlay se coloca delante de un NAS, un almacén de objetos o un host de Git ya existentes y gestiona solo un directorio o un bucket dentro de él. ### ¿Puede detener la inyección de prompts? No. Limita lo que ocurre después de una inyección y hace que las consecuencias sean visibles y reversibles. Sus límites honestos están en la página de [seguridad](https://agentnas.com/es/security/). ### ¿Puedo irme en cualquier momento? Sí. Todo se puede exportar como archivos normales e historial de Git. Es una garantía de diseño, no una función opcional. [Todas las preguntas](https://agentnas.com/es/faq/). ## En qué punto estamos > **Estado.** Agent NAS está en fase de concepto y borrador de especificación (v0.2, noviembre de 2026). La v0.2 es una revisión de realismo: trece conceptos se redujeron a nueve, y cada uno indica cómo empezar en pequeño y cuáles son sus límites honestos. Todavía no hay implementación de referencia. - [Borrador de especificación](https://agentnas.com/es/spec/): Niveles de conformidad y pruebas de aceptación ejecutables. - [Hoja de ruta](https://agentnas.com/es/roadmap/): Ahora, después, más adelante, y lo que no haremos. - [Sobre el proyecto](https://agentnas.com/es/about/): Licencia, cómo citar y cómo participar. --- URL canónica: https://agentnas.com/es/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # ¿Qué es Agent NAS? > Agent NAS es almacenamiento conectado en red diseñado en torno a la ejecución (run): cada ejecución de un agente trabaja en una rama aislada y accede a los datos mediante una concesión estrecha y de corta duración; cada cambio se puede rastrear y deshacer; y la memoria son archivos normales con procedencia. Habla lo que los agentes ya hablan: archivos, Git, S3 y MCP. ## En un párrafo Agent NAS guarda todo lo que un agente necesita para trabajar a lo largo del tiempo: instrucciones, habilidades, memoria, trabajo en curso e historial. Responde a preguntas que a un NAS tradicional no le importan: qué puede tocar esta ejecución, si un error se puede deshacer, quién aprobó qué y de dónde salió un recuerdo. No es un nuevo motor de almacenamiento. Es un **contrato** sobre almacenamiento maduro (sistemas de archivos, Git, almacenes de objetos) que especifica cómo deben funcionar la autoridad, el aislamiento, la trazabilidad y la memoria entre los agentes y los datos, y cómo verificarlo. ## Leer el nombre por partes - **Agent (agente)**: Un sistema de IA que actúa en nombre de alguien: lee, decide y usa herramientas a lo largo de muchos pasos. En Agent NAS un agente pertenece a un **rol**, y cada trabajo es una **ejecución** (run). - **Network-attached (conectado en red)**: Se accede a él por red desde muchos clientes a la vez, ya sea una LAN doméstica, un servidor de equipo o una región de la nube. No está atado a un sandbox ni a una máquina. - **Storage (almacenamiento)**: Duradero, versionado y exportable. El almacenamiento es la fuente de verdad; todo lo “inteligente” se deriva de él y se puede descartar y reconstruir. ## Qué convierte algo en un Agent NAS 1. **La unidad de acceso es la ejecución.** Cada ejecución tiene su propia [concesión](https://agentnas.com/es/concepts/capability-lease/), no una clave compartida ni una cuenta humana. 2. **Aislado y reversible por defecto.** Las escrituras llegan primero a una [rama](https://agentnas.com/es/concepts/agent-branch/); los datos protegidos solo cambian mediante fusiones; los borrados son lógicos. 3. **Cada cambio es rastreable.** Quién lo hizo, en nombre de quién, con qué concesión y qué se leyó ([Flight Recorder](https://agentnas.com/es/concepts/flight-recorder/)). 4. **La memoria son archivos con procedencia, y los índices son desechables** ([Agent Memory](https://agentnas.com/es/concepts/agent-memory/)). 5. **Se sirve a través de interfaces existentes:** montajes, Git, S3 y MCP, no un protocolo nuevo. 6. **Sin la capa de IA sigue siendo un NAS de propósito general sólido,** y todos los datos se pueden exportar por completo. ## Qué no es - **No es un nuevo motor de almacenamiento, sistema de archivos ni base de datos vectorial.** Todos se usan como piezas existentes. - **No es un sandbox.** No aísla el cómputo; restringe la relación entre los agentes y los datos, y debe usarse junto con un sandbox. - **No es una cura para la inyección de prompts.** Limita las consecuencias y no impide que la inyección ocurra. Consulta [seguridad](https://agentnas.com/es/security/). - **No es un framework de agentes.** No dice cómo razonan, planifican o llaman a los modelos los agentes. ## Para quién es, y quién no lo necesita - **Desarrolladores que ya usan `AGENTS.md` y Git:** quieren una línea principal protegida, ejecuciones reversibles y un registro trazable. - **Equipos que ejecutan varios agentes:** necesitan un árbol compartido, revisión de los cambios de los agentes y una respuesta a “¿qué leyó realmente?”. - **Particulares con un agente personal:** quieren que la memoria siga en sus manos, legible, editable y portátil. - **Organizaciones que manejan datos de clientes:** necesitan que la retención y el olvido sean decisiones explícitas al escribir, y un informe de olvido honesto. > **Quién no lo necesita.** Si tienes un solo agente y datos que puedes rehacer sin problema, **no** necesitas Agent NAS: un repositorio Git con un `AGENTS.md` basta. Se gana su lugar cuando los datos empiezan a importar, los agentes se multiplican y quieres saber “¿qué leyó y qué cambió realmente?”. Hay más casos en [casos de uso](https://agentnas.com/es/use-cases/). ## Agent NAS y los agentes de gestión de los fabricantes | Pregunta | Agentes de gestión de los fabricantes de NAS | Agent NAS | | --- | --- | --- | | ¿Qué hace el agente? | Gestiona este NAS en lenguaje natural, convirtiendo la conversación en operaciones. | Trabaja con los datos que hay dentro del equipo: leer, escribir, recordar y dejar un registro. | | ¿Cómo se concede el acceso? | Reutiliza los permisos del usuario, con una segunda confirmación para las operaciones peligrosas. | Una concesión de corta duración ligada a una ejecución: rutas, acciones, caducidad, presupuestos. | | ¿Y si algo sale mal? | Se apoya en confirmaciones y registros. | Las escrituras llegan a una rama; los borrados son lógicos; las instantáneas quedan fuera de toda concesión. | | ¿Dónde vive la memoria? | En los servidores del asistente o del fabricante. | Como notas con procedencia en el Home del agente; los índices son desechables. | | ¿Contenido no fiable? | Entra al modelo como cualquier otro texto. | Lleva una etiqueta `external`; después de leerlo, las acciones con consecuencias pasan por una compuerta. | | ¿Cómo me voy? | Depende del fabricante. | Todo se exporta como archivos normales e historial de Git. | ## Qué leer a continuación - [Los nueve conceptos](https://agentnas.com/es/concepts/): Una página para cada uno, con cómo empezar en pequeño. - [Arquitectura](https://agentnas.com/es/architecture/): Cuatro capas, seis sustantivos y el recorrido de una ejecución. - [Seguridad](https://agentnas.com/es/security/): Modelo de amenazas, controles y límites honestos. - [FAQ](https://agentnas.com/es/faq/): Respuestas breves a las preguntas habituales. --- URL canónica: https://agentnas.com/es/what-is-agent-nas/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Los nueve conceptos > Agent NAS se construye sobre nueve conceptos con nombre. Responden a tres preguntas: dónde ocurre el trabajo y qué pasó; quién puede hacer qué y por orden de quién; y qué sabe el agente, cómo lee y cómo olvida. Los nombres de los conceptos son términos acuñados y se mantienen en inglés en todos los idiomas, con una glosa en el idioma local. Cada página abre con una definición citable y después trata el problema, el mecanismo, cómo empezar en pequeño, un esbozo de interfaz, lo que pide la especificación, y lo que se toma prestado junto con los límites honestos. El nivel de conformidad indica cuándo una implementación debería admitir el concepto; consulta la [especificación](https://agentnas.com/es/spec/). > **Sobre lo “nuevo”.** La mayoría de los nueve conceptos combinan piezas maduras. Cada página de concepto dice qué toma prestado y qué es genuinamente nuevo. La lista resumen está en la página de [comparación](https://agentnas.com/es/compare/). ## Tres grupos ### Trabajo ¿Dónde ocurre el trabajo y qué pasó? - AN-01 [Agent Home (hogar del agente)](https://agentnas.com/es/concepts/agent-home/): Un directorio por rol, con historial. Archivos normales que puedes llevarte contigo. - AN-02 [Agent Branch (rama del agente)](https://agentnas.com/es/concepts/agent-branch/): Cada ejecución trabaja en una rama copy-on-write. Solo una fusión revisada llega a la línea principal. - AN-03 [Flight Recorder (registrador de vuelo)](https://agentnas.com/es/concepts/flight-recorder/): Un registro por ejecución, encadenado por hashes, que incluye lo que la ejecución leyó. ### Autoridad ¿Quién puede hacer qué, y por orden de quién? - AN-04 [Capability Lease (concesión de capacidad)](https://agentnas.com/es/concepts/capability-lease/): Una autorización estrecha para una ejecución, con caducidad y presupuestos. Las concesiones hijas solo pueden ser más estrechas. - AN-05 [Human Gate (compuerta humana)](https://agentnas.com/es/concepts/human-gate/): Aparece solo antes de acciones irreversibles, hacia el exterior o que elevan privilegios, y muestra el diff real. - AN-06 [Trust Labels (etiquetas de confianza)](https://agentnas.com/es/concepts/trust-labels/): Dos etiquetas pequeñas más la contaminación de sesión hacen cumplir la Rule of Two. ### Conocimiento ¿Qué sabe el agente, cómo lee y cómo olvida? - AN-07 [Agent Memory (memoria del agente)](https://agentnas.com/es/concepts/agent-memory/): Las notas que puedes leer y editar son la verdad. Los índices son una caché que puedes tirar. - AN-08 [Budgeted Reads (lecturas con presupuesto)](https://agentnas.com/es/concepts/budgeted-reads/): Lee un archivo como esquema, sección, rango de líneas o completo, degradando para ajustarse al presupuesto. - AN-09 [Cascade Forget (olvido en cascada)](https://agentnas.com/es/concepts/cascade-forget/): Borra los derivados siguiendo el linaje, trata el historial por clase de retención e informa de lo que no pudo hacer. --- URL canónica: https://agentnas.com/es/concepts/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Arquitectura > Agent NAS tiene cuatro capas y una capa de sincronización opcional: Interface proyecta las capacidades en interfaces existentes, Trust es el único punto de autorización, Memory convierte las notas en conocimiento consultable y Store guarda un árbol con historial. La capa Memory se puede borrar y reconstruir entera, y Store simplemente usa almacenamiento maduro. ## Cuatro capas y sincronización opcional - **Interface (interfaz)**: Proyecta las capacidades en interfaces que los agentes, las personas y las herramientas ya usan. Las pasarelas no tienen estado y nunca deciden quién puede hacer qué. (Montaje (FUSE, NFS, SMB), Git, Compatible con S3, WebDAV, MCP, API HTTP, CLI, A2A (opcional)) - **Trust (confianza)**: El único punto de autorización. Un motor de políticas determinista sin ningún modelo en la decisión; primero se registra y después se actúa. (Sujetos y ejecuciones, Capability Lease, Motor de políticas, Human Gate, Trust Labels, Credential Broker, Flight Recorder) - **Memory (memoria)**: Convierte las notas en conocimiento consultable y legible con presupuesto. Todo se puede reconstruir a partir de la capa inferior. (Convenciones de notas, Índices (texto completo, vectorial, grafo), Budgeted Reads, Tareas de mantenimiento, Linaje, Cascade Forget) - **Store (almacén)**: Un árbol con historial, sobre instantáneas maduras del sistema de archivos, Git o almacenamiento de objetos versionado. No entiende la memoria ni las etiquetas. (Tree, Commit, Agent Branch, Instantáneas del sistema de archivos, Git, Almacenamiento de objetos) - **Sync (sincronización, opcional)**: Replicación y uso compartido entre nodos. Va al final a propósito: primero hay que dejar bien un solo nodo. (Remotos de Git, Transferencia de instantáneas, Enlaces de concesión, Paquetes de traspaso) - **La capa Memory es reconstruible.** Borra todos los índices y reconstruye, y las notas de Store siguen siendo totalmente legibles. - **Las pasarelas no tienen estado.** Todo el estado persistente está en Store y en los registros de Trust; una pasarela puede reiniciarse libremente y escalar en horizontal. - **Trust es el único punto de autorización.** Eso incluye las tareas en segundo plano del propio NAS (indexación, mantenimiento): también se ejecutan como principals `svc:*` con concesiones. - **Store no entiende la memoria ni la semántica de las etiquetas.** Solo guarda un árbol con metadatos. - **Primero se registra, después se actúa.** Una operación con consecuencias debe escribir antes un registro de intención. ## La cintura estrecha: seis sustantivos Todo el diseño depende de seis sustantivos; las etiquetas, las compuertas, la memoria y los manifiestos de lectura son convenciones construidas encima. | Sustantivo | Significado | Invariante clave | | --- | --- | --- | | Tree | Un árbol de directorios con historial. | Cualquier commit se puede reproducir; hay un hash de contenido o una detección de cambios equivalente. | | Commit | Un cambio inmutable. | Lleva metadatos de procedencia: `principal`, `on_behalf_of`, `run`, `lease`. | | Principal | Una entidad que puede autenticarse y rendir cuentas. | El tipo es `human`, `agent`, `service` o `node`; un `agent` pertenece a un rol, no a una ejecución. | | Run | Una ejecución con principio, fin, propósito y un responsable. | Tiene una concesión raíz; es dueña de una rama. | | Lease | La autorización de una ejecución. | Tiene caducidad; solo se puede acotar más; es revocable; lleva presupuestos. | | Record | Un registro de solo anexado. | Encadenado por hashes; primero se registra, después se actúa. | ## La capa Store: contrato y motores opcionales El contrato de Store lo proporciona un motor o lo emula la pasarela. Una implementación puede combinar motores, por ejemplo Git para el texto e instantáneas para los archivos grandes; el contrato no prescribe el motor, la función hash ni el formato en disco. 1. Commits atómicos. 2. Bifurcaciones baratas: idealmente cercanas a O(1); en el peor caso degradándose a una copia, y entonces las cuotas y un TTL son obligatorios. 3. Instantáneas inmutables. 4. Detección de cambios: un hash de contenido o un equivalente. 5. La diferencia entre dos commits. 6. Exportación completa en un formato estándar: un directorio, el historial de Git y los metadatos `.nas/` en texto plano. | Motor | Adecuado para | Coste de bifurcar | Nota | | --- | --- | --- | --- | | Git (con worktrees) | Texto, memoria, habilidades, bases de código pequeñas | Bajo | Los archivos grandes necesitan LFS o almacenamiento externo; las fusiones binarias son malas. | | Instantáneas y clones del sistema de archivos (ZFS, btrfs, APFS) | Directorios grandes, archivos mixtos | Cercano a O(1) | Depende del sistema de archivos; copiar entre máquinas necesita send/receive. | | Almacenamiento de objetos versionado (forks de Tigris, lakeFS, S3 más un manifiesto) | Conjuntos de datos, archivos grandes | Cercano a O(1) | Necesita que la pasarela ofrezca una vista de archivos. | | Directorio normal más copia | Empezar con Lite | O(n) | Solo para datos pequeños; las cuotas y un TTL son obligatorios. | > **La vía de recuperación queda fuera del radio de impacto.** Las instantáneas y las copias de seguridad están en manos del principal propietario, y ninguna concesión puede incluir “borrar una instantánea” ni “borrar una copia de seguridad”. Es la lección más directa del incidente de abril de 2026: la vía de recuperación debe quedar fuera del radio de impacto de lo que protege. - El cifrado en reposo viene de la capa inferior; la clase de retención `sensitive` usa su propio dominio de claves, de modo que se puede destruir eliminando la clave. - La deduplicación y la destrucción entran en conflicto: la clase `sensitive` no se deduplica entre dominios de claves. ## El recorrido de una ejecución 1. **Solicitar.** El orquestador (o el propietario) solicita una concesión para una ejecución: rutas, acciones, caducidad, propósito. Dentro del **sobre de políticas** se emite de forma automática; fuera de él pasa a una Human Gate. 2. **Empezar.** El NAS crea el `run` y la rama `/` y entrega la concesión a la ejecución; el sandbox monta la rama (o hace un `git clone`). 3. **Trabajar.** El agente lee y escribe con herramientas de archivos normales. Las lecturas se acumulan en el **manifiesto de lectura** y la contaminación de la sesión se actualiza con ellas; el acceso fuera de los límites se rechaza y se registra. 4. **Hacer commit.** Los cambios se confirman con un commit de forma automática (con retardo) o explícita, y cada commit lleva metadatos de procedencia. 5. **Proponer.** `propose` crea un **Agent PR**: el diff, la intención, un resumen del manifiesto de lectura, los resultados de las comprobaciones y un resumen de etiquetas. 6. **Decidir.** El motor de políticas decide: si las comprobaciones pasan y el riesgo es bajo, se fusiona de forma automática; si hay datos protegidos, una acción hacia el exterior o una violación de la Rule of Two, pasa a una Human Gate; si está claramente prohibido, se rechaza. 7. **Fusionar y registrar.** La fusión crea un commit con procedencia y escribe un Record. 8. **Cerrar.** La concesión caduca; la rama se recicla tras su TTL; los manifiestos de lectura y los Records se conservan según la política de retención. **La ruta de lectura:** solicitud, comprobación de la concesión, comprobación de etiquetas (¿permite la contaminación actual de la sesión esta lectura?), recuento del presupuesto, lectura desde Store, anotación en el manifiesto de lectura, y devolución del contenido y de los punteros de evidencia. > **Primero se registra, después se actúa.** Una operación con consecuencias (fusionar, borrar, compartir, enviar al exterior, cambiar una concesión) debe escribir antes un registro de intención; si no se puede escribir, la operación falla (fail closed). Las lecturas van al manifiesto de lectura, que se vuelca por lotes y no necesita ser síncrono en cada lectura. ## Formas de despliegue | Forma | Descripción | Adecuado para | | --- | --- | --- | | Lite | Una sola máquina y un solo usuario: un proceso de pasarela más almacenamiento local (Git o instantáneas del sistema de archivos); L0 a L1. | Particulares y desarrolladores que lo prueban. | | Overlay | Deja en paz el NAS o el almacén de objetos existente: una pasarela se coloca delante y gestiona solo un directorio o un bucket; los montajes y la vista S3 pasan por la pasarela. | **El punto de partida más realista:** quien ya tiene un equipo. | | Team | Varios usuarios y agentes, un servidor o un clúster pequeño; L0 a L3; notificaciones de compuertas y una sala de control. | Equipos pequeños. | | Cloud | Un servicio alojado multiinquilino con aislamiento fuerte; L0 a L3. | Quien no tiene hardware propio. | El principio: no se necesita hardware especial y vale cualquier máquina siempre encendida; los aceleradores son opcionales, porque bastan modelos pequeños para los embeddings y los resúmenes, y también se pueden llamar servicios externos. ## Construir una v0 con piezas existentes | Capacidad | Piezas que puedes usar hoy | | --- | --- | | Store y ramas | Git y worktrees; instantáneas de btrfs o ZFS; o Tigris y lakeFS (almacenamiento de objetos). | | Línea principal protegida | Protección de ramas en Forgejo, Gitea o GitHub; o ramas protegidas de lakeFS. | | Concesiones | Un servidor de autorización OAuth (por ejemplo Keycloak) con intercambio de tokens, y un servidor de recursos que compruebe el prefijo de la ruta y la acción; o un servicio de firma de unos cientos de líneas. | | Registros | Una tabla SQLite de solo anexado más un hash diario; trailers de Git en los commits; exportación con OpenTelemetry. | | Compuertas | Revisión de PR más una notificación push; la CLI `nas gate approve`. | | Memoria | Markdown bajo `memory/` más SQLite FTS5; un almacén vectorial se añade después. | | Etiquetas | Marca el directorio de importación como `external`; guarda la contaminación de sesión de cada ejecución en la pasarela. | | Interfaces | Un montaje NFS, SMB o FUSE; Git sobre SSH o HTTPS; una pasarela S3; un pequeño servidor MCP. | Lo que dice esta tabla: **L0 y L1 no necesitan ninguna invención nueva.** Lo nuevo es el contrato que los combina y las pruebas que lo verifican; consulta la [especificación](https://agentnas.com/es/spec/). ## Operación - **Copias de seguridad:** 3-2-1; las instantáneas y las copias de seguridad pertenecen al principal propietario y ninguna concesión puede tocarlas; haz un simulacro de restauración cada trimestre y guarda un registro. - **Actualizaciones:** las pasarelas no tienen estado y se pueden actualizar de forma gradual; cualquier cambio de formato de Store debe llevar un plan de migración y de reversión; la capa Memory se puede reconstruir entera. - **Supervisión:** tasas de emisión y denegación de concesiones; longitud de la cola de compuertas y tasa de aprobación (una tasa de aprobación que se mantiene por encima del 95 % indica que las compuertas son demasiado frecuentes y conviene fusionarlas o endurecer la política); número y antigüedad de las ramas; frescura de los índices; verificación de la cadena de registros; cuotas. - **Capacidad:** las ramas tienen un TTL y cuotas; la papelera tiene un período de retención; los datos derivados tienen un presupuesto. ## La sala de control La interfaz para las personas puede ser una página web, una CLI o un chatbot. No es esencial: L0 a L1 pueden funcionar por completo con una CLI y una plataforma Git existente. - **Línea de actividad:** agregada por ejecución: quién hizo qué y qué leyó. - **Bandeja de compuertas:** acciones pendientes de aprobación, mostradas como Gate Cards. - **Directorio de roles:** el Home de cada rol, sus concesiones, presupuestos y ejecuciones recientes. - **Explorador de memoria:** notas y fuentes, la cuarentena de notas sin revisar, propuestas de mantenimiento. - **Ramas y PR:** ramas sin fusionar y la papelera. - **Consola de olvido:** solicitudes, vista previa del linaje e informes. Las personas también pueden mirar directamente por SMB o WebDAV: `/humans//Agent Activity/` es una vista de actividad de solo lectura hecha de archivos normales. --- URL canónica: https://agentnas.com/es/architecture/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Interfaces > Agent NAS usa archivos para el plano de datos y herramientas para el plano de control: los bytes viajan por montajes, Git y S3; la autorización, la aprobación, la memoria, la búsqueda y las explicaciones pasan por MCP, HTTP y una CLI. Cada interfaz es una proyección de los mismos datos, y las diferencias de semántica se expresan como errores explícitos en lugar de disimularlas. ## Principios 1. **Archivos para el plano de datos, herramientas para el plano de control.** Los bytes viajan por montajes, Git y S3; la autorización, la aprobación, la memoria, la búsqueda y las explicaciones pasan por MCP, HTTP y una CLI. 2. **Las pasarelas no tienen estado.** La autorización ocurre en un único punto de la capa Trust. 3. **Cada interfaz es una proyección.** Las diferencias de semántica se expresan con asignaciones de error explícitas (por ejemplo, “compuerta pendiente” se asigna a un `EACCES` con un archivo explicativo), y no se finge que S3 tenga ramas. 4. **Una superficie de herramientas estrecha.** No más de 10 herramientas MCP miran a los agentes; las acciones para personas y operadores viven en una interfaz de operador aparte. 5. **Los adaptadores aíslan el cambio de protocolo.** Los cambios de versión de MCP y A2A solo afectan a los adaptadores. ## Matriz de interfaces | Interfaz | Plano | Dirigida a | Asignación | Nivel | | --- | --- | --- | --- | --- | | Montaje (FUSE, NFS, SMB) | Datos | Agentes, personas, cualquier programa | Una vista de rama; asignación de errores más abajo | L0 | | Git (SSH, HTTPS) | Datos | Agentes, personas, CI | Una rama de ejecución es una rama de Git; un Agent PR es una solicitud de fusión | L0 | | Compatible con S3 | Datos | Canalizaciones de datos, trabajos por lotes | Un bucket se asigna a una vista de rama de un árbol; un ID de versión es un commit | L0 (opcional) | | WebDAV | Datos | Personas (Finder, Explorador) | Una vista de actividad de solo lectura | L0 (opcional) | | CLI `nas` | Control | Personas, scripts | Uno a uno con la API HTTP | L0 | | API HTTP | Control | Orquestadores, la sala de control | Todo `POST` con JSON; campos en `snake_case` | L1 | | MCP | Control | Agentes | Nueve herramientas (más abajo) | L1, L2 | | A2A | Control | Otros agentes | Una tarea se asigna a `inbox/` y `outbox/` | L4 (opcional) | ## La superficie de herramientas MCP Solo nueve herramientas miran a los agentes: | Herramienta | Qué hace | Acción de concesión necesaria | Nota | | --- | --- | --- | --- | | `nas_list` | Lista un directorio, con etiquetas y estado de revisión | `list` | Las rutas fuera de la concesión son invisibles. | | `nas_read` | Lectura con presupuesto: vista, rango, presupuesto | `read` | [Budgeted Reads](https://agentnas.com/es/concepts/budgeted-reads/) | | `nas_search` | Busca (texto completo, opcionalmente vectorial) y devuelve fragmentos y punteros | `read` | La cuarentena se excluye por defecto. | | `nas_write` | Escribe un archivo dentro de la rama, con un `intent` opcional | `write` | La mayoría de los runtimes usan el montaje directamente y no lo necesitan. | | `nas_branch` | Crea, marca puntos de control, restaura y lista ramas | `write` | [Agent Branch](https://agentnas.com/es/concepts/agent-branch/) | | `nas_propose` | Crea un Agent PR | `propose` | Puede activar una compuerta. | | `nas_lease` | Solicita una concesión hija más estrecha; consulta la concesión y los presupuestos actuales; solicita más autoridad (mediante una compuerta) | Ninguna | [Capability Lease](https://agentnas.com/es/concepts/capability-lease/) | | `nas_remember` | Escribe una nota, con fuentes y tipo | `write` | [Agent Memory](https://agentnas.com/es/concepts/agent-memory/) | | `nas_recall` | Recupera notas: con presupuesto, con fuentes y estado de revisión | `read` | [Agent Memory](https://agentnas.com/es/concepts/agent-memory/) | > **Acciones solo para personas y operadores.** `explain`, `gate approve/deny`, `forget`, `trash restore`, `label admin`, `lease revoke` y `policy edit` **no se exponen** a los agentes. Estas acciones cambian las propias garantías y no debería poder invocarlas la parte a la que se restringe. Un agente puede **solicitar** algunas (más autoridad, olvido), pero no ejecutarlas. ## Semántica del montaje - Un montaje enlaza **una rama y una concesión**; cuando la concesión caduca, el montaje pasa a solo lectura y después se desmonta. - Commits automáticos (con retardo, por ejemplo tras 5 segundos de calma); `fsync` activa un commit. - Las rutas fuera de la concesión **no aparecen en los listados de directorio:** esto reduce la fuga de información y la superficie de ataque de la inyección de prompts. - Apto para sandboxes: no hace falta root; FUSE o NFS, uno de los dos, sin módulo del kernel; son posibles los montajes de solo lectura. | Situación | Error POSIX | Nota | | --- | --- | --- | | Una ruta fuera de la concesión | `ENOENT` (`EACCES` cuando es visible pero está denegada) | El rechazo se registra. | | Cuota o presupuesto agotados | `EDQUOT` | Permite que la ejecución se autolimite. | | Compuerta pendiente | `EACCES`, con una explicación en `/.nas/pending` | Evita que el agente reintente para siempre. | | Concesión caducada | `ESTALE`, y después solo lectura | La rama se conserva hasta que caduca su propio TTL. | ## Git - Las ramas de ejecución se llaman `/`; `main` está protegida y un hook `pre-receive` en el servidor rechaza los push directos. - `nas propose` crea un Agent PR. - Los commits llevan automáticamente trailers como `Run:`, `Lease:` y `Principal:`. ## S3 - Un bucket corresponde a una vista de rama de un árbol; el ID de versión de un objeto es un commit. - La semántica que S3 no tiene, como las ramas, se expresa con un prefijo de bucket o una cabecera de solicitud (`x-nas-branch`). Es una **proyección degradada:** las canalizaciones de datos pueden leer y escribir, pero no obtienen la experiencia completa de ramas. - Las concesiones se pasan como credenciales temporales al estilo STS. ## A2A (opcional) - Las tareas entrantes llegan como archivos de tarea en `inbox/`; los entregables van a `outbox/`. - La Agent Card declara las habilidades del rol y las concesiones que necesita. - **El NAS no es un participante de A2A;** lo es el runtime que actúa por el rol. El NAS solo almacena tareas y entregables, paquetes de traspaso y concesiones. ## Convenciones de la API HTTP - **Todos los endpoints usan `POST`, con los parámetros en un cuerpo JSON;** los campos de respuesta son siempre `snake_case`. - Las rutas llevan versión: `/v1/...`. - Idempotencia: las operaciones de escritura aceptan una `idempotency_key`. - Paginación: `cursor` más `limit`. - Los presupuestos y los límites de frecuencia se devuelven en las cabeceras de la respuesta (bytes restantes, solicitudes restantes) para que los runtimes puedan autolimitarse. Una solicitud y una respuesta de lectura con presupuesto se ven más o menos así: *Lectura con presupuesto* ```http POST /v1/files/read { "path": "/agents/cleo/memory/notes/customer-acme.md", "view": "outline", "budget_tokens": 400 } 200 OK { "view": "outline", "tokens": 212, "generated": false, "truncated": false, "content": "# Acme\n## Renewal (L12-L18)\n## Contacts (L19-L31)\n## Open issues (L32-L40)", "evidence": [ { "pointer": "nas://home-box/agents/cleo/memory/notes/customer-acme.md@9f2c1de#L1-L40" } ] } ``` Los errores usan una estructura uniforme: *Respuesta de error* ```json { "error": { "code": "gate_required", "message": "This merge requires human approval.", "retryable": false, "request_id": "req_01JB7W2X4N", "details": { "gate_id": "gt_2Mx4" } } } ``` ## Descubrimiento - Los puntos de entrada legibles por máquinas son los mismos que en este sitio: `/.well-known/ai-catalog.json`, la Server Card de MCP y `llms.txt`. - Un endpoint que resuelve y verifica los punteros de evidencia `nas://`. - MCP `server/discover`. --- URL canónica: https://agentnas.com/es/interfaces/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Seguridad > Agent NAS no detiene la inyección de prompts; limita lo que ocurre después. Una concesión estrecha acota lo que una ejecución puede tocar, las ramas hacen reversibles los errores, la Rule of Two impide que una sesión que leyó contenido no fiable tenga además datos sensibles y un canal de salida, y queda un registro trazable. ## Alcance y supuestos de confianza - **Qué protegemos:** los datos y el historial del NAS; la frontera de la autoridad; la integridad del registro; la trazabilidad de la memoria. - **Qué no protegemos:** lo que hace un agente fuera del NAS; el aislamiento del propio cómputo (es tarea del sandbox); cualquier cosa que ocurra en el lado del proveedor del modelo. - **Supuestos de confianza:** la base de cómputo confiable (TCB) es la pasarela del NAS, el motor de políticas y el servicio de registros; el host no está comprometido; el sandbox aísla el cómputo. Si la TCB se ve comprometida, las garantías de esta página dejan de valer. ## La Rule of Two: un invariante de sesión Tres propiedades: **[A]** la sesión ha leído contenido no fiable, **[B]** la concesión permite leer datos sensibles, **[C]** la concesión permite cambiar un estado protegido o comunicarse hacia el exterior. Cuando las tres se cumplen en una misma sesión, la llamada que activa C no se deja pasar de forma automática. | Escenario | A | B | C | Resultado | | --- | --- | --- | --- | --- | | Resumir una página web en una nota de la rama | Sí | Sí | No (solo la rama) | Automático: una escritura dentro de la rama no cuenta como C. | | Tras leer una página web, proponer una fusión en `main` | Sí | Sí | Sí | Human Gate. | | Leer solo datos públicos y escribir en una zona temporal | Sí | No | No | Automático. | | Tras leer un correo externo, enviar un correo (salida) | Sí | Sí | Sí | Compuerta; se rechaza si interviene `secret`. | Es la [Agents Rule of Two](https://ai.meta.com/blog/practical-ai-agent-security/) de Meta aplicada en la **frontera del almacenamiento**. La propia Meta subraya que es una heurística para reducir el riesgo, no un punto final, y que no sustituye al mínimo privilegio; nosotros la usamos igual. El mecanismo está en [Trust Labels](https://agentnas.com/es/concepts/trust-labels/). ## Modelo de amenazas | Amenaza | Qué puede imponer el NAS | Qué no puede hacer el NAS | Riesgo residual | | --- | --- | --- | --- | | T1 Inyección indirecta de prompts (por archivos, páginas web, correo) | La Rule of Two; el acotamiento de las concesiones; las ramas; las compuertas. | Impedir que ocurra una inyección, o detener un comportamiento malicioso dentro de la concesión después de una. | Uso indebido dentro de la concesión. | | T2 Fuga de credenciales (un agente lee una clave de larga duración) | Las credenciales de larga duración nunca están en manos de una ejecución; un escáner de secretos marca `secret`; TTL cortos. | Impedir que un agente envíe datos, dentro de su concesión, a una salida autorizada. | Datos que salen dentro de la concesión. | | T3 Permisos demasiado amplios y errores | Concesiones estrechas; ramas; borrado lógico; instantáneas fuera de toda concesión. | Deshacer efectos secundarios fuera del NAS. | Consecuencias más allá del NAS. | | T4 Envenenamiento de la memoria (incluida su propagación entre roles) | Procedencia y contaminación; cuarentena; carga automática solo si está revisada; reversión. | Reconocer hechos que son falsos pero parecen plausibles. | Veneno que deja pasar un revisor. | | T5 Concesiones robadas o reutilizadas (replay) | TTL corto; revocable; vinculación opcional al titular (DPoP, mTLS). | Impedir el abuso dentro del TTL. | La ventana del TTL. | | T6 Fatiga de aprobación y aprobar por inercia | Compuertas poco frecuentes; el NAS genera el diff; aprobaciones ligadas a un digest; tasa de aprobación supervisada. | Conseguir que las personas miren con atención. | Error humano. | | T7 Manipulación de registros | Cadena de hashes; anclaje externo opcional. | Sin anclaje, impedir que root destruya el registro. | Un administrador malicioso. | | T8 Exfiltración de datos (salida, uso compartido, resultados de búsqueda) | La salida necesita una acción de concesión y una compuerta; `secret` no puede salir; los derivados heredan las etiquetas. | Evitar fugas después de que una persona apruebe; canales encubiertos. | Fugas después de la aprobación. | | T9 Cadena de suministro (habilidades, servidores MCP, plugins, modelos) | El contenido de las habilidades y de los servidores MCP externos se trata como `external`; un directorio de habilidades se puede fijar a un commit; el manifiesto del runtime se escribe en el registro. | Garantizar que el código de terceros sea inofensivo. | Una versión maliciosa fijada. | | T10 Agotamiento de recursos (bombas de ramas, presupuestos agotados, bucles de lectura) | Cuotas; TTL; presupuestos; cortacircuitos. | Distinguir una tarea grande legítima de una descontrolada. | Denegación de servicio local. | ## Controles - **Motor de políticas:** determinista (al estilo de Cedar o Rego), denegación por defecto, y al denegar da un motivo legible y la regla que coincidió; **no llama a ningún LLM**. - **Credential broker:** las claves de larga duración se quedan con el broker; este emite tokens descendentes de corta duración para una ejecución solo dentro de una acción de salida aprobada. - **Aislamiento y claves:** un Home y un espacio de rutas por rol; la clase de retención `sensitive` usa un dominio de claves separado. - **Cadena de suministro:** el contenido de las habilidades, los servidores MCP y los plugins se trata como `external`; al empezar una ejecución, las habilidades y versiones usadas se escriben en el registro. ## Límites honestos 1. Esto **no** es una defensa contra la inyección de prompts. Limita las consecuencias y las hace visibles. 2. Los permisos legítimos dentro de una concesión aún se pueden usar mal. 3. No puede hacer nada con los efectos secundarios fuera del NAS: un correo ya enviado, una API ya llamada. 4. Los canales encubiertos y los canales laterales quedan fuera del alcance. 5. Si la TCB se ve comprometida, las garantías fallan. 6. Las personas se equivocan: las compuertas reducen ese riesgo pero no pueden eliminarlo. 7. La contaminación es conservadora y trae fricción y falsos positivos; necesita ajuste y motivos de denegación visibles. 8. La destrucción criptográfica solo protege las copias que controlamos. ## Respuesta a incidentes - **Cortacircuitos:** `revoke_run` y `revoke_role` revocan las concesiones de inmediato y congelan la rama. - **Reversión:** restaura el árbol afectado a un commit anterior. - **Rastreo:** usa el manifiesto de lectura y la cadena de registros para averiguar qué leyó una ejecución, qué escribió y qué notas tocó. - **Limpieza:** usa [Cascade Forget](https://agentnas.com/es/concepts/cascade-forget/) para borrar los derivados afectados y emite un informe. ## Observabilidad y auditoría - **Tres tipos de datos:** el registro (eventos), el manifiesto de lectura (el conjunto de entradas), y las métricas y trazas. - **`explain(commit)`:** devuelve qué ejecución y qué concesión produjeron un commit, qué compuertas atravesó, qué se leyó y de qué entradas depende. - **Integración con la observabilidad existente:** una ejecución se asigna a un span de OpenTelemetry GenAI, con las concesiones y las compuertas adjuntas como eventos; los registros se pueden exportar como JSON Lines o enviar a un SIEM. - **Métricas:** tasas de emisión y denegación de concesiones; longitud de la cola de compuertas, tasa y latencia de aprobación; número y antigüedad de las ramas; frescura de los índices; consumo de presupuesto; resultados de la verificación de la cadena de registros. - **Privacidad y retención:** por defecto solo se registran metadatos, nunca contenido; la retención de los registros y el borrado del contenido son independientes; leer el propio registro requiere una concesión. --- URL canónica: https://agentnas.com/es/security/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Casos de uso > Cada escenario parte de algo que la gente ya hace, y muestra qué paso cambia Agent NAS, qué nivel de conformidad necesita y con qué se puede construir hoy. ## Un agente que trabaja de noche Antes de dormir le das una tarea a un agente: ordenar las notas de la versión. Trabaja en su propia rama; por la mañana ves en el móvil una Gate Card: 4 archivos, el diff real y las fuentes que leyó. Si apruebas, se fusiona; si rechazas, la rama se descarta y la línea principal queda intacta. - **Conceptos usados:** [Agent Branch](https://agentnas.com/es/concepts/agent-branch/), [Capability Lease](https://agentnas.com/es/concepts/capability-lease/), [Human Gate](https://agentnas.com/es/concepts/human-gate/). - **Conformidad:** L0 a L1. - **Construible hoy:** un worktree de Git, un `main` protegido y una notificación push. ## Cambia de framework y conserva tu memoria Pasas un agente de un runtime a otro. Su Home es un directorio que sigue convenciones abiertas: `AGENTS.md`, `skills/`, `memory/notes/`. El nuevo runtime lee el mismo directorio; lo que se asigna con pérdida se marca como sin revisar al importar. - **Conceptos usados:** [Agent Home](https://agentnas.com/es/concepts/agent-home/), [Agent Memory](https://agentnas.com/es/concepts/agent-memory/). - **Conformidad:** L0 a L2. - **Construible hoy:** un directorio de Git con un `AGENTS.md`. ## Un equipo, varios agentes, un solo cuerpo de conocimiento compartido Tres agentes escriben en la misma base de conocimiento. Cada uno trabaja en su propia rama y las fusiones se revisan; las notas escritas por una ejecución que leyó una página web externa pasan a cuarentena y los demás agentes no las cargan automáticamente. Lo que se comparte son las notas, no los índices. - **Conceptos usados:** [Trust Labels](https://agentnas.com/es/concepts/trust-labels/), [Agent Memory](https://agentnas.com/es/concepts/agent-memory/), [Agent Branch](https://agentnas.com/es/concepts/agent-branch/). - **Conformidad:** L0 a L3. - **Construible hoy:** una línea principal protegida, una marca `external` en el directorio de importación y una regla que carga automáticamente solo las notas revisadas. ## Revisión de un incidente Tras una fusión encuentras una página que parece incorrecta. `explain(commit)` te dice qué ejecución, qué concesión y qué compuerta lo decidieron; el manifiesto de lectura muestra que esa ejecución leyó una página web externa. Sigues la procedencia hasta las notas afectadas, haces la reversión y las pones en cuarentena. - **Conceptos usados:** [Flight Recorder](https://agentnas.com/es/concepts/flight-recorder/), [Agent Branch](https://agentnas.com/es/concepts/agent-branch/). - **Conformidad:** L1. - **Construible hoy:** trailers de Git en los commits más una tabla SQLite de solo anexado. ## Un cliente pide que lo olviden Los datos del cliente se marcaron con la clase de retención `sensitive` al escribirlos. Cuando llega la solicitud, Cascade Forget sigue el linaje hasta los resúmenes, los embeddings y las notas que los citan, destruye ese dominio de claves y emite un informe: qué se hizo y qué no se pudo hacer (copias fuera del NAS, los registros del proveedor del modelo, los pesos del modelo). - **Conceptos usados:** [Cascade Forget](https://agentnas.com/es/concepts/cascade-forget/), [Agent Memory](https://agentnas.com/es/concepts/agent-memory/). - **Conformidad:** L3. - **Construible hoy:** clases de retención, borrado lógico y registro de las entradas de cada derivado. ## Añade una puerta a un equipo que ya tienes Ya tienes un NAS. La forma Overlay coloca una pasarela delante y gestiona solo un directorio. Los agentes entran y salen por un montaje o por la vista S3; las copias de seguridad y las instantáneas del propietario quedan fuera de su alcance. - **Conceptos usados:** [Capability Lease](https://agentnas.com/es/concepts/capability-lease/), [Agent Branch](https://agentnas.com/es/concepts/agent-branch/). - **Conformidad:** L0 a L1. - **Construible hoy:** NFS o SMB más una pequeña pasarela que comprueba los tokens contra un prefijo de ruta y una acción. ## Cuándo no usar Agent NAS | Tu situación | Un enfoque más simple | | --- | --- | | Un agente y datos que puedes rehacer sin problema | Un repositorio Git con un `AGENTS.md`. | | Solo quieres que un agente te ayude a gestionar tu NAS | El agente de gestión del propio fabricante. | | Solo necesitas conjuntos de datos bifurcables | lakeFS o Tigris. | | Solo necesitas recuperar memoria | Cualquier biblioteca de memoria. | | Necesitas cómputo aislado | Un sandbox. | --- URL canónica: https://agentnas.com/es/use-cases/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Comparación > Agent NAS no pretende sustituir estos enfoques. La mayoría de los trabajos vecinos hacen bien lo suyo y pueden pasar a ser una parte de él. Intentamos ser honestos sobre qué se toma prestado y qué es genuinamente nuevo. ## El panorama | Categoría | Ejemplos | Qué hace ya | Dónde se detiene | | --- | --- | --- | --- | | Agentes de gestión de los fabricantes de NAS | QNAP QuAgent, Synology DSM Agent, TrueNAS MCP | Gestionan el equipo en lenguaje natural; reutilizan los permisos del usuario; confirman dos veces las operaciones peligrosas; registros. | Orientados a “gestionar”, no a “trabajar dentro de los datos”; sin concesiones por ejecución, ramas ni contrato de memoria. | | Sistemas de archivos para agentes y Git | Turso AgentFS, Letta Context Repositories, Cloudflare Artifacts, Redis Agent Filesystem | Meten archivos, estado y auditoría de llamadas a herramientas en un almacenamiento portátil; memoria versionada con Git; Git para agentes. | Cada uno está atado a un runtime o a una plataforma; la autorización, la aprobación, la contaminación y el olvido quedan en su mayoría fuera. | | Almacenamiento de objetos bifurcable y control de versiones de datos | Tigris Agent Kit, lakeFS | Bifurcaciones copy-on-write, puntos de control, ramas protegidas, credenciales acotadas, hooks previos a la fusión. | Orientados a data lakes y almacenamiento de objetos en la nube; sin semántica de memoria ni de concesiones, y sin experiencia de aprobación humana. | | Frameworks de memoria | Letta, Mem0, Zep/Graphiti, arquitectura de memoria de OpenClaw | Recuperación, consolidación, grafos temporales; OpenClaw ya tiene etiquetas de procedencia y cuarentena. | En su mayoría atados a un framework; el índice y la verdad no están separados; migrar y borrar es difícil. | | Sandboxes y runtimes | E2B, Daytona, Vercel Sandbox | Cómputo aislado e instantáneas. | El almacenamiento no es el foco; el estado desaparece con el sandbox. | | Almacenamiento de propósito general | S3 y S3 Files, NFS, SMB, Git | Duradero, maduro, con un ecosistema completo. | No conoce “ejecución”, “concesión” ni “contaminación”. | **El hueco.** Cada pieza la ha construido alguien. Lo que no vemos es un contrato **autoalojado, abierto y comprobable** que las combine, con la ejecución como unidad, que una ramas, concesiones, aprobación, registros, memoria y olvido, y que lleve pruebas de conformidad. No afirmamos que nadie haya hecho ninguna de estas cosas por separado; precisamente por eso tomamos tanto prestado. ## Cómo se relaciona con los enfoques vecinos | Enfoque | Bueno en | Relación con Agent NAS | | --- | --- | --- | | QNAP QuAgent, Synology DSM Agent, TrueNAS MCP | Gestionar un NAS en lenguaje natural | Complementarios; sus equipos pueden ser la base de un Overlay. | | Turso AgentFS, Redis Agent Filesystem, LayerFS | Sistemas de archivos para agentes | Pueden servir como motores de Store; Agent NAS añade el contrato por encima. | | Letta Context Repositories | Memoria respaldada por Git | Agent Home toma prestadas sus ideas de organización; Letta puede ser un runtime para Agent Memory. | | Cloudflare Artifacts, Tigris, lakeFS | Almacenamiento bifurcable y versionado | Se pueden usar directamente como motores de Store. | | Mem0, Zep/Graphiti | Recuperación y consolidación de memoria | Pueden ser indexadores, es decir, productores de derivados. | | Arquitectura de memoria de OpenClaw | Etiquetas de procedencia y cuarentena | Un precursor; ponemos las mismas ideas en la capa de almacenamiento compartida. | | S3, S3 Files, NFS, SMB | Almacenamiento de propósito general | Pueden servir como Store; no conocen las ejecuciones, las concesiones ni la contaminación. | | E2B, Daytona, Vercel Sandbox | Cómputo aislado | Complementarios; conviene usarlos juntos. | ## Lo que hemos tomado prestado - De **Git y lakeFS:** ramas, ramas protegidas, hooks previos a la fusión. - De **Letta y Cursor:** los archivos son la interfaz que mejor conocen los agentes, y el contexto debe revelarse de forma progresiva. - De **OpenClaw y la investigación en seguridad de la memoria:** la procedencia no se puede falsificar, y la memoria no fiable se pone en cuarentena. - De **la Rule of Two de Meta, CaMeL y Fides:** limitar las consecuencias fuera del modelo. - De **OAuth (RFC 8693, RFC 9396), Biscuit y UCAN:** intercambio de tokens y autorización atenuante. - De **OpenTelemetry y Certificate Transparency:** trazas exportables y manipulación detectable. - De **la investigación sobre el modo automático de Anthropic:** mantener pocas aprobaciones, y ponerlas en los planes y las fusiones. ## Lo que es genuinamente nuevo Intentamos ser honestos. La lista es corta: 1. Usar la **ejecución** como unidad, uniendo rama, concesión, presupuesto y registro. 2. El **manifiesto de lectura** y la contaminación de sesión: aplicar la Rule of Two en la frontera del almacenamiento. 3. Escrituras de memoria que llevan **procedencia y contaminación**, y la frontera de confianza de “carga automática solo si está revisada”. 4. **Clases de retención:** convertir “recuperable” frente a “olvidable” en una elección explícita. 5. **Una escalera de conformidad con pruebas de aceptación ejecutables.** > **Un juicio que aún hay que demostrar.** Todo lo demás, incluidas las ramas, los tokens, los registros y la recuperación, es una combinación de técnicas existentes. Creemos que combinarlas en un contrato abierto y comprobable tiene valor propio, pero eso es un **juicio que aún hay que demostrar**, no un hecho establecido. --- URL canónica: https://agentnas.com/es/compare/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Especificación > El borrador v0.2 de la especificación define cinco niveles de conformidad acumulativos, de L0 Files a L4 Sync. Cada nivel corresponde a un conjunto de conceptos y a un conjunto de pruebas de aceptación ejecutables; una afirmación de “compatible” sin un `conformance.json` no se acepta. > **Borrador.** Todavía no hay implementación de referencia ni una suite de conformidad ejecutable. Las pruebas de aceptación de abajo forman parte de la especificación: su función es que la palabra “compatible” se pueda comprobar. ## Componentes de la especificación | Componente | Contenido | Versión objetivo | | --- | --- | --- | | Core | Los seis sustantivos, el contrato de Store, las ramas y los árboles protegidos, las fusiones, el borrado lógico. | Borrador v0.3 | | Lease & Record | El formato de la concesión (un perfil de `authorization_details`), el formato de los registros y de los manifiestos de lectura, `explain`. | Borrador v0.3 | | Interfaces | Semántica del montaje, las proyecciones de Git y S3, la API HTTP, la superficie de herramientas MCP. | Borrador v0.4 | | Memory | Convenciones de notas, derivados y recetas, lecturas con presupuesto, punteros de evidencia. | Borrador v0.4 | | Guard | Etiquetas, contaminación de sesión, el perfil de políticas, las Gate Cards, el informe de olvido. | Borrador v0.5 | | Sync | Paquetes de traspaso, umbrales de etiquetas, lápidas (tombstones). | Más adelante | | Conformance Suite | Pruebas de aceptación ejecutables para cada nivel. | A la par de cada versión | ## Niveles de conformidad Los niveles son acumulativos: para afirmar L2 hay que cumplir también L0 y L1. | Nivel | Nombre | Conceptos que cubre | En una línea | | --- | --- | --- | --- | | L0 | Files | Agent Home, Agent Branch | Un directorio con historial. | | L1 | Authority | Flight Recorder, Capability Lease, Human Gate | Quién hizo qué, y con qué autoridad. | | L2 | Memory | Agent Memory, Budgeted Reads | Una memoria que se puede leer y mover. | | L3 | Guard | Trust Labels, Cascade Forget | Limitar las consecuencias. | | L4 | Sync | Ninguno (opcional) | Varios nodos. | ## L0 Files: un directorio con historial 1. Cambiar archivos en una rama de ejecución deja intacta la línea principal protegida. 2. Una escritura directa en un árbol protegido se rechaza, incluso con credenciales válidas. 3. Cuando se borra un archivo de un árbol protegido, se puede restaurar desde la papelera. 4. Exportar y luego importar produce un árbol y un historial idénticos byte a byte. 5. Se ofrecen al menos dos vistas estándar: montaje y Git, o una de ellas más S3. ## L1 Authority: quién hizo qué, y con qué autoridad 1. Una solicitud sin concesión se rechaza, y el rechazo se registra. 2. Se rechaza la solicitud de una concesión hija más amplia que su padre. 3. Cuando una concesión caduca, el montaje pasa a solo lectura; la revocación surte efecto dentro del límite de tiempo que declare la implementación. 4. Ninguna concesión puede borrar una instantánea. 5. Para cualquier commit, `explain` devuelve la ejecución, la concesión y el manifiesto de lectura que lo produjeron. 6. La verificación de la cadena de registros pasa; tras manipular un registro, la verificación falla. 7. Al fusionar en un árbol protegido, la Gate Card muestra un diff calculado por el NAS, y la aprobación queda ligada a un digest: si cambia el diff, la aprobación queda anulada. ## L2 Memory: una memoria que se puede leer y mover 1. Tras borrar y reconstruir todos los índices, pasan las pruebas de recuperación de referencia (golden recall). 2. Las notas se pueden leer sin la capa Memory. 3. Cada derivado lleva una receta y sus entradas. 4. Una lectura con presupuesto degrada la calidad cuando el presupuesto es demasiado pequeño, y declara la vista que realmente devolvió. 5. Los punteros de evidencia se pueden verificar: después de que cambien los commits, un puntero sigue apuntando al contenido original. ## L3 Guard: limitar las consecuencias 1. Con una concesión que incluye B y C, cuando una sesión que leyó contenido `external` activa una acción de clase C, se rechaza o se pasa a una compuerta. 2. Un derivado hereda la unión de las etiquetas de sus entradas. 3. Las notas escritas por una sesión contaminada no se cargan automáticamente. 4. Una solicitud de olvido produce un informe que incluye “lo que no se cubre”; una retención legal puede bloquear el olvido. 5. La evaluación de políticas no llama a un LLM: el motor de políticas no hace llamadas salientes a un modelo, de modo que se puede auditar. ## L4 Sync: varios nodos 1. Cuando dos nodos se sincronizan, los árboles son idénticos. 2. Los objetos de sensibilidad muy alta no se envían a un nodo con una acreditación inferior. 3. Las lápidas del olvido se propagan al par. 4. Un paquete de traspaso se puede ejecutar en el par, y las concesiones solo se estrechan. ## El formato de declaración Una implementación debe publicar un `conformance.json` que indique el nivel con el que cumple, el resultado de cada prueba y las desviaciones conocidas. Una afirmación de “compatible” sin este archivo no se acepta. *conformance.json* ```json { "implementation": "example-nas", "version": "0.1.0", "spec": "0.2", "level": "L1", "tests": { "L0.1": "pass", "L0.2": "pass", "L0.3": "pass", "L0.4": "pass", "L0.5": "pass", "L1.1": "pass", "L1.2": "pass", "L1.3": "pass", "L1.4": "pass", "L1.5": "pass", "L1.6": "pass", "L1.7": "pass" }, "deviations": ["L1.3: revocation takes effect within 60 seconds"] } ``` ## Versiones y compatibilidad - Versionado semántico. No se garantiza compatibilidad durante 0.x. - Los campos nuevos son retrocompatibles. - Un campo obsoleto mantiene un período de aviso de al menos una versión. ## Lo que la especificación todavía no cubre Los detalles de versión de los protocolos de transporte, un lenguaje de políticas concreto, el algoritmo de firma de los tokens, motores de almacenamiento concretos y las interfaces de usuario. --- URL canónica: https://agentnas.com/es/spec/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Hoja de ruta > La hoja de ruta se ordena en ahora, después, más adelante y no previsto, sin promesas año por año: un calendario a tres años escrito en 2026 lo reescribirían los hechos, con toda probabilidad, antes de que acabase el primer año. ## Ahora, después, más adelante - **Ahora (4.º trimestre de 2026)** · En curso · **Concepto, borrador de especificación y sitio web**: El concepto y el borrador de la especificación v0.2, y el sitio web en 8 idiomas. Recogida de opiniones: entrevistar a entre 3 y 5 usuarios reales que ya combinan `AGENTS.md` con Git, para poner a prueba las apuestas B1 a B7. - **Después (objetivo: primera mitad de 2027)** · Siguiente · **Implementación de referencia v0 y especificación v0.3**: Implementación de referencia v0 (Lite y Overlay): backends de Git y de instantáneas del sistema de archivos, emisión de concesiones, registros y manifiestos de lectura, una CLI y una suite de conformidad para L0 a L1; especificación v0.3 (Core, Lease & Record). Un escenario demostrable: un agente trabaja de noche en una rama, y por la mañana apruebas la fusión en una Gate Card. - **Más adelante (según las opiniones recibidas)** · Más adelante · **Memory, Guard, la sala de control y Sync**: La capa Memory y la superficie de herramientas MCP (L2); Guard: etiquetas, contaminación y olvido en cascada (L3); la sala de control; las formas Team y Cloud; Sync (L4). > **No vinculante.** Es una intención, no una promesa. Lo que define “compatible” son los niveles de conformidad, no el calendario. ## La puerta de etapa (lo que demostraría que nos equivocamos) El listón para dar por terminado “después” **no** es una lista de funciones. Es: funcionar durante una semana en al menos tres flujos de trabajo reales; una tasa de aprobación de compuertas por debajo del 95 %; y haber detectado al menos un problema real. Si no lo conseguimos, volvemos atrás y cambiamos los conceptos en lugar de acumular funciones. ## No previsto - Un motor de almacenamiento propio. - Una base de datos vectorial propia. - Alojamiento de modelos. - Un mercado de habilidades. - Tokens y cadenas de bloques. - Hardware dedicado. ## Preguntas que dejamos abiertas a propósito - ¿Cómo evoluciona el `purpose` de texto libre de una concesión hasta convertirse en una intención estructurada que las máquinas puedan comprobar? - ¿Cómo se registran los fusionadores semánticos y cómo se les da confianza? - ¿Debe ser la granularidad de las etiquetas el archivo o el párrafo? - En entornos multiinquilino, ¿cómo se gobierna el vocabulario de etiquetas? - ¿Cómo se debe describir hacia el exterior el retardo de propagación de la revocación entre nodos? - ¿Cómo medimos la calidad de la memoria? ¿Cuál es el estándar de regresión cuando cambian el modelo o los embeddings? - Para un hecho inferido de varias fuentes, ¿cómo define Cascade Forget el alcance afectado? - Con un alto rendimiento, ¿cómo se equilibran el coste de almacenamiento y la granularidad de los manifiestos de lectura? - ¿Cuál es la mejor interfaz para la revisión por lotes y por niveles? ¿Cómo se miden y se ajustan los umbrales de la fusión automática? - ¿Cómo se distribuyen y se revocan las raíces de confianza entre organizaciones? --- URL canónica: https://agentnas.com/es/roadmap/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Principios de diseño > Ocho tesis guían cada compromiso de Agent NAS; siete apuestas dicen a qué juega y qué pasa si la apuesta sale mal. Un diseño que aspira a durar años debería decir cuándo se equivocará. ## 1. La unidad de acceso es la ejecución, no la cuenta La práctica actual es darle a un agente un token de larga duración o una cuenta humana: el token del incidente de abril de 2026 estaba “hecho para gestionar dominios, pero podía hacerlo todo”. Una ejecución tiene principio, fin, propósito y un responsable, lo que la convierte en una unidad natural de autorización y de rendición de cuentas. *Descarta:* las claves compartidas, los tokens de larga duración y las cuentas humanas prestadas. ## 2. Deshacer es más barato que prevenir La prevención (aprobaciones, clasificadores, reglas en los prompts) siempre tendrá fugas: los clasificadores fallan, las personas fallan más, y los modelos rompen los principios escritos en sus prompts. Hacer que los errores sean **reversibles** (ramas, borrado lógico, instantáneas) es mucho más fácil que hacer que cada acción sea correcta, y más fácil de verificar. Un corolario: **la vía de recuperación debe quedar fuera del radio de impacto de lo que protege**, por eso las instantáneas están en manos del propietario y fuera del poder de cualquier concesión. *Descarta:* tratar “una línea en el prompt que pide confirmación” como un control. ## 3. La autoridad se presta por tarea, no se concede por identidad Una ejecución recibe una concesión estrecha y limitada en el tiempo, con presupuestos; las claves de larga duración se quedan con el orquestador o con el propietario, y el modelo nunca las ve. *Descarta:* los permisos permanentes, amplios y de larga duración. ## 4. Las notas son la verdad, la inteligencia es caché La memoria debería ser archivos que las personas puedan leer y editar; los índices, los embeddings y los resúmenes son derivados desechables y reconstruibles. Así el algoritmo de recuperación puede cambiar sin perder memoria, y el envenenamiento y el borrado se vuelven manejables. *Descarta:* los almacenes de memoria opacos que no se pueden inspeccionar ni mover. ## 5. La procedencia es la columna vertebral Cada recuerdo, cada derivado y cada fusión pueden responder a “¿de dónde viene y qué lo influyó?”. La procedencia es la base de la auditoría y también del control del envenenamiento, de las etiquetas de confianza y del olvido. *Descarta:* la memoria sin procedencia. ## 6. La política es determinista, y los modelos solo pueden endurecerla Las decisiones de autorización las toma el código, no la “opinión” de un modelo. Un clasificador o un LLM puede sugerir que “este paso necesita aprobación”, pero nunca puede aprobar. *Descarta:* dejar que un modelo decida por sí mismo si algo puede pasar. ## 7. Mantén el almacenamiento aburrido y pon la innovación en el contrato Ningún motor nuevo; primero los archivos, porque la interfaz que mejor conocen los modelos es el archivo; los protocolos cambiarán, los seis sustantivos no. *Descarta:* inventar un motor de almacenamiento nuevo en nombre de la IA. ## 8. Lo escaso son los tokens y la atención humana Las lecturas tienen un presupuesto; las aprobaciones son pocas y concretas, y están donde una persona puede juzgar de verdad: en los planes y las fusiones, no en cada acción. *Descarta:* devolver archivos enteros por defecto; una ventana emergente por cada acción. ## Siete apuestas y qué las refutaría Un diseño que aspira a durar años debería decir a qué apuesta y cuándo se equivocaría. | Apuesta | Fundamento | Si falla | | --- | --- | --- | | B1 Los agentes seguirán usando el sistema de archivos y Git como su principal medio de trabajo | Varios runtimes importantes ya se han pasado a los archivos. | Si pasan a “APIs de memoria” dedicadas, Agent Home se degrada a un formato de exportación; los demás conceptos no dependen de los archivos y siguen en pie. | | B2 “Una ejecución” sigue siendo la unidad natural de autorización y de rendición de cuentas | Los orquestadores suelen arrancar sandboxes por tarea o por sesión. | Si aparecen procesos autónomos de larga vida, las concesiones pasan a ser renovaciones continuas con presupuestos, y el concepto se mantiene. | | B3 La inyección de prompts no se erradicará en la capa del modelo en un futuro previsible | La propia formulación de Meta; las tasas de fallo de los clasificadores; varios estudios de ataques. | Si se erradica, las Trust Labels pasan a ser una capa barata de defensa en profundidad. | | B4 La atención humana sigue siendo escasa | Datos publicados por Anthropic. | Si la automatización total llega a ser lo bastante fiable, una Human Gate deja paso a una política de autorización previa, y la auditoría se mantiene. | | B5 La capa de almacenamiento es el lugar adecuado para imponer la procedencia y la contaminación | La investigación sobre seguridad de la memoria insiste en la procedencia en el momento de escribir; OpenClaw hizo lo mismo dentro de un runtime. | Si cada runtime lo hace bien por sí mismo, al NAS solo le queda almacenar las etiquetas, y su papel se adelgaza. | | B6 La memoria compartida entre runtimes y agentes se convertirá en una necesidad real | La colaboración entre varios agentes; el coste de migrar de framework. | Si la memoria sigue siendo una función privada de cada framework, el valor de Agent Memory estará sobre todo en la portabilidad para particulares y equipos pequeños. | | B7 Los protocolos cambiarán, pero “archivos más herramientas” como dos puertos seguirá estable | Las migraciones de versión de MCP; A2A 1.0. | Se cambian los adaptadores; por eso los adaptadores aíslan los protocolos. | ## Qué esperamos que siga estable y qué esperamos que cambie | Se espera que siga estable | Se espera que cambie | | --- | --- | | Los seis sustantivos | Los protocolos y transportes concretos | | La convención de directorios de un Home | Los modelos de embeddings y los algoritmos de recuperación | | Las cuatro promesas | Los formatos de token | | La garantía de que “exportar significa poder irse” | Los frameworks de agentes y las interfaces persona-máquina | --- URL canónica: https://agentnas.com/es/principles/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # FAQ > Respuestas a las preguntas que más se hacen primero sobre Agent NAS: qué es, en qué se diferencia de las herramientas de almacenamiento y de memoria existentes, cómo trata la seguridad y la privacidad, y en qué punto está el proyecto. ## Lo básico ### ¿Qué es Agent NAS? Agent NAS es almacenamiento conectado en red diseñado en torno a la ejecución: cada ejecución de un agente trabaja en una rama aislada y accede a los datos mediante una concesión estrecha y de corta duración; cada cambio se puede rastrear y deshacer; y la memoria son archivos normales con procedencia. Se sirve por montajes, Git, S3 y MCP. ### ¿Es Agent NAS un producto que pueda comprar o descargar? Todavía no. Por ahora es un concepto con un borrador de especificación (v0.2, noviembre de 2026). L0 y L1 se pueden construir hoy con piezas existentes; el objetivo para la implementación de referencia v0 es la primera mitad de 2027, y el plan posterior está en la [hoja de ruta](https://agentnas.com/es/roadmap/). ### ¿En qué se diferencia de los agentes de IA que incluyen los fabricantes de NAS? Los agentes de fabricantes como QNAP, Synology y TrueNAS administran el equipo. Agent NAS especifica cómo trabajan otros agentes sobre los datos que hay dentro del equipo: ramas, concesiones, memoria y olvido. Se complementan; consulta la [comparación](https://agentnas.com/es/compare/). ### ¿En qué se diferencia de una base de datos vectorial o de un framework de memoria? Esas son herramientas de recuperación y consolidación, mientras que la verdad en Agent NAS son notas normales con procedencia. Un almacén vectorial o un framework de memoria puede situarse bajo [Agent Memory](https://agentnas.com/es/concepts/agent-memory/) como indexador, y el índice siempre se puede tirar y reconstruir. ### ¿Es de código abierto? La especificación y este sitio tienen licencia CC BY 4.0. La implementación de referencia está prevista como código abierto bajo Apache-2.0. ## Diseño y seguridad ### ¿Por qué archivos y Git en lugar de una base de datos? Los agentes están convergiendo en los archivos: instrucciones en `AGENTS.md`, habilidades en `SKILL.md`, memoria en Markdown, historial en Git. Cualquier herramienta y cualquier modelo puede leer archivos, es fácil compararlos y fácil llevárselos. Las bases de datos y los índices se siguen usando, pero como una capa derivada que se puede reconstruir. ### ¿Qué es lo peor que puede pasar cuando una ejecución sale mal? Lo peor es perder una rama desechable: la línea principal protegida solo cambia mediante fusiones revisadas, los borrados son lógicos y las instantáneas quedan fuera de toda concesión. Eso vale cuando el error ocurre dentro del NAS; un correo ya enviado o una API externa ya llamada son cosas que el NAS no puede deshacer. ### ¿Cómo se relaciona una concesión con un token de OAuth? Una concesión es un token de acceso de OAuth: se solicita mediante intercambio de tokens (RFC 8693) y describe rutas y acciones con Rich Authorization Requests (RFC 9396). Lo que añade Agent NAS es la convención por ejecución, que incluye ramas, presupuestos y propiedades de la Rule of Two. Consulta [Capability Lease](https://agentnas.com/es/concepts/capability-lease/). ### ¿Por qué “notas más una caché” para la memoria? Para poder inspeccionarla, corregirla, moverla y olvidarla. Las notas son archivos; los índices, los embeddings y los resúmenes se calculan a partir de ellas con una receta documentada. Si cambias el modelo de embeddings, el sistema recalcula en segundo plano. Las notas escritas por una sesión contaminada pasan primero a cuarentena y no se cargan automáticamente hasta que se revisan. ### ¿Puede Agent NAS detener la inyección de prompts? No. Nada fuera del modelo puede detenerla por completo. Agent NAS limita lo que puede hacer un agente inyectado: las [Trust Labels](https://agentnas.com/es/concepts/trust-labels/) impiden que una sesión que leyó contenido externo tenga además datos sensibles y un canal de salida, y las acciones con consecuencias necesitan una [Human Gate](https://agentnas.com/es/concepts/human-gate/). Los límites honestos están en la página de [seguridad](https://agentnas.com/es/security/). ### ¿Cómo trata el “derecho al olvido”? Mediante [Cascade Forget](https://agentnas.com/es/concepts/cascade-forget/): borra siguiendo el linaje los resúmenes, los embeddings y las notas derivadas de una fuente, trata el historial según la clase de retención y destruye las claves de la clase `sensitive` (destrucción criptográfica). Su informe enumera de forma explícita lo que no puede cubrir: copias fuera del NAS, registros de los proveedores de modelos y pesos de los modelos. No puede hacer que un modelo olvide nada. ### ¿Tengo que usar MCP? No. MCP es solo una de las interfaces del plano de control; los archivos, Git y S3 no lo necesitan, y la capa de protocolos está diseñada para poder sustituirse. ## Adopción y futuro ### ¿Sustituirá a mi NAS o a mi almacenamiento en la nube? No. La forma de despliegue Overlay coloca una pasarela delante de un NAS, un almacén de objetos o un host de Git ya existentes y gestiona solo un directorio o un bucket dentro de él. El almacenamiento en la nube también puede servir como Store. ### ¿Con qué frameworks y runtimes de agentes funciona? Con cualquier runtime que pueda montar un directorio o usar Git, S3 o MCP. La organización de un Agent Home sigue convenciones abiertas (`AGENTS.md`, Agent Skills, Markdown con frontmatter YAML), así que Claude Code, Cursor, Codex, OpenHands, LangGraph y los frameworks propios son todos candidatos. ### ¿Puedo irme en cualquier momento? Sí. Todo se puede exportar como archivos normales e historial de Git. Es una de las cuatro promesas, no una función. ### ¿Cuándo no debería usar Agent NAS? Cuando tienes un solo agente y datos que puedes rehacer sin problema: un repositorio Git con un `AGENTS.md` basta. Hay más casos en [casos de uso](https://agentnas.com/es/use-cases/). ### ¿Cómo lo cito o contribuyo? Cada página indica su URL canónica y una cita sugerida. Para contribuir, abre una issue o inicia una discusión en GitHub. Los detalles están en la página [Sobre el proyecto](https://agentnas.com/es/about/). --- URL canónica: https://agentnas.com/es/faq/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Glosario > Este glosario define todos los términos que usa Agent NAS: los nueve conceptos con nombre y el vocabulario de apoyo. Los nombres de los conceptos son términos acuñados y se mantienen en inglés en todos los idiomas. ## Los nueve conceptos - **[Agent Home (hogar del agente)](https://agentnas.com/es/concepts/agent-home/)**: **Un Agent Home** es un directorio por rol, con historial: instrucciones, habilidades, memoria, diario y espacio de trabajo, todo como archivos normales. Cualquier runtime puede entrar en él, y puedes llevártelo todo cuando te vayas. - **[Agent Branch (rama del agente)](https://agentnas.com/es/concepts/agent-branch/)**: **Un Agent Branch** permite que cada ejecución trabaje en una rama copy-on-write. Los cambios llegan a la línea principal protegida solo mediante una fusión revisada (un Agent PR), y puedes crear puntos de control y restaurar en cualquier momento. - **[Flight Recorder (registrador de vuelo)](https://agentnas.com/es/concepts/flight-recorder/)**: **Un Flight Recorder** es un registro de solo anexado y encadenado por hashes que se lleva por ejecución: qué leyó la ejecución (el manifiesto de lectura), qué escribió, qué se permitió o se denegó y quién aprobó qué. Vive junto a los datos y responde a una pregunta: “¿qué pudo influir en este cambio?” - **[Capability Lease (concesión de capacidad)](https://agentnas.com/es/concepts/capability-lease/)**: **Una Capability Lease** es una autorización para datos concretos y operaciones concretas, con una caducidad explícita y presupuestos. Se emite a **una ejecución** y es la única vía por la que una ejecución toca el NAS. Una concesión hija solo puede ser más estrecha que su padre. - **[Human Gate (compuerta humana)](https://agentnas.com/es/concepts/human-gate/)**: **Una Human Gate** es un punto de control activado por la política: antes de que surta efecto una acción **irreversible, hacia el exterior o que eleve privilegios**, una persona (o un aprobador designado) aprueba una acción concreta, totalmente representada. Está pensada para ser infrecuente, específica y difícil de aprobar por inercia. - **[Trust Labels (etiquetas de confianza)](https://agentnas.com/es/concepts/trust-labels/)**: **Las Trust Labels** son dos conjuntos de etiquetas muy pequeños asociados a los datos, **origen** (`owner`, `agent`, `external`) y **sensibilidad** (`public`, `private`, `secret`), más la **contaminación de sesión**. El NAS hace cumplir la Rule of Two como un invariante de sesión: una sesión no puede tener a la vez [A] ha leído contenido externo, [B] toca datos sensibles y [C] cambia un estado protegido o se comunica hacia el exterior. Completar la tercera exige una [Human Gate](https://agentnas.com/es/concepts/human-gate/). - **[Agent Memory (memoria del agente)](https://agentnas.com/es/concepts/agent-memory/)**: **Agent Memory** = **notas que puedes leer y editar** + **índices que puedes tirar en cualquier momento**. Cada nota cita sus fuentes; los índices (texto completo, vectoriales, de grafo, esquemas) son solo derivados de las notas; y las tareas de mantenimiento en segundo plano solo **proponen** ediciones y nunca reescriben el diario original. - **[Budgeted Reads (lecturas con presupuesto)](https://agentnas.com/es/concepts/budgeted-reads/)**: **Budgeted Reads** son lecturas medidas en un presupuesto de tokens: el mismo archivo se puede leer con distintos niveles de detalle, del esquema y la sección al rango de líneas y al texto completo. El agente pide “la mejor vista que quepa en N tokens” y recibe punteros de evidencia al origen exacto. - **[Cascade Forget (olvido en cascada)](https://agentnas.com/es/concepts/cascade-forget/)**: **Cascade Forget** es el borrado siguiendo el linaje: cuando se borra una fuente, o alguien pide que lo olviden, el NAS encuentra todo lo derivado de ella (resúmenes, embeddings, notas que la citan, cachés y enlaces compartidos), lo borra o lo vuelve a derivar sin esa fuente, y emite un **informe**: qué se hizo y qué no se pudo hacer. ## Términos de apoyo - **Principal (sujeto)**: Una entidad que puede autenticarse y rendir cuentas: una persona, un agente, un servicio o un nodo. - **Run (ejecución)**: Una ejecución con principio, fin, propósito y un responsable. Una ejecución tiene una concesión raíz y es dueña de una rama. - **Protected tree (árbol protegido)**: Un árbol que solo se actualiza mediante una fusión revisada y nunca acepta escrituras directas, por ejemplo `main`. - **Read manifest (manifiesto de lectura)**: El registro agregado de las rutas, los commits, los rangos y los hashes de contenido que ha leído una ejecución. No contiene el contenido. - **Evidence pointer (puntero de evidencia)**: Una referencia verificable con la forma `nas:////@#L12-L18` a líneas exactas de un commit. - **Derived data (datos derivados)**: Datos calculados a partir de las notas mediante una receta, como un índice, un embedding o un resumen. Se pueden descartar y reconstruir. - **Recipe (receta)**: Todo lo necesario para producir un objeto derivado: el modelo y su versión, el fragmentador y los parámetros. - **Lineage (linaje)**: El grafo de dependencias entre los objetos derivados y las entradas a partir de las que se calcularon. - **Session taint (contaminación de sesión)**: La unión de las etiquetas de todo lo que ha leído una sesión. Solo crece dentro de una sesión y decide lo que esta puede hacer a continuación. - **Rule of Two (regla de dos)**: Una heurística de Meta: hasta que la inyección de prompts esté resuelta de forma fiable, una sesión debería tener como máximo dos de tres propiedades: [A] procesa entradas no fiables, [B] accede a datos sensibles, [C] cambia el estado o se comunica con el exterior. - **Declassification (desclasificación)**: Bajar la sensibilidad de unos datos o subir la confianza en su origen. Solo mediante una Human Gate o un traspaso estructurado validado por esquema. - **Policy envelope (sobre de políticas)**: Un rango fijado de antemano por el propietario dentro del cual las concesiones se emiten de forma automática. Lo que queda fuera pasa a una Human Gate. - **Credential Broker (intermediario de credenciales)**: Un componente que guarda los secretos de larga duración y emite tokens de corta duración solo para acciones de salida aprobadas. Los modelos y las ejecuciones nunca ven los secretos de larga duración. - **Agent PR**: Una propuesta estructurada para fusionar una rama en un destino, con el diff, la procedencia, los resultados de las comprobaciones y un resumen de etiquetas. - **Retention class (clase de retención)**: Una de `scratch`, `normal` o `sensitive`, elegida al escribir. Decide las copias de seguridad, el historial y si los datos se pueden destruir. - **Crypto-shredding (destrucción criptográfica)**: Destruir una clave para que todas las copias cifradas con ella queden ilegibles. - **Conformance level (nivel de conformidad)**: Un nivel de L0 a L4. Cada uno corresponde a un conjunto de conceptos y a un conjunto de pruebas de aceptación ejecutables. - **MCP**: Model Context Protocol: un protocolo abierto entre agentes y herramientas o fuentes de datos. - **A2A**: El protocolo Agent2Agent: un protocolo abierto para que los agentes colaboren en tareas. --- URL canónica: https://agentnas.com/es/glossary/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Sobre el proyecto > agentnas.com es la casa del concepto Agent NAS y de su borrador de especificación. Es un proyecto abierto que aspira a dar a las personas y a los agentes un vocabulario compartido y un contrato comprobable que puedan seguir varias implementaciones independientes. ## Estado En noviembre de 2026, Agent NAS es un concepto con un borrador de especificación (v0.2). Todavía no hay implementación de referencia ni una suite de conformidad ejecutable. La v0.2 es una revisión de realismo: trece conceptos se redujeron a nueve, y cada uno indica cómo empezar en pequeño y cuáles son sus límites honestos. Este sitio web es lo primero que ha publicado el proyecto. Consulta la [hoja de ruta](https://agentnas.com/es/roadmap/) para ver el plan. ## Licencia El texto y los diagramas de este sitio y de la especificación tienen licencia [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/): puedes compartirlos y adaptarlos siempre que reconozcas la autoría. Está previsto publicar la implementación de referencia bajo Apache-2.0. ## Cómo citar Cita la página que hayas usado y reproduce su definición literalmente cuando puedas. Cada página muestra al final su URL canónica y una cita sugerida. Para citar el proyecto en su conjunto: *Cita* ```text Proyecto Agent NAS. “Agent NAS: almacenamiento conectado en red para agentes de IA.” Especificación v0.2 (borrador), noviembre de 2026. https://agentnas.com/es/what-is-agent-nas/ ``` *BibTeX* ```bibtex @misc{agentnas2026, title = {Agent NAS: almacenamiento conectado en red para agentes de IA}, author = {{Proyecto Agent NAS}}, year = {2026}, howpublished = {Especificación v0.2 (borrador)}, url = {https://agentnas.com/es/what-is-agent-nas/} } ``` ## Gobernanza - **La especificación y las implementaciones son cosas distintas.** Se agradecen muchas implementaciones; lo que define “compatible” son las pruebas de conformidad y el `conformance.json`, no una marca. - **Proceso.** Propuestas públicas (issues y PR); los cambios importantes deben exponer su motivación, sus pruebas y los contraejemplos. - **Nombre.** “Agent NAS” es un nombre descriptivo del concepto; afirmar un nivel de conformidad exige publicar un `conformance.json`. - **Se agradece el desacuerdo.** Cualquier objeción a una tesis es valiosa, en especial a las [siete apuestas](https://agentnas.com/es/principles/). ## Participa Se agradecen las correcciones, las críticas y las notas de implementación. Abre una issue o una discusión en el [repositorio del proyecto](https://github.com/xwzy/agentnas.com). Este sitio no publica una dirección de correo; los avisos de seguridad sobre la especificación usan el mismo canal. ## Para agentes y rastreadores - Cada página tiene un gemelo en Markdown: añade `index.md` a su dirección o envía `Accept: text/markdown`. - [/es/llms.txt](https://agentnas.com/es/llms.txt) es un índice seleccionado, y [/es/llms-full.txt](https://agentnas.com/es/llms-full.txt) es el texto completo. - Un servidor MCP para esta documentación funciona en `https://agentnas.com/mcp` y está descrito por su [server card](https://agentnas.com/mcp/server-card). - Un endpoint de búsqueda, `POST /api/search`, está descrito en [/openapi.json](https://agentnas.com/openapi.json). - El [AI Catalog](https://agentnas.com/.well-known/ai-catalog.json) y el [mapa del sitio](https://agentnas.com/sitemap.xml) lo enumeran todo. - El contenido se puede indexar, citar y usar como entrada de respuestas con libertad. Consulta [/robots.txt](https://agentnas.com/robots.txt). --- URL canónica: https://agentnas.com/es/about/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Agent Home (hogar del agente) *Un directorio por rol, con historial. Archivos normales que puedes llevarte contigo.* > **Un Agent Home** es un directorio por rol, con historial: instrucciones, habilidades, memoria, diario y espacio de trabajo, todo como archivos normales. Cualquier runtime puede entrar en él, y puedes llevártelo todo cuando te vayas. **AN-01** · Nivel de conformidad: L0 Files · Grupo: Trabajo ## El problema El estado de un agente está repartido entre bases de datos de frameworks, APIs de memoria alojadas por el proveedor y discos de sandbox que pueden desaparecer en cualquier momento. Si cambias de framework o de proveedor, el estado se pierde; cuando algo sale mal, no hay un único lugar donde ver qué sabe realmente el agente. Al mismo tiempo, los agentes principales están convergiendo en los archivos: `AGENTS.md`, Agent Skills, repositorios de memoria respaldados por Git. Lo que falta no es un formato nuevo, sino un lugar para ellos con **dueño, historial, cuotas y exportación garantizada**. ## Cómo funciona - **La organización sigue convenciones abiertas.** `AGENTS.md`, el `SKILL.md` de Agent Skills y Markdown con frontmatter YAML, como en el esbozo de abajo. No inventamos un formato. - **Un Home pertenece a un rol, no a una ejecución.** Las ejecuciones lo usan a través de [ramas](https://agentnas.com/es/concepts/agent-branch/): los cambios llegan primero a una rama y se fusionan de vuelta en el Home tras la revisión. - **Tiene historial.** Cada cambio es un commit. `nas export` o `git clone` se llevan el Home entero, incluidos los metadatos en texto plano de `.nas/`. - **El contexto de arranque es solo leer unos pocos archivos:** `AGENTS.md`, `memory/MEMORY.md` y un resumen de la bandeja de entrada. No hay un protocolo especial de despertar; un NAS puede ofrecer, como comodidad, una vista `briefing` con tope de tokens, pero no es obligatoria. - **Solo se cargan automáticamente las notas revisadas.** Solo las notas marcadas como `reviewed` entran en `MEMORY.md` y en el contexto de carga automática; consulta [Trust Labels](https://agentnas.com/es/concepts/trust-labels/) y [Agent Memory](https://agentnas.com/es/concepts/agent-memory/). - **Ciclo de vida.** Creación a partir de una plantilla, cuotas, archivo y retirada, con un heredero que se puede nombrar al retirar. ## Empezar en pequeño - Crea un directorio con `AGENTS.md`, `skills/` y `memory/`, y ejecuta `git init`. Enlaza simbólicamente `CLAUDE.md` y archivos similares a `AGENTS.md`. - Ejecuta `git worktree add` antes de cada ejecución para que trabaje en su propio árbol de trabajo. - Eso es L0: sin ningún software de Agent NAS ya tienes un Home con historial que puedes llevarte. ## Esbozo de la interfaz Solo ilustrativo. Los nombres de los campos pueden cambiar antes de la especificación v0.3. *layout* ```text /agents/cleo/ # a role's Home: it belongs to the role, not to one run ├── AGENTS.md # instructions (open convention) ├── skills/ # Agent Skills: one directory per skill │ └── release-notes/SKILL.md ├── memory/ │ ├── MEMORY.md # reviewed core memory: auto-loaded, token-capped │ ├── notes/ # notes: Markdown + YAML frontmatter │ ├── journal/ # raw log: append-only │ └── quarantine/ # unreviewed notes: recallable, never auto-loaded ├── inbox/ # tasks and messages received ├── outbox/ # deliverables and replies ├── workspace/ # scratch space (retention class: scratch) └── .nas/ # plain-text metadata: role.yaml, limits.yaml, maintenance.yaml ``` ## Lo que pide la especificación - Un Home DEBE poder reconstruirse solo desde Store; leerlo NO DEBE depender de ningún dato derivado. - Los metadatos de `.nas/` DEBEN ser texto plano y DEBEN exportarse con el Home. - El contexto de carga automática DEBE tener un tope de tokens y DEBE provenir solo de notas revisadas. - La organización DEBERÍA seguir convenciones abiertas: `AGENTS.md`, `SKILL.md`, Markdown con frontmatter YAML. - Las ejecuciones DEBEN usar un Home a través de ramas. ## Lo prestado y lo nuevo Lo que sigue está todo prestado, y **muy poco es nuevo**: la organización y Git ya existen. Lo único nuevo es tratar el Home como un objeto de primera clase con cuotas, heredero y garantía de exportación, y fijar la frontera de confianza de que solo se cargan automáticamente las notas revisadas. - [AGENTS.md](https://agents.md) - [Agent Skills](https://agentskills.io/specification) - [Letta Context Repositories](https://www.letta.com/blog/context-repositories/) - [Turso AgentFS](https://github.com/tursodatabase/agentfs) - [Cloudflare Artifacts](https://blog.cloudflare.com/artifacts-git-for-agents-beta/) ## Límites honestos - Los formatos de memoria nativos difieren entre frameworks, así que asignarlos a las convenciones del Home implica pérdidas. - Solo sirve si los runtimes están dispuestos a leer y escribir estos archivos. - El estado oculto del lado del proveedor, como la memoria alojada en la nube de un proveedor, no se puede traer. ## Preguntas abiertas - ¿Cómo deben asignarse en ambos sentidos los formatos de distintos frameworks al Home? - ¿Cómo se mantienen bajo control la carga y la latencia al arrancar con un Home muy grande? ## Preguntas ### ¿Un Agent Home es solo un repositorio Git? En su mayor parte, y a propósito: basta con hacer `git clone`. La diferencia es que además tiene un dueño (un rol), cuotas, un heredero, una garantía de exportación y la regla de que solo se cargan automáticamente las notas revisadas, y el NAS las hace cumplir en lugar de dejarlas como convención. ### ¿Perderé la memoria si cambio de framework de agentes? No, siempre que el nuevo runtime esté dispuesto a leer los archivos. Un Home usa convenciones abiertas: `AGENTS.md`, `SKILL.md` y las notas en Markdown no dependen de ningún framework. Las partes cuya asignación implica pérdidas deben marcarse como sin revisar al importar. ### ¿Necesito instalar Agent NAS para usar un Home? No. Un directorio de Git con un `AGENTS.md` es un Home L0. Lo que añade un NAS son cuotas, fusiones protegidas, concesiones y un rastro de auditoría, no un formato de archivo. ## Conceptos relacionados - [Agent Branch (rama del agente)](https://agentnas.com/es/concepts/agent-branch/): Cada ejecución trabaja en una rama copy-on-write. Solo una fusión revisada llega a la línea principal. - [Agent Memory (memoria del agente)](https://agentnas.com/es/concepts/agent-memory/): Las notas que puedes leer y editar son la verdad. Los índices son una caché que puedes tirar. - [Capability Lease (concesión de capacidad)](https://agentnas.com/es/concepts/capability-lease/): Una autorización estrecha para una ejecución, con caducidad y presupuestos. Las concesiones hijas solo pueden ser más estrechas. --- URL canónica: https://agentnas.com/es/concepts/agent-home/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Agent Branch (rama del agente) *Cada ejecución trabaja en una rama copy-on-write. Solo una fusión revisada llega a la línea principal.* > **Un Agent Branch** permite que cada ejecución trabaje en una rama copy-on-write. Los cambios llegan a la línea principal protegida solo mediante una fusión revisada (un Agent PR), y puedes crear puntos de control y restaurar en cualquier momento. **AN-02** · Nivel de conformidad: L0 Files · Grupo: Trabajo ## El problema Los agentes cometen errores a la velocidad de las máquinas, y los datos compartidos no tienen forma de “probar, ver el diff, revisar, deshacer”. Además, los agentes en paralelo se pisan entre sí. En un incidente de abril de 2026, un agente usó un token demasiado amplio para borrar en 9 segundos un volumen de producción y las copias de seguridad que estaban en el mismo volumen. Si solo hubiera podido escribir en una rama, si los borrados hubieran sido lógicos y si las instantáneas hubieran estado fuera de su autoridad, el daño habría sido mucho menor. ## Cómo funciona - **Las ramas son baratas** (según el motor, idealmente cercanas a O(1)). Una concesión otorga escritura **dentro de la rama** y `propose` hacia el destino. - **Árboles protegidos.** La línea principal solo se puede actualizar mediante una fusión: ni siquiera una credencial filtrada puede escribir en ella directamente. - **Agent PR.** El diff, la intención, la procedencia (un resumen del manifiesto de lectura), los resultados de las comprobaciones y un resumen de etiquetas. Si las comprobaciones pasan y la política lo permite, se fusiona de forma automática; si no, pasa a una [Human Gate](https://agentnas.com/es/concepts/human-gate/). - **Borrado lógico.** Los borrados en un árbol protegido van a una papelera, que por defecto se conserva 7 días; las instantáneas pertenecen al propietario y están **fuera de la autoridad de cualquier concesión**. - **Puntos de control.** Instantáneas con nombre; `restore` devuelve los archivos a un punto de control. - **Fusión.** El texto usa una fusión a tres bandas y los demás archivos se fusionan archivo por archivo. Si hay un conflicto, se detiene y **nunca sobrescribe en silencio**; los datos estructurados necesitan un fusionador registrado, o una persona. - **TTL y cuota,** para evitar las bombas de ramas. - **Intentos en paralelo.** Abre N ramas para una misma tarea, fusiona la mejor y recicla el resto. ## Empezar en pequeño - Ramas y worktrees de Git, más un **main protegido** en Forgejo, Gitea o GitHub. - Para directorios grandes usa instantáneas y clones de btrfs o ZFS; para almacenamiento de objetos, los forks de Tigris o lakeFS. - Empieza por acertar con “los borrados van a la papelera” y “las instantáneas son del propietario”. Son lo más barato y lo que más daño evita. ## Esbozo de la interfaz Solo ilustrativo. Los nombres de los campos pueden cambiar antes de la especificación v0.3. *nas cli* ```bash nas branch create cleo/release-notes --from main --ttl 48h nas checkpoint create before-refactor nas propose --into main --checks links,schema nas restore before-refactor nas trash list # recycle area, kept 7 days by default nas trash restore ``` ## Lo que pide la especificación - Un árbol protegido DEBE poder actualizarse solo mediante una fusión; ninguna credencial puede escribir en él directamente. - Una fusión DEBE producir un commit que lleve procedencia (ejecución, concesión, principal). - Ninguna concesión PUEDE permitir borrar una instantánea ni una copia de seguridad. - Un borrado en un árbol protegido DEBE ser lógico y recuperable dentro de la ventana configurada (7 días por defecto). - Un conflicto NO DEBE resolverse en silencio; la fusión DEBE detenerse y avisar. - Una rama DEBE tener un TTL y una cuota. ## Lo prestado y lo nuevo Lo que sigue es todo práctica establecida. **Lo nuevo:** unir la rama a una **ejecución y una concesión**, de modo que la rama sea la unidad de autorización y la fusión sea la unidad de revisión. Las ramas y las instantáneas en sí no son nuevas. - [Git worktree](https://git-scm.com/docs/git-worktree) - [lakeFS for agents](https://lakefs.io/agentic-ai/) - [Tigris Agent Kit](https://www.tigrisdata.com/docs/ai/agent-kit/) - [Cloudflare Artifacts](https://blog.cloudflare.com/artifacts-git-for-agents-beta/) ## Límites honestos - Una rama solo protege los datos dentro del NAS. **No deshace los efectos secundarios externos:** un correo ya enviado, una API ya llamada. - Los archivos binarios grandes y los archivos de bases de datos son difíciles de fusionar. - La fatiga de revisión sigue siendo posible, así que las rutas de bajo riesgo pueden fusionarse automáticamente y se mide la tasa de aprobación. ## Preguntas abiertas - ¿Cómo se registran los fusionadores semánticos y cómo se les da confianza? - ¿Cómo debe ser la interacción ante los conflictos binarios? ## Preguntas ### ¿En qué se diferencia de una rama de Git? Mecánicamente no es magia: se puede construir sobre Git. La diferencia es que une la rama a una ejecución y a una concesión, de modo que “solo puede escribir en su propia rama” se convierte en una regla de autorización y la fusión pasa a ser el único punto de revisión. ### ¿Una rama evita todos los accidentes? No. Solo protege los datos dentro del NAS: un correo ya enviado o una API externa ya llamada no se deshacen al revertir una rama. Esas acciones deben pasar por `egress` en la concesión y por una Human Gate. ### ¿Cada fusión necesita que una persona la apruebe? No. Una fusión cuyas comprobaciones pasan, cuya ejecución no leyó contenido externo y que no implica borrar ni compartir puede pasar de forma automática. Solo hace falta una persona en unos pocos casos; consulta [Human Gate](https://agentnas.com/es/concepts/human-gate/). ## Conceptos relacionados - [Human Gate (compuerta humana)](https://agentnas.com/es/concepts/human-gate/): Aparece solo antes de acciones irreversibles, hacia el exterior o que elevan privilegios, y muestra el diff real. - [Agent Home (hogar del agente)](https://agentnas.com/es/concepts/agent-home/): Un directorio por rol, con historial. Archivos normales que puedes llevarte contigo. - [Flight Recorder (registrador de vuelo)](https://agentnas.com/es/concepts/flight-recorder/): Un registro por ejecución, encadenado por hashes, que incluye lo que la ejecución leyó. --- URL canónica: https://agentnas.com/es/concepts/agent-branch/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Flight Recorder (registrador de vuelo) *Un registro por ejecución, encadenado por hashes, que incluye lo que la ejecución leyó.* > **Un Flight Recorder** es un registro de solo anexado y encadenado por hashes que se lleva por ejecución: qué leyó la ejecución (el manifiesto de lectura), qué escribió, qué se permitió o se denegó y quién aprobó qué. Vive junto a los datos y responde a una pregunta: “¿qué pudo influir en este cambio?” **AN-03** · Nivel de conformidad: L1 Authority · Grupo: Trabajo ## El problema En un análisis posterior, los registros están dispersos; no hay enlace entre una “lectura” y la acción que le siguió; y los registros los puede editar el mismo administrador, o incluso el mismo agente. Más a fondo: cuando se sospecha que una fusión o un recuerdo están contaminados, no hay forma de responder a “¿qué leyó esa ejecución?”. ## Cómo funciona - **Dos tipos de contenido.** Los *eventos* se registran uno por uno: commits, emisión y revocación de concesiones, solicitudes y decisiones de compuertas, denegaciones de políticas, derivaciones, olvido. El *manifiesto de lectura* se agrega por ejecución: qué rutas@commit, qué rangos y qué hashes de contenido se leyeron. No registra cada llamada de lectura y nunca registra el contenido. - **Cada commit lleva metadatos de procedencia:** `principal`, `on_behalf_of`, `run`, `lease`, `purpose` y una referencia al manifiesto de lectura. - **Una cadena de hashes** (por día), con firmas y anclaje externo opcionales (un segundo nodo, un bucket con bloqueo de objetos). El objetivo es que “**la manipulación se pueda detectar**”, no que “la manipulación sea imposible”. - **Exportación:** spans de OpenTelemetry GenAI, JSON Lines, o hacia un SIEM. - **Privacidad:** por defecto solo metadatos, sin contenido; la retención de los registros es independiente del borrado del contenido; los propios registros tienen control de acceso. - **`explain(commit)`:** devuelve la ejecución, la concesión, las decisiones de las compuertas, el manifiesto de lectura y las entradas que hay detrás de ese commit. - **Primero se registra, después se actúa:** una operación con consecuencias debe escribir antes un registro de intención. ## Empezar en pequeño - Una tabla SQLite de solo anexado más un hash diario. - Trailers de Git como `Run:` y `Lease:` en cada mensaje de commit. - Exporta spans de OpenTelemetry a la pila de observabilidad que ya tengas. ## Esbozo de la interfaz Solo ilustrativo. Los nombres de los campos pueden cambiar antes de la especificación v0.3. *record.json* ```json { "seq": 18211, "time": "2026-11-12T09:14:22Z", "kind": "commit", "run": "run_91ab", "principal": "agt_cleo", "on_behalf_of": "usr_wei", "lease": "lse_7Qk3", "purpose": "Draft the Q4 release notes", "subject": { "path": "/shared/launch/notes.md", "commit": "91ce3a7" }, "read_manifest": "rm_5d2e", "decision": { "effect": "allow", "rule": "r-17" }, "taint": { "external": true, "sensitivity": "private" }, "prev_hash": "sha256:b3a0..." } ``` ## Lo que pide la especificación - Una operación con consecuencias DEBE escribir un registro de intención antes de surtir efecto; si la escritura falla, la operación DEBE fallar. - Cada ejecución DEBE tener un manifiesto de lectura que registre las rutas, los commits y los rangos leídos (no el contenido). - Los registros DEBEN estar encadenados por hashes y DEBEN poder verificarse con un comando publicado. - `explain(commit)` DEBE devolver la ejecución, la concesión, las decisiones de las compuertas y una referencia al manifiesto de lectura. - La retención de los registros DEBE ser independiente del borrado del contenido. ## Lo prestado y lo nuevo Lo que sigue son todo piezas establecidas. **Lo nuevo es el manifiesto de lectura:** convierte la “lectura” en un conjunto de entradas rastreable, de modo que “una fusión contaminada” y “una memoria envenenada” se puedan investigar a posteriori. - [OpenTelemetry GenAI conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/) - [Certificate Transparency](https://certificate.transparency.dev) - [Sigstore Rekor](https://docs.sigstore.dev/logging/overview/) - [Git trailers](https://git-scm.com/docs/git-interpret-trailers) ## Límites honestos - Sin anclaje externo, un administrador con root aún puede destruir el registro. - Los propios registros contienen metadatos sensibles y deben controlarse. - La granularidad del manifiesto de lectura es un equilibrio entre el coste de almacenamiento y la trazabilidad. ## Preguntas abiertas - ¿Cómo se mantiene bajo control el coste de almacenamiento de los manifiestos de lectura con un alto rendimiento? - ¿Cómo se fusionan y se verifican los registros de varios nodos? ## Preguntas ### ¿Registra el contenido que leyó el agente? Por defecto no. Un registro guarda rutas, commits, rangos y hashes de contenido: lo bastante para apuntar a los datos originales sin copiar contenido sensible a un registro. El contenido se queda en Store, protegido por concesiones y etiquetas. ### ¿Qué significa aquí “con evidencia de manipulación” (tamper-evident)? Solo prometemos que **la manipulación se puede detectar**: los registros están encadenados por hashes, así que cambiar uno rompe la verificación de la cadena; con anclaje externo (un segundo nodo o un bucket con bloqueo de objetos) también resiste a un administrador con root. Sin anclaje, un administrador aún puede destruir todo el registro. ### ¿Por qué registrar las lecturas? Porque el riesgo suele venir de leer: una sesión que leyó una página web puede escribir después una nota contaminada. El manifiesto de lectura permite responder después a “¿qué influyó en este cambio?”. ## Conceptos relacionados - [Capability Lease (concesión de capacidad)](https://agentnas.com/es/concepts/capability-lease/): Una autorización estrecha para una ejecución, con caducidad y presupuestos. Las concesiones hijas solo pueden ser más estrechas. - [Trust Labels (etiquetas de confianza)](https://agentnas.com/es/concepts/trust-labels/): Dos etiquetas pequeñas más la contaminación de sesión hacen cumplir la Rule of Two. - [Cascade Forget (olvido en cascada)](https://agentnas.com/es/concepts/cascade-forget/): Borra los derivados siguiendo el linaje, trata el historial por clase de retención e informa de lo que no pudo hacer. --- URL canónica: https://agentnas.com/es/concepts/flight-recorder/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Capability Lease (concesión de capacidad) *Una autorización estrecha para una ejecución, con caducidad y presupuestos. Las concesiones hijas solo pueden ser más estrechas.* > **Una Capability Lease** es una autorización para datos concretos y operaciones concretas, con una caducidad explícita y presupuestos. Se emite a **una ejecución** y es la única vía por la que una ejecución toca el NAS. Una concesión hija solo puede ser más estrecha que su padre. **AN-04** · Nivel de conformidad: L1 Authority · Grupo: Autoridad ## El problema RBAC y las ACL suponen usuarios estables con permisos amplios y duraderos. Un agente necesita permisos cortados a la medida de la tarea que dejan de valer cuando la tarea termina. Peor aún, las credenciales de larga duración suelen estar al alcance del agente: en el incidente de abril de 2026, el token estaba en un archivo sin relación, creado para gestionar dominios pero capaz de hacerlo todo. ## Cómo funciona - **Quién tiene la clave.** Las credenciales de larga duración se quedan con el orquestador o con el propietario; una ejecución recibe una concesión, no una clave. El modelo nunca ve una credencial de larga duración. - **Una concesión es un token de acceso.** Su `authorization_details` ([RFC 9396](https://www.rfc-editor.org/rfc/rfc9396)) describe las rutas, las acciones y la rama; la solicita el propietario o el orquestador mediante [intercambio de tokens (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693), la declaración `act` registra la cadena de delegación, y el NAS guarda estado para la revocación y el recuento de presupuestos. - **Solo estrechar.** Una concesión hija debe ser un subconjunto de su padre, y el NAS lo comprueba al emitirla. - **Presupuestos.** Bytes leídos y escritos, número de solicitudes y, opcionalmente, bytes de salida y un tope de gasto, contados en la pasarela. Son un **cortacircuitos**, no una facturación exacta. - **Sobre de políticas.** El propietario fija un rango de antemano; las concesiones dentro de él se emiten de forma automática y todo lo que queda fuera pasa a una [Human Gate](https://agentnas.com/es/concepts/human-gate/). El acceso de larga duración se expresa como un sobre, no como una concesión de larga duración. - **B y C se declaran de forma explícita.** Una concesión indica la sensibilidad más alta que puede leer y si puede escribir en árboles protegidos o enviar datos al exterior. Son entradas de las [Trust Labels](https://agentnas.com/es/concepts/trust-labels/). - **Revocación.** Un TTL corto (4 horas por defecto, 24 como máximo) más una revocación inmediata, que se propaga en cascada a las concesiones hijas. - **`purpose` se registra, no se impone:** el texto libre no lo puede comprobar una máquina. ## Empezar en pequeño - Escribe un comando `nas lease create`: para cada rol, emite un token con un prefijo de ruta, acciones y un TTL, entrégalo al sandbox en una variable de entorno y haz que el NAS imponga el prefijo y las acciones. - Esto ya detiene la primera mitad de ese tipo de incidente: el token no puede hacer nada fuera de la concesión. - Los presupuestos, las cadenas de delegación y los sobres de políticas pueden venir después. ## Esbozo de la interfaz Solo ilustrativo. Los nombres de los campos pueden cambiar antes de la especificación v0.3. *lease.json* ```json { "lease_id": "lse_7Qk3", "run": "run_91ab", "principal": "agt_cleo", "on_behalf_of": "usr_wei", "parent": null, "purpose": "Draft the Q4 release notes", "paths": ["/shared/launch/**", "/agents/cleo/workspace/**"], "actions": ["read", "write", "propose"], "branch": "cleo/run_91ab", "sensitivity_max": "private", "egress": false, "requires_gate": ["merge", "delete", "share"], "budgets": { "bytes_read": 200000000, "bytes_written": 5000000, "requests": 5000 }, "expires_at": "2026-11-12T16:00:00Z" } ``` ## Lo que pide la especificación - Una concesión DEBE tener caducidad y NO DEBE renovarse más allá del TTL máximo; la renovación exige una nueva emisión. - Una concesión hija DEBE ser un subconjunto de su padre, y el NAS DEBE verificarlo al emitirla. - Revocar una concesión DEBE propagarse en cascada a todas sus concesiones hijas. - El acceso de larga duración DEBE expresarse como un sobre de políticas y NO DEBE convertirse en una concesión de larga duración. - Una concesión DEBE declarar su techo de sensibilidad y si permite la salida de datos y las escrituras protegidas. - Las credenciales de larga duración NO DEBEN exponerse a un modelo ni a una ejecución. ## Lo prestado y lo nuevo Lo que sigue son todo piezas establecidas. **Lo nuevo:** tomar como unidad la **forma de una ejecución y una tarea** y poner la rama, los presupuestos y las propiedades de la Rule of Two en una sola concesión. Los tokens y los modelos de capacidades en sí no son nuevos. - [OAuth Token Exchange (RFC 8693)](https://www.rfc-editor.org/rfc/rfc8693) - [OAuth Rich Authorization Requests (RFC 9396)](https://www.rfc-editor.org/rfc/rfc9396) - [Biscuit](https://github.com/biscuit-auth/biscuit) - [UCAN](https://ucan.xyz/specification/) - [IETF attenuating agent tokens draft](https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/) ## Límites honestos - Solo cubre las operaciones dentro del NAS y no puede gobernar lo que hace un agente en otros sitios. - `purpose` no se puede imponer, y los presupuestos son aproximados. - Una concesión no puede evitar el uso indebido **dentro de la autoridad legítima**; de eso se encargan las ramas y las compuertas. ## Preguntas abiertas - ¿Cómo puede `purpose` pasar de texto libre a una intención estructurada que una máquina pueda comprobar? - ¿Cómo se contabilizan los presupuestos bajo federación? ## Preguntas ### ¿En qué se diferencia una concesión de una clave de API? Una clave de API es un secreto compartido de larga duración, y quien la tiene puede hacer lo que pueda hacer la cuenta. Una concesión está ligada a una ejecución, limita rutas, acciones y tiempo, y solo se puede estrechar; deja de funcionar al caducar y se puede revocar en cualquier momento. ### ¿Por qué no usar simplemente OAuth? Es OAuth: una concesión es un token de acceso, solicitado mediante intercambio de tokens (RFC 8693) y descrito con rich authorization requests (RFC 9396). Agent NAS solo añade lo que OAuth no especifica: la ejecución como unidad, y poner la rama, los presupuestos y las propiedades de la Rule of Two en una sola autorización. ### ¿Qué le pasa a una ejecución cuando caduca su concesión? El montaje pasa a solo lectura y después se desmonta; las nuevas solicitudes se rechazan y se registran. La rama se conserva hasta que caduca su propio TTL, de modo que el trabajo terminado no se pierde y todavía se puede fusionar tras la revisión. ## Conceptos relacionados - [Human Gate (compuerta humana)](https://agentnas.com/es/concepts/human-gate/): Aparece solo antes de acciones irreversibles, hacia el exterior o que elevan privilegios, y muestra el diff real. - [Trust Labels (etiquetas de confianza)](https://agentnas.com/es/concepts/trust-labels/): Dos etiquetas pequeñas más la contaminación de sesión hacen cumplir la Rule of Two. - [Flight Recorder (registrador de vuelo)](https://agentnas.com/es/concepts/flight-recorder/): Un registro por ejecución, encadenado por hashes, que incluye lo que la ejecución leyó. --- URL canónica: https://agentnas.com/es/concepts/capability-lease/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Human Gate (compuerta humana) *Aparece solo antes de acciones irreversibles, hacia el exterior o que elevan privilegios, y muestra el diff real.* > **Una Human Gate** es un punto de control activado por la política: antes de que surta efecto una acción **irreversible, hacia el exterior o que eleve privilegios**, una persona (o un aprobador designado) aprueba una acción concreta, totalmente representada. Está pensada para ser infrecuente, específica y difícil de aprobar por inercia. **AN-05** · Nivel de conformidad: L1 Authority · Grupo: Autoridad ## El problema El actual “humano en el bucle” es o un torrente interminable de avisos o nada en absoluto. Anthropic informa de que los usuarios de Claude Code aprueban entre el 93 % y el 97 % de las solicitudes de permiso; en su experimento controlado, las personas detectaron solo el 13,6 % de los comandos peligrosos introducidos a propósito, y lo hicieron peor cuanto más largas eran las sesiones. Es una investigación del proveedor para promover el modo automático, y mide la detección de avisos introducidos a propósito y no las tasas de incidentes en producción, pero la dirección es clara. Los mismos datos contienen otra cifra: los usuarios rechazan el 39 % de los planes pero solo el 3 % de las solicitudes de permiso individuales. Lo que las personas juzgan en serio son los planes y las fusiones, no cada llamada a una herramienta. ## Cómo funciona - **Aparece en pocos lugares:** fusionar en un árbol protegido, borrar de un árbol protegido, compartir o publicar hacia el exterior, enviar datos al exterior (egress), ampliar una concesión y bajar una etiqueta. Las escrituras en una rama no necesitan aprobación. - **La granularidad es un plan o una fusión.** Se revisa un PR, no cincuenta avisos. - **La Gate Card la genera el NAS:** el diff real, un resumen del manifiesto de lectura, la concesión y la contaminación de la sesión, nunca el relato del propio agente. Opciones: aprobar, aprobar acotado, denegar; si se agota el tiempo, se deniega por defecto. - **Una aprobación queda ligada al digest de la acción:** liga el hash del diff y la concesión y no se puede reutilizar. - **Entrega:** push, chat, correo o CLI; se puede delegar; las passkeys son una autenticación fuerte opcional. - **Solo escalar.** Un clasificador de riesgo opcional (incluido un LLM) solo puede **escalar** una acción a una compuerta y nunca **aprobarla**. Un modelo solo puede endurecer, nunca aflojar. - **La fatiga se mide:** tasa de aprobación y tiempo hasta aprobar; cuando la tasa de aprobación es inusualmente alta, conviene fusionar compuertas o endurecer la política. ## Empezar en pequeño - Un main protegido más revisión de PR (vale cualquier plataforma Git) y una notificación push. - O una CLI: `nas gate approve `. - Haz que la Gate Card muestre primero el “diff real”; no te apresures con interfaces vistosas. ## Esbozo de la interfaz Solo ilustrativo. Los nombres de los campos pueden cambiar antes de la especificación v0.3. *gate-card.json* ```json { "gate_id": "gt_2Mx4", "run": "run_91ab", "action": { "op": "merge", "from": "cleo/run_91ab", "into": "main", "files_changed": 4, "diff_sha256": "7d2a..." }, "why": "Release notes are ready for review", "risk": { "session_taint": ["external"], "sources": ["web:example.com/changelog"], "destructive": false, "egress": false }, "options": ["approve", "approve_narrowed", "deny"], "default": "deny", "expires_at": "2026-11-12T12:00:00Z" } ``` ## Lo que pide la especificación - Una Gate Card DEBE mostrar el diff real calculado por el NAS, no la descripción que hace el agente. - Una aprobación DEBE quedar ligada al digest de la acción y a la concesión y NO DEBE poder reutilizarse. - El resultado por defecto al agotarse el tiempo DEBE ser la denegación. - Un clasificador o un LLM NO DEBE conceder la aprobación; PUEDE escalar una acción a una compuerta. - Fusionar en un árbol protegido, borrar de un árbol protegido, compartir hacia el exterior, enviar datos al exterior, ampliar una concesión y bajar una etiqueta DEBEN pasar por una compuerta. - El NAS DEBERÍA informar de la tasa de aprobación y del tiempo hasta aprobar. ## Lo prestado y lo nuevo Lo que sigue es todo práctica establecida. **Lo nuevo:** anclar la aprobación en **la fusión en la capa de almacenamiento** y hacer que el NAS (no el agente) genere el contenido. La aprobación y los PR en sí no son nuevos. - [How we built Claude Code auto mode](https://www.anthropic.com/research/claude-code-auto-mode) - [Anthropic: approval data behind auto mode](https://claude.com/resources/articles/auto-mode-default-in-claude-code) - [CaMeL](https://arxiv.org/abs/2503.18813) - [WebAuthn](https://www.w3.org/TR/webauthn-3/) - [OpenID CIBA](https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html) ## Límites honestos - Una persona aún puede aprobar la acción equivocada; la revisión por lotes también causa fatiga. - Los canales de notificación pueden ser objeto de phishing. - Una aprobación no puede detener algo **fuera de lo aprobado**; eso es tarea de la concesión. ## Preguntas abiertas - ¿Cuál es la mejor interfaz para la revisión por lotes y por niveles? - ¿Cómo se miden y se ajustan los umbrales de la fusión automática? ## Preguntas ### ¿No es solo otro cuadro de diálogo de “confirmar”? Deliberadamente no. Un cuadro de diálogo salta en cada llamada a una herramienta y pronto la gente pulsa “aprobar”. Una compuerta aparece solo antes de unas pocas acciones irreversibles o hacia el exterior, muestra el diff real calculado por el NAS, y la aprobación liga el hash del diff: si el diff cambia, la aprobación queda anulada. ### ¿Puede un LLM decidir si dejar pasar algo? Puede sugerir que “una persona debería mirar este paso”; no puede aprobar. La decisión de dejar pasar algo debe ser una regla determinista o la aprobación de una persona. Así la seguridad no depende del criterio de ningún modelo. ### ¿Qué pasa al agotarse el tiempo? Se deniega por defecto. La ejecución recibe una negativa clara y puede tomar otro camino, o dejar la propuesta en su rama para que una persona se ocupe. ## Conceptos relacionados - [Capability Lease (concesión de capacidad)](https://agentnas.com/es/concepts/capability-lease/): Una autorización estrecha para una ejecución, con caducidad y presupuestos. Las concesiones hijas solo pueden ser más estrechas. - [Trust Labels (etiquetas de confianza)](https://agentnas.com/es/concepts/trust-labels/): Dos etiquetas pequeñas más la contaminación de sesión hacen cumplir la Rule of Two. - [Agent Branch (rama del agente)](https://agentnas.com/es/concepts/agent-branch/): Cada ejecución trabaja en una rama copy-on-write. Solo una fusión revisada llega a la línea principal. --- URL canónica: https://agentnas.com/es/concepts/human-gate/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Trust Labels (etiquetas de confianza) *Dos etiquetas pequeñas más la contaminación de sesión hacen cumplir la Rule of Two.* > **Las Trust Labels** son dos conjuntos de etiquetas muy pequeños asociados a los datos, **origen** (`owner`, `agent`, `external`) y **sensibilidad** (`public`, `private`, `secret`), más la **contaminación de sesión**. El NAS hace cumplir la Rule of Two como un invariante de sesión: una sesión no puede tener a la vez [A] ha leído contenido externo, [B] toca datos sensibles y [C] cambia un estado protegido o se comunica hacia el exterior. Completar la tercera exige una [Human Gate](https://agentnas.com/es/concepts/human-gate/). **AN-06** · Nivel de conformidad: L3 Guard · Grupo: Autoridad ## El problema La inyección de prompts funciona porque un modelo no distingue las “instrucciones” de los “datos”. Las defensas en la capa del modelo (clasificadores, endurecimiento del prompt) tienen fugas, y los atacantes pueden adaptarse. A finales de octubre de 2025, Meta propuso la [Agents Rule of Two](https://ai.meta.com/blog/practical-ai-agent-security/): hasta que la inyección esté resuelta de forma fiable, una sesión debería tener como máximo dos de tres propiedades. El enfoque más fiable es acotar las consecuencias **fuera** del modelo. El almacenamiento es justo por donde pasan todas las lecturas y escrituras, así que es un lugar natural para convertir esta regla en un invariante comprobable. ## Cómo funciona - **Etiquetas.** Tres orígenes, tres sensibilidades y una marca `reviewed` (la fija la aprobación de una compuerta). Los puntos de importación (páginas web, correo, subidas) son `external` por defecto; cuando un escáner de secretos encuentra credenciales, las etiqueta como `secret` automáticamente. - **Contaminación de sesión.** El resumen de todo lo que ha leído una ejecución (a partir del manifiesto de lectura); dentro de una sesión solo crece, y una sesión nueva empieza limpia. - **El invariante.** A = la sesión ha leído `external`; B = la concesión puede leer `private` o superior (umbral configurable); C = la concesión puede proponer una fusión en un árbol protegido, compartir, borrar o enviar datos al exterior. Cuando las tres se cumplen en una misma sesión, la llamada que activa C se deniega o se envía a una compuerta. - **En la práctica:** con una concesión que tiene tanto B como C, una vez que una sesión ha leído contenido externo, toda acción posterior de tipo C necesita a una persona. Para evitar esa fricción, haz el trabajo de “leer contenido externo” en una sesión aparte sin B y pasa los resultados solo mediante un traspaso estructurado. - **Propagación.** Las derivaciones que hace el propio NAS (índices, resúmenes) heredan de forma determinista la unión de las etiquetas de sus entradas; los archivos que escribe una ejecución heredan la contaminación de sesión de la ejecución (la opción conservadora). - **Desclasificación.** Solo mediante una Human Gate, o un **traspaso estructurado:** la salida de la sesión contaminada se restringe a campos validados por un JSON Schema (enumeraciones, ID, cadenas acotadas), y solo después de validar puede leerla una sesión con privilegios. Solo se puede confiar en lo que se puede validar de forma determinista. - **La aplicación se hace en la pasarela y en el montaje** (que conocen la concesión y la sesión), no dentro del modelo. ## Empezar en pequeño - Haz solo dos cosas: etiqueta como `external` los archivos del directorio de importación y, por defecto, no des a una ejecución que haya leído `external` ni salida de datos ni fusión protegida sin una compuerta. - Escribe la política como reglas deterministas en Cedar o Rego, y da motivos legibles al denegar. - Ejecuta en modo “solo registrar” durante una semana para ver qué bloquearía por error y luego activa la aplicación. ## Esbozo de la interfaz Solo ilustrativo. Los nombres de los campos pueden cambiar antes de la especificación v0.3. *policy.yaml* ```yaml # Deterministic policy (Cedar- or Rego-style rules can express the same thing) session_invariant: rule_of_two properties: A: session.read_origin includes "external" B: lease.sensitivity_max >= "private" C: lease allows propose_protected | share | delete | egress on_would_complete_ABC: gate # never "allow" rules: - id: r-merge-1 when: session.A and op == "merge" and target.protected then: gate - id: r-secret-1 when: session.read_sensitivity == "secret" and op == "egress" then: deny ``` ## Lo que pide la especificación - Todo punto de importación DEBE asignar una etiqueta por defecto; el contenido externo DEBE etiquetarse como `external`. - La contaminación de sesión DEBE crecer únicamente dentro de una sesión. - La evaluación de políticas DEBE ser determinista y NO DEBE llamar a un LLM. - Una llamada que permitiría a una sesión completar A+B+C DEBE denegarse o enviarse a una compuerta. - La desclasificación DEBE pasar por una compuerta o por un traspaso estructurado validado por esquema. - Los datos derivados DEBEN heredar la unión de las etiquetas de sus entradas. ## Lo prestado y lo nuevo Lo que sigue es todo pensamiento establecido. **Lo nuevo:** implementar la contaminación de sesión en la **frontera del almacenamiento** con el manifiesto de lectura, y aplicar las etiquetas a las escrituras de memoria y a los datos derivados. Mantenemos deliberadamente el retículo de etiquetas en 3×3 porque los retículos de grano fino llevan en la práctica a una explosión de etiquetas. OpenClaw ya hace etiquetas de origen y aislamiento dentro de un solo runtime; nuestra diferencia es solo ponerlo en el almacenamiento compartido. - [Agents Rule of Two (Meta)](https://ai.meta.com/blog/practical-ai-agent-security/) - [The lethal trifecta](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) - [CaMeL](https://arxiv.org/abs/2503.18813) - [Fides](https://arxiv.org/abs/2505.23643) - [Design Patterns for Securing LLM Agents against Prompt Injections](https://arxiv.org/abs/2506.08837) - [OpenClaw memory architecture](https://docs.openclaw.ai/concepts/memory-architecture) ## Límites honestos - Esto **no** es una defensa contra la inyección de prompts; limita las consecuencias. - El NAS no puede ver las herramientas que están fuera de él (un navegador, el correo), así que necesita la cooperación del runtime. - La contaminación es conservadora y trae fricción y falsos positivos; el texto libre fuera de los esquemas estructurados aún puede llevar palabras de un atacante. - Los canales encubiertos no se pueden eliminar. ## Preguntas abiertas - ¿Debe ser la granularidad de una etiqueta el archivo o el párrafo? - ¿Cómo se gobierna el vocabulario de etiquetas entre inquilinos? - ¿Cómo se pueden reducir los falsos positivos? ## Preguntas ### ¿La Rule of Two detiene la inyección de prompts? No impide que ocurra una inyección. Hace que una sesión inyectada **no pueda tener las tres** cosas: “ha leído contenido no fiable, toca datos sensibles, puede cambiar un estado protegido o enviar datos al exterior”, lo que acota las consecuencias. La propia Meta subraya que es una heurística de reducción de riesgo que no sustituye al mínimo privilegio. ### ¿Por qué solo tres orígenes y tres sensibilidades? Porque los retículos de etiquetas de grano fino tienden a hincharse y a desactivarse en la práctica. 3×3 basta para decir “quién lo escribió y cuán sensible es” y hace fácil entender el motivo de un rechazo. Las particiones más finas se pueden hacer con rutas y concesiones. ### ¿La contaminación de sesión dejará al agente sin poder hacer nada? Solo restringe tres tipos de acción: cambiar un árbol protegido, compartir o borrar, y enviar datos al exterior. Las lecturas y escrituras dentro de una rama no se ven afectadas. Para evitar la fricción, pon el trabajo de leer contenido externo en una sesión sin datos sensibles y devuelve solo resultados validados contra un esquema. ## Conceptos relacionados - [Human Gate (compuerta humana)](https://agentnas.com/es/concepts/human-gate/): Aparece solo antes de acciones irreversibles, hacia el exterior o que elevan privilegios, y muestra el diff real. - [Agent Memory (memoria del agente)](https://agentnas.com/es/concepts/agent-memory/): Las notas que puedes leer y editar son la verdad. Los índices son una caché que puedes tirar. - [Capability Lease (concesión de capacidad)](https://agentnas.com/es/concepts/capability-lease/): Una autorización estrecha para una ejecución, con caducidad y presupuestos. Las concesiones hijas solo pueden ser más estrechas. --- URL canónica: https://agentnas.com/es/concepts/trust-labels/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Agent Memory (memoria del agente) *Las notas que puedes leer y editar son la verdad. Los índices son una caché que puedes tirar.* > **Agent Memory** = **notas que puedes leer y editar** + **índices que puedes tirar en cualquier momento**. Cada nota cita sus fuentes; los índices (texto completo, vectoriales, de grafo, esquemas) son solo derivados de las notas; y las tareas de mantenimiento en segundo plano solo **proponen** ediciones y nunca reescriben el diario original. **AN-07** · Nivel de conformidad: L2 Memory · Grupo: Conocimiento ## El problema Los frameworks de memoria meten la memoria en bases de datos opacas: no se puede inspeccionar, comparar, migrar ni corregir, borrarla de forma fiable es difícil, y el índice y el modelo de embeddings quedan atados. Y la propia memoria es una superficie de ataque: en un [estudio de 2026](https://arxiv.org/abs/2606.04329), el envenenamiento de la memoria persistente alcanzó una tasa media de éxito del ataque del 50,46 % en dos agentes, y [otro estudio](https://arxiv.org/abs/2607.05189) usó un solo correo cuidadosamente elaborado para tener éxito contra los backends de memoria tanto de sistema de archivos como vectoriales. Mientras tanto, “qué arquitectura de memoria es la mejor” está lejos de estar resuelto: los benchmarks se contradicen entre sí. Un diseño que no apuesta por ningún algoritmo de recuperación concreto es el que puede sobrevivir a tres años de cambios. ## Cómo funciona - **Las notas son la verdad.** Markdown con frontmatter YAML: `kind` (episodic, semantic, procedural, preference), `subject`, `sources`, `confidence`, `valid_from`, `valid_to`, `supersedes`, `origin`, `reviewed`. - **Actualiza, no sobrescribas.** Un hecho nuevo `supersedes` al anterior; el tiempo de validez y el tiempo de registro se mantienen separados, porque los hechos cambian y los benchmarks habituales apenas lo prueban. - **Los índices son una caché.** BM25 (por ejemplo SQLite FTS5), vectores (pueden coexistir varios) y un grafo opcional; cada derivado lleva su **receta** y sus **entradas**. Cambiar el modelo de embeddings es un recálculo en segundo plano, y el índice antiguo se conserva hasta que el nuevo supere las pruebas de recuperación de referencia. - **Dos tipos de derivación.** Las deterministas (fragmentación, BM25, embeddings de un modelo fijo) son reproducibles; las generativas (resúmenes de LLM, hechos extraídos) solo se pueden “regenerar y comparar”, así que se marcan con `generated: true` y nunca sirven como única copia. - **Ruta de escritura.** `nas_remember` escribe una nota (con fuentes) en la rama actual, y la contaminación se hereda. Una nota de una sesión con contaminación `external` va a **cuarentena**, marcada como sin revisar: se puede recuperar pero **no se carga automáticamente** ni entra en `MEMORY.md`. - **Ruta de lectura.** `nas_recall` = búsqueda, candidatas, una vista con presupuesto y punteros de evidencia, y muestra la fuente y el estado de revisión de cada nota. - **Tareas de mantenimiento** (de noche o en ratos libres): deduplicar, consolidar episodios en hechos semánticos, señalar contradicciones, retirar hechos obsoletos, reconstruir índices. Las tareas generan propuestas en una rama para que las revise una persona o un agente; **nunca borran el diario original**; se mide la “tasa de arrepentimiento” (la proporción de propuestas que se revierten). - **Pruebas de recuperación de referencia (golden recall).** Para cada Home, un conjunto de pares “pregunta, nota esperada” que se ejecutan automáticamente cuando cambia el modelo o el indexador. ## Empezar en pequeño - `memory/notes/*.md` con frontmatter, y SQLite FTS5 para la búsqueda. - Ejecuta diez preguntas de referencia en CI. - Los índices vectoriales y las tareas de mantenimiento pueden venir después; acierta primero con la “procedencia” y con que “solo se cargan automáticamente las notas revisadas”. ## Esbozo de la interfaz Solo ilustrativo. Los nombres de los campos pueden cambiar antes de la especificación v0.3. *memory/notes/customer-acme.md* ```markdown --- id: mem_4kq2 kind: semantic subject: customer/acme valid_from: 2026-10-02 valid_to: null confidence: 0.8 origin: agent reviewed: true sources: - nas://home-box/agents/cleo/journal/2026-10-02.md@9f2c1de#L12-L18 supersedes: [mem_1xa9] --- Acme renewed for 24 months; the champion moved from Dana to Luis. ``` ## Lo que pide la especificación - Las notas DEBEN ser legibles sin la capa Memory (son archivos normales en Store). - Cada derivado DEBE llevar su receta y sus entradas; un índice DEBE ser desechable y reconstruible. - Las notas escritas por una sesión contaminada NO DEBEN cargarse automáticamente antes de revisarse. - Un hecho nuevo DEBE sustituir a uno antiguo con `supersedes` en lugar de sobrescribirlo. - Las tareas de mantenimiento DEBEN trabajar en una rama y solo proponer; NO DEBEN borrar el diario original. - Cada Home DEBERÍA llevar pruebas de recuperación de referencia y ejecutarlas siempre que cambie el modelo o el indexador. ## Lo prestado y lo nuevo Lo que sigue es todo pensamiento establecido, y la arquitectura de memoria de OpenClaw ya hace etiquetas de procedencia, cuarentena por niveles y propagación de la contaminación durante la consolidación. **Lo nuevo:** OpenClaw lo hace **dentro de un solo runtime**; nosotros proponemos hacerlo **en el almacenamiento compartido** para que cualquier runtime se beneficie, y degradar el índice a una caché desechable para que el algoritmo de recuperación pueda cambiar sin perder memoria. - [Letta Context Repositories](https://www.letta.com/blog/context-repositories/) - [Letta: is a filesystem all you need?](https://www.letta.com/blog/benchmarking-ai-agent-memory/) - [OpenClaw memory architecture](https://docs.openclaw.ai/concepts/memory-architecture) - [Long-term memory security survey](https://arxiv.org/abs/2604.16548) - [Graphiti](https://github.com/getzep/graphiti) - [MemGPT](https://arxiv.org/abs/2310.08560) ## Límites honestos - Los derivados generativos nunca se pueden reproducir bit a bit. - Una tarea de mantenimiento puede “endurecer” un error hasta convertirlo en un hecho, por eso solo propone y nunca edita directamente. - Qué arquitectura de memoria es la mejor sigue sin estar resuelto. ## Preguntas abiertas - ¿Cuándo debe escribir la memoria el propio agente y cuándo una tarea de mantenimiento? - ¿Cuál es el estándar de regresión entre versiones de modelos? ## Preguntas ### ¿Por qué archivos y no una base de datos vectorial? Los archivos son la verdad que puedes leer, editar, comparar y llevarte; un índice vectorial es una caché derivada que puede coexistir en varias versiones y reconstruirse en cualquier momento. El benchmark de Letta mostró que un agente con solo `grep` y herramientas de archivos es competitivo, pero los benchmarks se contradicen entre sí, así que el diseño no apuesta por un único algoritmo de recuperación. ### ¿Cómo se evita el envenenamiento de la memoria? No se puede garantizar que nunca se escriba nada malo, pero sí acotar las consecuencias: el contenido de fuera lleva la etiqueta `external`; las notas escritas por una sesión contaminada van a cuarentena y no se cargan automáticamente; las fusiones se revisan; y cuando algo sale mal puedes seguir la cadena de procedencia hasta las notas afectadas y revertir. ### ¿Tengo que migrar la memoria al cambiar el modelo de embeddings? No. Las notas no cambian; solo se recalculan los índices en segundo plano con la nueva receta, y el índice antiguo se conserva hasta que el nuevo supere las pruebas de recuperación de referencia. ## Conceptos relacionados - [Budgeted Reads (lecturas con presupuesto)](https://agentnas.com/es/concepts/budgeted-reads/): Lee un archivo como esquema, sección, rango de líneas o completo, degradando para ajustarse al presupuesto. - [Cascade Forget (olvido en cascada)](https://agentnas.com/es/concepts/cascade-forget/): Borra los derivados siguiendo el linaje, trata el historial por clase de retención e informa de lo que no pudo hacer. - [Trust Labels (etiquetas de confianza)](https://agentnas.com/es/concepts/trust-labels/): Dos etiquetas pequeñas más la contaminación de sesión hacen cumplir la Rule of Two. --- URL canónica: https://agentnas.com/es/concepts/agent-memory/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Budgeted Reads (lecturas con presupuesto) *Lee un archivo como esquema, sección, rango de líneas o completo, degradando para ajustarse al presupuesto.* > **Budgeted Reads** son lecturas medidas en un presupuesto de tokens: el mismo archivo se puede leer con distintos niveles de detalle, del esquema y la sección al rango de líneas y al texto completo. El agente pide “la mejor vista que quepa en N tokens” y recibe punteros de evidencia al origen exacto. **AN-08** · Nivel de conformidad: L2 Memory · Grupo: Conocimiento ## El problema Los agentes gastan su contexto en archivos enteros y lecturas repetidas, y la fragmentación ingenua de RAG pierde la estructura. Los modelos ya son buenos con `grep`, `tail` y la lectura por líneas: Cursor escribe en archivos las salidas de herramientas demasiado largas para que los agentes las lean bajo demanda, y en las ejecuciones que llamaron a una herramienta MCP, el [descubrimiento dinámico](https://cursor.com/blog/dynamic-context-discovery) de las descripciones de herramientas redujo el total de tokens un 46,9 %. Así que el problema no es “construir otro sistema de recuperación”, sino dar a la lectura sobre archivos un contrato **con presupuesto y comprobable**. ## Cómo funciona - **Primero los archivos.** Las lecturas estándar (incluidos los rangos de líneas) siempre están disponibles; Budgeted Reads es una extensión opcional por encima y no sustituye al sistema de archivos. - **Esquemas deterministas (gratis):** el árbol de encabezados de Markdown, los símbolos de código (tree-sitter), las claves de JSON y YAML, los encabezados y el número de filas de CSV. No hace falta ningún LLM. - **Presupuesto y degradación.** Una solicitud lleva `budget_tokens`; si no cabe, degrada a una vista más gruesa **en lugar de truncar en silencio**; la respuesta indica la vista real, el recuento de tokens y si es `generated`. - **La búsqueda devuelve fragmentos y punteros,** no archivos enteros. - **Punteros de evidencia:** `nas:////@#L12-L18`, estables y verificables contra un commit; `dereference` devuelve el contenido exacto. - **Qué ha cambiado desde la última vez:** devuelve el diff entre dos commits en lugar del archivo entero. - **Una capa opcional de resúmenes con LLM:** como caché, marcada con `generated: true` y con una marca de obsolescencia. ## Empezar en pequeño - No añadas nada más allá de `nas_read`: deja que el agente lea a la antigua usanza, con `rg` y `sed -n`. - Después añade una pequeña herramienta de esquemas para Markdown y código. - Empieza los punteros de evidencia como “path@commit#line”; no hace falta ningún servicio nuevo. ## Esbozo de la interfaz Solo ilustrativo. Los nombres de los campos pueden cambiar antes de la especificación v0.3. *POST /v1/files/read* ```http POST /v1/files/read { "path": "/agents/cleo/memory/notes/customer-acme.md", "view": "outline", "budget_tokens": 400 } 200 OK { "view": "outline", "tokens": 212, "generated": false, "truncated": false, "content": "# Acme\n## Renewal (L12-L18)\n## Contacts (L19-L31)\n## Open issues (L32-L40)", "evidence": [ { "pointer": "nas://home-box/agents/cleo/memory/notes/customer-acme.md@9f2c1de#L1-L40" } ] } ``` ## Lo que pide la especificación - Una respuesta DEBE indicar la vista realmente devuelta y su recuento de tokens; las vistas generativas DEBEN marcarse. - Cuando el presupuesto es demasiado pequeño, el NAS DEBE degradar a una vista más gruesa y NO DEBE truncar en silencio. - Las lecturas estándar de archivos (incluidos los rangos) DEBEN seguir disponibles. - Los punteros de evidencia DEBEN ser verificables contra un commit. - La búsqueda DEBE devolver por defecto fragmentos y punteros en lugar de archivos enteros. ## Lo prestado y lo nuevo La revelación progresiva y grep no son nuevos en sí mismos. **Lo nuevo:** convertir los presupuestos y los punteros de evidencia en un **contrato de lectura en la capa de almacenamiento**, de modo que las respuestas se puedan comprobar: de una frase se puede volver a las líneas del commit de donde salió. - [Cursor: dynamic context discovery](https://cursor.com/blog/dynamic-context-discovery) - [Agent Skills (progressive disclosure)](https://agentskills.io/specification) - [Letta Context Repositories](https://www.letta.com/blog/context-repositories/) - [RAPTOR](https://arxiv.org/abs/2401.18059) ## Límites honestos - Los tokenizadores difieren entre modelos, así que los recuentos de tokens son estimaciones. - Solo funciona si los clientes lo adoptan. - Los resúmenes se quedan obsoletos y pueden ser erróneos, así que solo son una caché y siempre están marcados. ## Preguntas abiertas - ¿Cómo debe tratarse el error de presupuesto entre los tokenizadores de distintos modelos? - ¿Cómo se evalúa la calidad de los resúmenes? ## Preguntas ### ¿En qué se diferencia de RAG? RAG devuelve los fragmentos más cercanos a una pregunta. Budgeted Reads deja que el lector elija el nivel de detalle de un objeto que ya conoce, degrada con honestidad cuando el presupuesto se queda corto y da punteros verificables. Se pueden combinar: los resultados de búsqueda también pueden volver como vistas con presupuesto. ### ¿Tengo que usarlo para leer archivos? No. Los montajes y Git siempre dan archivos normales; Budgeted Reads es una lectura opcional para los agentes a los que les importan los tokens. ### ¿Un puntero de evidencia puede impedir las “citas inventadas”? Hace que las citas se puedan comprobar: un puntero nombra líneas concretas de un commit y se puede verificar su hash de contenido. No impide que un modelo se invente cosas, pero convierte “¿existe realmente el pasaje que cita?” en una comprobación automática. ## Conceptos relacionados - [Agent Memory (memoria del agente)](https://agentnas.com/es/concepts/agent-memory/): Las notas que puedes leer y editar son la verdad. Los índices son una caché que puedes tirar. - [Agent Home (hogar del agente)](https://agentnas.com/es/concepts/agent-home/): Un directorio por rol, con historial. Archivos normales que puedes llevarte contigo. - [Flight Recorder (registrador de vuelo)](https://agentnas.com/es/concepts/flight-recorder/): Un registro por ejecución, encadenado por hashes, que incluye lo que la ejecución leyó. --- URL canónica: https://agentnas.com/es/concepts/budgeted-reads/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0 --- # Cascade Forget (olvido en cascada) *Borra los derivados siguiendo el linaje, trata el historial por clase de retención e informa de lo que no pudo hacer.* > **Cascade Forget** es el borrado siguiendo el linaje: cuando se borra una fuente, o alguien pide que lo olviden, el NAS encuentra todo lo derivado de ella (resúmenes, embeddings, notas que la citan, cachés y enlaces compartidos), lo borra o lo vuelve a derivar sin esa fuente, y emite un **informe**: qué se hizo y qué no se pudo hacer. **AN-09** · Nivel de conformidad: L3 Guard · Grupo: Conocimiento ## El problema Borrar un archivo no borra sus embeddings, sus resúmenes ni los hechos que la memoria dedujo de él; las instantáneas y las copias de seguridad permanecen; y el contenido sigue en el historial de versiones. “Recuperable” y “olvidable” son los dos extremos de un mismo eje, y la mayoría de los sistemas no ponen esa elección en manos de una persona. Si solo piensas en el olvido después de escribir, suele ser demasiado tarde. ## Cómo funciona - **Linaje.** Cada derivado registra sus entradas; un índice inverso responde a “todo lo que depende de X”; el campo `sources` de una nota también es linaje. - **La clase de retención se decide al escribir** (porque después no se puede reescribir el historial): `scratch` (TTL corto, fuera de las copias de seguridad, se puede limpiar cuando termina la ejecución), `normal` (versionada, recuperable) y `sensitive` (su propio dominio de claves, que se puede destruir eliminando la clave). - **La tensión entre recuperar y olvidar.** Recuperable dentro de la ventana de borrado lógico; borrado definitivo solo después; una solicitud de olvido puede saltarse la ventana. - **Proceso.** Una solicitud (la plantea una persona o un operador; un agente solo puede pedirla, no ejecutarla), recorrido del linaje, borrado de los derivados y nueva derivación de los hechos de origen mixto, reescritura del historial de las rutas afectadas y limpieza de instantáneas para la clase `normal`, destrucción de claves para la clase `sensitive` y, por último, el informe. - **El informe:** el número de archivos borrados, de derivados eliminados, si se reescribió el historial, las claves destruidas, las instantáneas que aún no han caducado y una **lista explícita de lo que no cubre:** copias fuera del NAS, registros de los proveedores de modelos y pesos de los modelos. - Siempre pasa por una [Human Gate](https://agentnas.com/es/concepts/human-gate/) (o una política de autorización previa); una **retención legal** bloquea el olvido y queda registrada. ## Empezar en pequeño - Empieza con las clases de retención y el borrado lógico, y registra las entradas de cada derivado. - Llega primero a “cuando se borra un archivo de origen, listar y borrar todos sus derivados”. - Deja la destrucción criptográfica para la clase `sensitive`; no hace falta hacerla en todas partes al principio. ## Esbozo de la interfaz Solo ilustrativo. Los nombres de los campos pueden cambiar antes de la especificación v0.3. *forget-report.json* ```json { "forget_id": "fgt_3b7c", "selector": { "paths": ["/shared/crm/acme/**"], "subject": "customer/acme" }, "retention_class": "sensitive", "report": { "files_removed": 142, "derived_removed": { "embeddings": 3621, "summaries": 210, "notes_rewritten": 6 }, "history": "rewritten (3 commits)", "keys_destroyed": ["key_acme"], "snapshots_pending": ["nightly-2026-11-10 (expires 2026-11-17)"], "not_covered": ["copies outside the NAS", "model provider logs", "model weights"] }, "state": "pending_expiry" } ``` ## Lo que pide la especificación - El olvido DEBE propagarse por el linaje desde la fuente hasta cada derivado. - La clase de retención DEBE asignarse al escribir (`normal` por defecto). - Un informe de olvido DEBE enumerar lo que no cubre: copias fuera del NAS, registros de los proveedores y pesos de los modelos. - Una retención legal DEBE bloquear el olvido y DEBE registrarse. - Un agente PUEDE solicitar el olvido pero NO DEBE ejecutarlo. - Un informe NO DEBE afirmar que un modelo ha “olvidado” algo. ## Lo prestado y lo nuevo Lo que sigue es todo ya establecido. **Lo nuevo:** tratar la **clase de retención** como una propiedad explícita del almacenamiento, y admitir que “recuperable” y “olvidable” son un compromiso en un mismo eje. - [OpenLineage](https://openlineage.io) - [GDPR Article 17](https://gdpr-info.eu/art-17-gdpr/) - [Long-term memory security survey (forget and rollback)](https://arxiv.org/abs/2604.16548) ## Límites honestos - Las copias de seguridad, las copias fuera del NAS y los registros de los proveedores de modelos quedan fuera del alcance. - Para los hechos inferidos de varias fuentes, el “alcance afectado” es difícil de definir. - Reescribir el historial es caro y conlleva riesgo. ## Preguntas abiertas - ¿Cómo se define el alcance afectado de un hecho de origen mixto? - ¿Cuál debería ser el proceso cuando una retención legal choca con una solicitud de olvido? ## Preguntas ### ¿Puede hacer que un modelo olvide? No, y no pretende afirmarlo. Lo que sí puede es borrar archivos y derivados dentro del NAS y, para la clase `sensitive`, el historial y las claves; los registros de los proveedores de modelos y los pesos de los modelos quedan fuera del alcance, y el informe lo dice de forma explícita. ### ¿Por qué elegir la clase de retención al escribir? Porque después es difícil reescribir el historial: lo que ya ha entrado en las copias de seguridad y en el historial solo se puede reescribir o esperar a que caduque. Decidir al escribir si algo es `scratch`, `normal` o `sensitive` es la condición previa para poder borrar limpiamente más tarde. ### ¿Puede un agente pedir por sí mismo que se olvide algo? Puede plantear una solicitud pero no ejecutarla. El olvido es irreversible y debe pasar por una persona o por una política de autorización previa, y una retención legal puede bloquearlo. ## Conceptos relacionados - [Agent Memory (memoria del agente)](https://agentnas.com/es/concepts/agent-memory/): Las notas que puedes leer y editar son la verdad. Los índices son una caché que puedes tirar. - [Flight Recorder (registrador de vuelo)](https://agentnas.com/es/concepts/flight-recorder/): Un registro por ejecución, encadenado por hashes, que incluye lo que la ejecución leyó. - [Agent Branch (rama del agente)](https://agentnas.com/es/concepts/agent-branch/): Cada ejecución trabaja en una rama copy-on-write. Solo una fusión revisada llega a la línea principal. --- URL canónica: https://agentnas.com/es/concepts/cascade-forget/ Actualizado: 2026-11-11 · Borrador de especificación v0.2 · CC BY 4.0