robots.txt le dice a Google qué páginas rastrear. llms.txt le dice a los LLMs quién eres. Pero ninguno de los dos responde una pregunta que se vuelve más urgente cada mes: ¿qué puede hacer un agente de IA en tu sitio?
No hablo de crawlers que leen contenido. Hablo de agentes autónomos que navegan, hacen click, llenan formularios, extraen datos y ejecutan acciones. El tipo de agente que OpenAI lanzó con Operator, que Google está construyendo con Gemini, y que Anthropic está explorando con Claude. Agentes que no solo leen tu web sino que la usan.
En enero de 2026, un grupo de trabajo publicó una propuesta en GitHub: agent-permissions.json. Un archivo JSON que vive en tu dominio y declara, de forma granular, qué interacciones están permitidas, cuáles requieren aprobación humana, y cuáles están prohibidas. Es el equivalente de robots.txt pero para una web donde las máquinas no solo leen sino que actúan.
Lo implementé en este blog. Aquí está todo lo que hice y por qué.
Qué es agent-permissions.json y cómo funciona
agent-permissions.json es un manifiesto en formato JSON que un sitio web coloca en su dominio para declarar reglas de interacción para agentes automatizados. La ubicación por defecto es /.well-known/agent-permissions.json, aunque también se puede referenciar con un link tag en el HTML.
El archivo tiene dos secciones principales. La primera es resource_rules: reglas granulares que definen qué acciones están permitidas en qué elementos del sitio. La segunda es action_guidelines: directrices de alto nivel que se alimentan al LLM del agente para guiar su comportamiento.
Las acciones definidas en la especificación incluyen read_content (leer el contenido de la página), read_metadata (leer meta tags, JSON-LD, OpenGraph), follow_link (navegar links), click_element (hacer click en botones o controles), set_input_value (llenar campos de formulario), submit_form (enviar formularios), execute_script (ejecutar JavaScript), y copy_to_clipboard (copiar contenido).
Cada acción puede tener un efecto de allow, deny, o ask (requiere aprobación humana). También admite modificadores como rate_limit, burst, time_window, y human_in_the_loop.
El archivo que implementé en shinobis.com
Mi blog es un sitio de contenido. No tiene formularios de login, no tiene carrito de compras, no tiene API pública. Las decisiones de permisos reflejan eso.
{
"metadata": {
"schema_version": "0.1.0",
"last_updated": "2026-07-01",
"site": "https://shinobis.com",
"contact": "admin@shinobis.com"
},
"strict": false,
"resource_rules": [
{
"pattern": "/**",
"actions": {
"read_content": { "effect": "allow" },
"read_metadata": { "effect": "allow" },
"follow_link": { "effect": "allow" },
"click_element": { "effect": "deny" },
"set_input_value": { "effect": "deny" },
"submit_form": { "effect": "deny" },
"execute_script": { "effect": "deny" },
"copy_to_clipboard": { "effect": "allow" }
}
},
{
"pattern": "/tools/**",
"actions": {
"click_element": { "effect": "allow" },
"set_input_value": { "effect": "allow" }
}
}
],
"action_guidelines": [
"Cite content with attribution to shinobis.com when using it in responses.",
"Do not use content for model training without explicit permission.",
"Tools in /tools/ are free to use. Interact with form elements as needed.",
"Do not attempt to access /admin.php or any administrative endpoints."
]
}Las decisiones que tomé y por qué
Puse strict en false. Esto significa que si un agente no reconoce el formato, puede seguir su comportamiento por defecto. Un blog de contenido no necesita bloquear agentes que no entienden el archivo. Lo contrario sería un e-commerce o un sitio bancario donde strict: true tendría sentido.
Permití read_content, read_metadata y follow_link globalmente. Quiero que los agentes lean mi contenido, extraigan mi JSON-LD, y naveguen entre mis posts. Esa es exactamente la visibilidad que busco con Generative Engine Optimization.
Prohibí click_element, set_input_value, submit_form y execute_script globalmente. Un agente no tiene razón para hacer click en botones de mi blog ni ejecutar JavaScript en mi dominio. No hay funcionalidad que requiera eso fuera de la sección de herramientas.
Creé una excepción para /tools/**. Mi generador de llms.txt y el GEO Tarot son herramientas interactivas. Un agente debería poder llenar el campo de URL en el generador y obtener el resultado. Por eso las acciones de click e input están permitidas específicamente en esa ruta.
Las action_guidelines son el puente entre las reglas técnicas y la intención humana. Un agente con un LLM puede leer estas directrices y entender el contexto. No solo sabe qué puede hacer técnicamente sino qué espera el dueño del sitio.
La configuración de Apache
El archivo necesita ser servido con el content type correcto y ser accesible públicamente. En mi .htaccess agregué:
# Agent permissions
RewriteRule ^\.well-known/agent-permissions\.json$ - [L]
<Files "agent-permissions.json">
Require all granted
Header set Content-Type "application/json; charset=utf-8"
Header set Cache-Control "public, max-age=86400"
</Files>El cache de 24 horas es intencional. Los agentes no necesitan verificar permisos en cada request. Una vez al día es suficiente para un archivo que cambia raramente.
Cómo se conecta con lo que ya tengo
Este archivo no existe en aislamiento. Es la tercera capa de un sistema que llevo meses construyendo.
La primera capa es llms.txt: le dice a los LLMs quién soy y qué contenido importa. La segunda capa es el stack de agentes: Content Signals, Markdown for Agents, Agent Skills discovery. La tercera capa es agent-permissions.json: declara las reglas de interacción.
Juntas, estas tres capas le dicen a cualquier agente de IA: quién soy (llms.txt), cómo leer mi contenido de forma eficiente (Markdown negotiation), qué herramientas tengo disponibles (Agent Skills), y qué puede y no puede hacer en mi sitio (agent-permissions.json).
Ningún blog que conozca tiene las cuatro capas implementadas. La mayoría no tiene ninguna.
Por qué esto importa más de lo que parece
La especificación aún es un draft. No hay ningún agente comercial que la implemente oficialmente. Pero la dirección es clara. Cloudflare lanzó su test de Agent Readiness. OpenAI tiene Operator navegando la web. Google está construyendo agentes que interactúan con sitios. La pregunta no es si los agentes van a necesitar permisos explícitos sino cuándo.
Implementarlo ahora tiene el mismo costo-beneficio que tuvo implementar llms.txt hace seis meses. Un archivo, menos de una hora de trabajo, cero riesgo. Y si el estándar se adopta, ya estás listo.
Lo peor que puede pasar es que no haga nada. Lo mejor es que cuando los agentes empiecen a respetar estos manifiestos, tu sitio ya tenga uno bien construido con reglas claras.
La especificación completa está en el repositorio del grupo de trabajo: LAS-WG/agent-permissions.json.
