¿Qué es un token de capacidad y cómo limita a un agente de IA doméstico?
Un token de capacidad otorga autoridad basada en la posesión sobre un recurso y una operación específicos, limitando a un agente al negarle todas las capacidades que no se le hayan concedido.
Un agente doméstico puede necesitar leer un calendario, encender las luces de una habitación o cargar una copia de seguridad concreta sin recibir credenciales permanentes de administrador. Un token de capacidad puede vincular recurso, acción, caducidad, presupuesto y contexto en una concesión verificable. La puerta de enlace de herramientas comprueba esa concesión en cada llamada, por lo que el texto de la instrucción por sí solo no puede ampliar la autoridad del agente.
El token combina una referencia a un objeto con autoridad
Una capacidad nombra o resuelve un objeto protegido y transmite las operaciones permitidas a quien lo posee legítimamente. A diferencia de una clave de API amplia seguida de una consulta interna a una ACL, la propia concesión es deliberadamente limitada e imposible de falsificar.
La investigación sobre capacidades de objetos describe el modelo de capacidades de objetos como la codificación de derechos de acceso en objetos individuales para restringir las interacciones. Los descriptores de archivos son un ejemplo local conocido: autorizan el acceso a un objeto ya abierto sin conceder autoridad para nombrar arbitrariamente elementos del sistema de archivos.
Una capacidad puede coexistir con la identidad y la política. La identidad responde a quién participa; la capacidad responde a qué autoridad concreta se delegó para esta operación. Esta distinción sigue siendo visible durante las pruebas domésticas posteriores.
La atenuación limita la delegación sin ampliarla
Un servicio principal puede derivar un token secundario restringido a una ruta más pequeña, un método de solo lectura, una caducidad más breve, un presupuesto menor o un contexto de solicitud concreto. El token secundario puede delegar menos autoridad, pero no puede eliminar restricciones ni acuñar derechos más amplios.
Los macarons introducen una autorización atenuada que admite restricciones contextuales y delegación descentralizada. La verificación comprueba la cadena de firmas y cada restricción antes de que el servidor de recursos acepte una solicitud. El resultado intermedio debe seguir siendo inspeccionable antes de que la automatización continúe.
Esto resulta útil para los agentes porque un planificador puede recibir una capacidad de sesión y pasar una derivada específica de la tarea a un subproceso de una herramienta. El subproceso nunca necesita la credencial raíz en su instrucción ni en su entorno. Ese límite debe medirse por separado en condiciones operativas realistas.
La posesión, la delegación y la revocación siguen siendo límites de seguridad
Cualquiera que robe una capacidad de portador puede utilizarla hasta que caduque o sea revocada. Los tokens necesitan transporte y almacenamiento protegidos, vinculación a una audiencia o canal cuando corresponda, vidas útiles breves e identificadores de auditoría. La consecuencia práctica aparece cuando varias fuentes compiten por un contexto limitado.
Un análisis de la seguridad basada en capacidades explica la distinción entre la autoridad de capacidad y los controles centrados en la identidad. El modelo reduce la autoridad ambiental, pero no determina si la acción solicitada por un agente refleja la verdadera intención del usuario. Esta dependencia debe mantenerse explícita en la interfaz final.
El límite de fallo es un token demasiado amplio, reutilizable o filtrado. Las comprobaciones de capacidades no pueden impedir un uso dañino que esté incluido en la concesión, por lo que las acciones con consecuencias aún necesitan validación del objetivo, aprobación, límites de frecuencia y revocación observable. Por tanto, el resultado debe comprobarse frente a las pruebas originales.
Inventaría la autoridad por token, herramienta y solicitud
Para cada llamada a una herramienta, registra el emisor, el sujeto o poseedor, la audiencia, el recurso, la operación, el alcance de la ruta, el presupuesto, la caducidad, la cadena de delegación, las restricciones, el identificador de revocación, el requisito de aprobación y el ID de auditoría. Esta distinción sigue siendo visible durante las pruebas domésticas posteriores.
Compara la concesión con la seguridad basada en capacidades. Prueba el recorrido de rutas, el cambio del ID del dispositivo, la sustitución del método, la reproducción, el token caducado, el token secundario robado, el verificador sin conexión, el principal revocado y una solicitud permitida pero de gran impacto. El resultado intermedio debe seguir siendo inspeccionable antes de que la automatización continúe.
Continúa solo cuando cada herramienta reciba la concesión mínima y no pueda ampliarla. Considera el éxito de la capacidad como una autorización, no como una prueba de la intención del usuario, de la seguridad semántica ni de que el resultado de la herramienta sea correcto. Ese límite debe medirse por separado en condiciones operativas realistas.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Puede un LLM local reanudar la generación después de que se reinicie su proceso?
Una explicación de la reanudación de la generación de LLM desde el mecanismo, sus concesiones en recursos compartidos, tres preguntas frecuentes sobre la ramificación...
¿Puede un servidor doméstico ejecutar embeddings y transcodificación de vídeo en la misma GPU integrada?
Una explicación centrada en el mecanismo de las representaciones vectoriales compartidas de la iGPU y la transcodificación, sus ventajas y desventajas en cuanto a...
¿Cómo afecta la duración de los tokens de acceso a la seguridad y las molestias en el hogar?
Una explicación centrada en el mecanismo sobre la duración de los tokens de acceso, sus ventajas y desventajas respecto a los recursos compartidos, tres...
