Farolero — give an AI agent a vague instruction and later nobody can say what it was allowed to do.
The permission, the spending limit and a readable record of what the agent actually did. Evidence: 13/13 tests. Fictional data; the agent's effects are local and reversible.
Part of Vespi's HackMeridian 2026 submission, as evidence of what Vespi and Lore Plugin let a person build.
For judges: How it works · Evidence · Limits · Review-only license.
The source is in this repository: run npm test on Node 24.
Run it / Córrelo
git clone https://github.com/andresanemic/farolero.git
cd farolero
npm test
npm run recorridoNode 24. npm test runs the suite; npm run recorrido replays the walkthrough. / Node 24. npm test ejecuta la suite; npm run recorrido repite el recorrido.
These projects remain separate, runnable repositories. / Estos proyectos siguen siendo repositorios ejecutables por separado.
Read in English
Kernel re-pin, 26 Oct 2026. This project now vendors Vespi kernel 0.1.8 (release
v0.1.8-kernel, commit13dbe24). Suite: 13 of 13 pass indocs/suite-2026-10-26.txt. Mentions of 0.1.6 below describe the 2026-10-11 capture.
Farolero is designed to make an AI agent’s permission something a person can inspect.
The unit is a bounded permission: who may do what, to which subject, for which operation, until when, within what budget, and toward which destination.
An organization may know that an agent is helping, yet still struggle to answer the questions that matter after an action: who authorized it, what exactly was allowed, and did the agent stay within that boundary? When the answer lives in a prompt, a card, or a chat, the explanation is easy to lose and hard to check from outside the conversation.
Farolero starts from that practical gap. A responsible person grants a specific permission. The agent may pass on only a narrower subset. A request that falls outside the permission returns as blocked, with a reason and a named next step for a person. That turns a vague instruction into a boundary the project can test and record.
Imagine a fictional archive that asks an agent to add a line to a local project record. A responsible person grants permission for that subject, operation, time window, budget, and destination. The agent may ask a second registered agent to do part of the work, but that delegated permission must fit inside the first one. If the second agent tries to write to a different destination, Farolero blocks the request and sends the reason back to a person. If the request fits, the described effect is one local, reversible file write. A separate verifier rereads the store and recomputes the receipt. The example uses fictional data and explains the agreed path; it is not a captured run or a real institution’s workflow.
The case below is fictional. It follows the agreement’s rules rather than pretending to show output from the program. The repository contains no captured output for the walkthrough command, so the only terminal-style excerpts here are exact test names and statuses from the recorded suite capture.
Suppose a fictional community archive wants an agent called Scribe to add one entry to a local record. The person granting authority fixes the subject, operation, end time, budget, and destination. A second fictional agent, Index, can receive a smaller permission. The request to add the entry at the named local destination fits; a request to send it to another destination does not. That second request comes back blocked with a reason and a next step for the person, rather than being silently redirected.
Fictional case, not program output
Subject the fictional archive record
Operation add one entry
Time the period named in the permission
Budget the limit named in the permission
Destination the local project record
Delegation a subset of Scribe’s permission only
The captured suite confirms that these boundaries are among the checks:
✔ sin permiso, la ejecución queda bloqueada y vuelve a la persona con la salida
✔ un delegado no puede recibir más de lo que su delegante tiene
✔ con el mismo permiso y otro destino, el bloqueo nombra los dos destinos
✔ el presupuesto es un límite duro y se acumula entre ejecuciones
The names and marks above are copied from the captured test output. The example record is invented for explanation; it is not supplied project data or an actual execution.
| You need | What it gives you | Where it lives |
|---|---|---|
| To know who may do what | A permission tied to a subject, operation, clock, budget, and destination | How it works |
| To delegate without expanding authority | A child permission that must remain a subset of its parent | How it works |
| To see what happens when a request does not fit | A blocked return with a reason and a named human next step | How it works |
| To check a record independently | A verifier that rereads the local store and recomputes the receipt | How it works |
| To distinguish a design rule from current evidence | Named test results, the kernel pin context, and their limits | Evidence |
Person grants a bounded permission
|
v
Registered agent acts within its limits
|
+---- delegate receives a subset only
|
v
Check subject, operation, time, budget, and destination
| fits | does not fit
v v
Local reversible effect Blocked return to a person
| with reason and next step
v
Receipt enters the local store
|
v
Separate verifier rereads the store and recomputes the receipt
| Actor | Rights | Limits |
|---|---|---|
| Granting person | Grant, delegate, pause, and revoke permission | The only authority for those actions in this project run |
| Permitted agent | Act within its granted permission | Cannot exceed its subject, operation, time, budget, or destination |
| Delegate | Receive and exercise a narrower permission | Cannot receive or pass on more than its delegator has |
| Verifier | Recheck the local effect and recompute the receipt from the store | Separate from execution; does not establish external truth |
| Named destination | Receive the effect described by the permission | A named destination, not an integrated institution in this run |
The receipt records what was requested, which permission applied or why it did not, what effect was made, who acted, what the verifier checked, and a content digest. The verifier reads the store again instead of treating the executor’s report as proof. See the full walkthrough and rules.
Farolero is not a passive directory, an identity system, a configuration dashboard, or a legal compliance product. In this project run it is not connected to an institution, network, blockchain, payment service, or testnet. Its described effect is a local and reversible file write.
The captured suite dated 2026-10-11 reports 13 tests: 13 pass, none unsuccessful, none skipped, under Node v24.15.0. It covers permission boundaries, delegation, expiry, pausing authority, blocked returns, receipt tampering, verification, repeated effects, budget limits, and a readable local record. The 2026-10-03 capture was red because the project was pinned to an older kernel cut (0.1.3); that pin update to 0.1.6 (commit 39d4573) is now recorded and checked module by module in docs/suite-2026-10-11.txt.
The adversarial phase wrote eight project RED cases before code and observed each one stay red. The available sources do not map those original cases one by one to the current test names. These are project checks, not an external audit. Read Evidence for the names, phase record, and rerun instructions.
Vespi supplies the kernel Farolero consumes. Farolero does not change that kernel. This project uses its granted-authority model, kernel receipts, a human gate when an action is outside permission, verification separate from execution, and continuity based on receipts. Lore Plugin is part of the project foundation; Farolero’s agreement and publication boundary remain its own.
What this relationship means. The project was built with Lore Plugin's method (its agreement and criterion live in the project, in acuerdo.md and lore/), and its operations, authority and receipts run on the Vespi kernel 0.1.8, in the pinned copy of the v0.1.8-kernel release (vendor/vespi-kernel, commit 13dbe24). That copy sits in the project as vendor/vespi-kernel and the suite verifies it against its SOURCE.md. Lore Plugin does not run inside the project. This project does not use the kernel's newer capabilities (Stellar pubnet anchors, live x402 settlement, the ZK verifier, emergency access); it exercises the core of operations, authority and receipts.
Review status: this project has not been audited. The Vespi kernel it runs on has had superreviews with Claude Code and no independent external security audit.
All sample agents and records are fictional. The current run has no real personal, health, financial, or third-party data, and no external effect. The materials do not establish legal identity, the truth of an input, anyone’s legal authority, legal admissibility, legal compliance, institutional adoption, or readiness for production or use. The cited Chilean Law 21.719 is problem context in the agreement; its primary text was not reviewed for this run, and the implementation was not checked against it. No legal professional reviewed these materials. More detail is in Legal and limits.
Start with How it works for the agreement translated into the operating model. Then open Evidence for the captured suite and its limits, and Legal and limits for the boundary of the claims. The source is in this repository: run npm test on Node 24 from the project root. The review-only license permits reading and cloning for evaluation, not modifying the code.
Repository authority: Andrés Peña (andresanemic on GitHub).
How it works · Evidence · Legal and limits · Review-only license · Vespi · Lore Plugin
Leer en español
Nueva fijación del kernel, 26 oct. 2026. Este proyecto ahora vendoriza el kernel de Vespi 0.1.8 (release
v0.1.8-kernel, commit13dbe24). Suite: 13 de 13 aprobadas endocs/suite-2026-10-26.txt. Las menciones a 0.1.6 más abajo describen la captura del 2026-10-11.
Farolero es un proyecto para volver visible la autoridad de un agente de IA antes de que actúe.
La unidad es un permiso acotado: quién puede hacer qué, respecto de qué sujeto, para qué operación, hasta cuándo, con qué presupuesto y hacia qué destino.
Una organización puede saber que un agente la está ayudando y, aun así, tener dificultades para responder las preguntas que importan después de una acción: quién la autorizó, qué estaba permitido exactamente y si el agente se mantuvo dentro de ese límite. Cuando la respuesta vive en un prompt, una ficha o un chat, es fácil perder la explicación y difícil comprobarla desde fuera de la conversación.
Farolero parte de esa brecha práctica. El acuerdo define cómo una persona responsable concede un permiso concreto, cómo el agente puede transmitir solo un subconjunto más estrecho y cómo una solicitud fuera del límite debe volver bloqueada, con una razón y un siguiente paso nombrado para una persona. Así, una instrucción vaga se convierte en un límite que el proyecto puede probar y registrar.
- Lee la base del proyecto y su recorrido. Empieza por Cómo funciona.
- Abre el registro de pruebas. Consulta Evidencia.
- Lee los límites jurídicos y de verificación. Consulta Marco legal y límites.
- Lee los términos en la licencia de solo revisión y ejecuta
npm test(Node 24).
Imagina un archivo comunitario ficticio que pide a un agente añadir una línea a un registro local del proyecto. Una persona responsable concede permiso para ese sujeto, operación, plazo, presupuesto y destino. El agente puede encargar parte del trabajo a un segundo agente registrado, pero ese permiso delegado debe caber dentro del primero. Si el segundo agente intenta escribir en otro destino, Farolero bloquea la solicitud y devuelve la razón a una persona. Si la solicitud cabe, el efecto descrito es escribir una línea local y reversible en un archivo. Un verificador aparte vuelve a leer el almacén y recalcula el recibo. El ejemplo usa datos de fantasía y explica el recorrido acordado; no es una corrida capturada ni el flujo de una institución real.
El caso siguiente es de fantasía. Sigue las reglas del acuerdo, no pretende mostrar la salida del programa. La captura pública no contiene la salida del comando de recorrido; por eso, los únicos extractos con aspecto de terminal aquí son nombres y estados exactos de pruebas de la captura suministrada.
Supongamos que un archivo comunitario ficticio quiere que un agente llamado Escriba añada una entrada a un registro local. La persona que otorga autoridad fija el sujeto, la operación, el vencimiento, el presupuesto y el destino. Un segundo agente ficticio, Índice, puede recibir un permiso más acotado. La solicitud de añadir una entrada al destino local nombrado cabe; una solicitud para enviarla a otro destino no. Esa segunda solicitud vuelve bloqueada, con una razón y un siguiente paso para la persona, en vez de redirigirse en silencio.
Caso de fantasía, no es salida del programa
Sujeto el registro del archivo ficticio
Operación añadir una entrada
Plazo el periodo indicado en el permiso
Presupuesto el límite indicado en el permiso
Destino el registro local del proyecto
Delegación solo un subconjunto del permiso de Escriba
La suite capturada confirma que estos límites están entre las comprobaciones:
✔ sin permiso, la ejecución queda bloqueada y vuelve a la persona con la salida
✔ un delegado no puede recibir más de lo que su delegante tiene
✔ con el mismo permiso y otro destino, el bloqueo nombra los dos destinos
✔ el presupuesto es un límite duro y se acumula entre ejecuciones
Los nombres y marcas anteriores se copian de la salida capturada de pruebas. El registro de ejemplo es inventado para explicar el caso; no proviene de los datos suministrados ni de una ejecución real.
| Necesitas | Qué te da | Dónde vive |
|---|---|---|
| Saber quién puede hacer qué | Un permiso ligado a sujeto, operación, reloj, presupuesto y destino | Cómo funciona |
| Delegar sin ampliar la autoridad | Un permiso derivado que debe seguir dentro del permiso de origen | Cómo funciona |
| Ver qué ocurre cuando una solicitud no cabe | Una devolución bloqueada con razón y siguiente paso para una persona | Cómo funciona |
| Comprobar un registro por separado | Un verificador que relee el almacén local y recalcula el recibo | Cómo funciona |
| Distinguir una regla de diseño de la evidencia actual | Resultados de pruebas con nombre, contexto del pin del kernel y sus límites | Evidencia |
La persona concede un permiso acotado
|
v
El agente registrado actúa dentro de sus límites
|
+---- el delegado recibe solo un subconjunto
|
v
Comprobación de sujeto, operación, plazo, presupuesto y destino
| cabe | no cabe
v v
Efecto local y reversible Devolución bloqueada a una persona
| con razón y siguiente paso
v
El recibo entra al almacén local
|
v
Un verificador aparte relee el almacén y recalcula el recibo
| Actor | Derechos | Límites |
|---|---|---|
| Persona que otorga | Conceder, delegar, pausar y revocar permisos | Única autoridad para esas acciones en este recorrido del proyecto |
| Agente con permiso | Actuar dentro del permiso concedido | No puede exceder sujeto, operación, plazo, presupuesto ni destino |
| Delegado | Recibir y ejercer un permiso más acotado | No puede recibir ni transmitir más de lo que tiene quien delega |
| Verificador | Volver a comprobar el efecto local y recalcular el recibo desde el almacén | Está separado de la ejecución y no establece una verdad externa |
| Destino nombrado | Recibir el efecto descrito por el permiso | Es un destino nombrado, no una institución integrada en este recorrido |
El recibo registra qué se pidió, qué permiso aplicó o por qué no, qué efecto se hizo, quién actuó, qué comprobó el verificador y un digest del contenido. El verificador vuelve a leer el almacén en vez de tratar el informe del ejecutor como prueba. Consulta el recorrido completo y sus reglas.
Farolero no es un directorio pasivo, un sistema de identidad, un panel de configuración ni un producto de cumplimiento legal. En este recorrido del proyecto no se conecta con una institución, red, blockchain, servicio de pagos ni testnet. El efecto descrito es escribir un archivo local y reversible.
La suite capturada el 2026-10-11 informa 13 pruebas: 13 pasan, ninguna sin pasar, ninguna omitida, con Node v24.15.0. Cubre límites de permisos, delegación, vencimiento, autoridad para pausar, devoluciones bloqueadas, manipulación de recibos, verificación, efectos repetidos, presupuesto y un registro local legible. La captura del 2026-10-03 quedó en rojo porque el proyecto estaba fijado a un corte viejo del kernel (0.1.3); esa actualización del pin a 0.1.6 (commit 39d4573) ya está registrada y comprobada módulo por módulo en docs/suite-2026-10-11.txt.
La fase adversarial escribió ocho casos RED del proyecto antes del código y observó fallar cada uno. Las fuentes disponibles no relacionan esos casos originales uno por uno con los nombres actuales de pruebas. Son comprobaciones del proyecto, no una auditoría externa. Consulta Evidencia para ver los nombres, el registro de fases y cómo repetirlas.
Vespi aporta el kernel que consume Farolero. Farolero no modifica ese kernel. Este proyecto usa su modelo de autoridad otorgada, los recibos del kernel, una compuerta humana si una acción queda fuera del permiso, la verificación separada de la ejecución y la continuidad basada en recibos. Lore Plugin forma parte de los cimientos del proyecto; el acuerdo y los límites de publicación de Farolero son propios.
Qué significa esta relación. El proyecto se construyó con el método de Lore Plugin (su acuerdo y su criterio viven en el proyecto, en acuerdo.md y lore/), y sus operaciones, autoridad y recibos corren sobre el kernel de Vespi 0.1.8, en la copia fijada del release v0.1.8-kernel (vendor/vespi-kernel, commit 13dbe24). Esa copia está en el proyecto como vendor/vespi-kernel y la suite la verifica contra su SOURCE.md. Lore Plugin no corre dentro del proyecto. Este proyecto no usa las capacidades nuevas del kernel (anclas Stellar pubnet, liquidación x402 en vivo, el verificador ZK, el acceso de emergencia); ejerce el núcleo de operaciones, autoridad y recibos.
Estado de revisión: este proyecto no ha sido auditado. El kernel de Vespi sobre el que corre ha tenido superreviews con Claude Code y ninguna auditoría de seguridad externa independiente.
Todos los agentes y registros de ejemplo son ficticios. El recorrido actual no usa datos personales, de salud, financieros ni de terceros reales, y no produce efectos externos. Los materiales no establecen identidad legal, verdad de una entrada, autoridad jurídica de una persona, admisibilidad jurídica, cumplimiento legal, adopción institucional ni preparación para producción o uso. El acuerdo cita la Ley 21.719 de Chile como contexto del problema; en este recorrido no se revisó su texto primario ni se comprobó la implementación frente a ella. Ningún profesional del derecho revisó estos materiales. Hay más detalle en Marco legal y límites.
Empieza por Cómo funciona, donde el acuerdo se expresa como modelo operativo. Después abre Evidencia para consultar la suite capturada y sus límites, y Marco legal y límites para conocer la frontera de las afirmaciones. El código está en este repositorio: ejecuta npm test con Node 24 desde la raíz del proyecto. La licencia de solo revisión permite leer y clonar para evaluar, no modificar el código.
Autoridad del repositorio: Andrés Peña (andresanemic en GitHub).
Cómo funciona · Evidencia · Marco legal y límites · Licencia de solo revisión · Vespi · Lore Plugin