Un agente puede resumir una fuente, preparar un borrador y entregarte una buena respuesta. Eso no implica que deba tener permiso para pulsar “publicar”. El problema aparece cuando lectura, preparación y envío viven detrás de la misma herramienta o credencial: un fallo de contexto puede convertirse en un cambio real.

Vamos a construir una barrera pequeña y comprobable. El ejemplo no usa un modelo ni se conecta a SoyJB: decide, de forma determinista, si una acción queda permitida, exige revisión o se bloquea. Así puedes probar primero la regla y luego incorporarla al servidor que ejecuta tus herramientas.

El resultado que buscamos

En este escenario, posts:read puede ejecutarse, drafts:create queda para revisión y posts:publish se bloquea. Una petición al destino equivocado también se bloquea. Son cuatro comportamientos distintos; un prompt genérico de “ten cuidado” no los separa por sí solo.

La decisión se aplica en el servidor antes de que el agente alcance una acción de publicación.

Código listo para ejecutar

Crea el archivo permisos-agente.js y pega este código. Usa Node.js moderno; no necesita paquetes ni claves.

const reglas = Object.freeze({
  "posts:read": { destino: "blog", modo: "permitir" },
  "drafts:create": { destino: "blog", modo: "revisar" },
  "posts:publish": { destino: "blog", modo: "bloquear" }
});

function decidir({ accion, destino }) {
  const regla = Object.hasOwn(reglas, accion) ? reglas[accion] : null;
  if (!regla || regla.destino !== destino) {
    return { estado: "bloquear", motivo: "Fuera de alcance" };
  }
  return { estado: regla.modo };
}

const casos = [
  { accion: "posts:read", destino: "blog" },
  { accion: "drafts:create", destino: "blog" },
  { accion: "posts:publish", destino: "blog" },
  { accion: "posts:read", destino: "otro-servicio" }
];

for (const caso of casos) {
  console.log(caso.accion, caso.destino, decidir(caso));
}

En la terminal ejecuta node permisos-agente.js. Debes ver, en orden, permitir, revisar, bloquear y bloquear. El cuarto caso demuestra que una acción válida no sirve para cualquier destino. Aquí “revisar” solo devuelve una decisión: el ejemplo no crea un borrador ni publica nada.

Cómo conectarlo a una herramienta de verdad

1. Define acciones precisas. Evita una herramienta llamada manage_posts que haga de todo. Separar lectura, borrador y publicación simplifica los permisos.
2. Ejecuta decidir en tu backend. Antes de llamar al CMS, comprueba la acción solicitada y el destino. El modelo puede proponer una acción, pero no modificar la tabla de reglas.
3. Trata “revisar” como una pausa. Muestra título, contenido y destino exacto a una persona con permisos. La confirmación debe venir de una sesión confiable del producto, no de un texto generado por el agente.
4. Registra el resultado real. Guarda quién solicitó la acción, qué regla se aplicó, el ID del recurso y si el CMS confirmó el cambio. Omite contraseñas y tokens en el registro.

Una buena prueba de integración es esta: el agente solicita posts:publish, el backend lo rechaza y el registro del CMS sigue sin fecha de publicación. Si el agente responde “publicado” pese a ese estado, tienes dos fallos que corregir: la interpretación del resultado y la barrera de ejecución.

Tres fallos que esta demo todavía no resuelve

La tabla en memoria no sustituye un sistema completo de permisos. Primero, una etiqueta como blog debe vincularse en el servidor a destinos reales y concretos; de lo contrario podría apuntar a otro servicio. Segundo, varias acciones pequeñas aparentemente inocuas pueden combinarse para producir un efecto no deseado. Tercero, si el agente consigue ejecutar código fuera de este control, la función no lo detendrá. En producción, limita credenciales y herramientas además de validar peticiones.

El motivo para probarlo está documentado: Anthropic publicó casos en los que Claude, al encontrar bloqueos o instrucciones ambiguas, tomó rutas que los operadores no pretendían. Lee el informe de incidentes y, para medir agentes por su estado final en vez de su respuesta, su guía de evaluaciones.

Prueba siguiente: cambia una regla a propósito, vuelve a correr los cuatro casos y añade uno donde falte destino. Si tu aplicación no puede explicar por qué bloqueó una operación, todavía le falta observabilidad para darle más autonomía al agente.