Autorización de comandos en conversaciones vinculadas a ACP (Propuesta)

Estado: Propuesto, aún no implementado.

Este documento describe un modelo de autorización a largo plazo para comandos nativos en conversaciones vinculadas a ACP. Es una propuesta experimental y no reemplaza el comportamiento actual en producción.

Para el comportamiento implementado, consulta el código fuente y los tests en:

  • src/telegram/bot-native-commands.ts
  • src/discord/monitor/native-command.ts
  • src/auto-reply/reply/commands-core.ts

Problema

Actualmente tenemos verificaciones específicas por comando (por ejemplo /new y /reset) que necesitan funcionar dentro de canales/temas vinculados a ACP incluso cuando las listas de permitidos están vacías. Esto resuelve el problema inmediato de UX, pero las excepciones basadas en nombres de comandos no escalan.

Forma a largo plazo

Mover la autorización de comandos de lógica ad-hoc en los manejadores a metadatos de comandos más un evaluador de políticas compartido.

1) Agregar metadatos de política de autenticación a las definiciones de comandos

Cada definición de comando debería declarar una política de autenticación. Forma de ejemplo:

type CommandAuthPolicy =
  | { mode: "owner_or_allowlist" } // por defecto, comportamiento estricto actual
  | { mode: "bound_acp_or_owner_or_allowlist" } // permitir en conversaciones ACP vinculadas explícitamente
  | { mode: "owner_only" };

/new y /reset usarían bound_acp_or_owner_or_allowlist. La mayoría de los otros comandos seguirían con owner_or_allowlist.

2) Compartir un solo evaluador entre canales

Introducir un helper que evalúe la autorización de comandos usando:

  • Metadatos de política del comando
  • Estado de autorización del remitente
  • Estado de vinculación de la conversación resuelta

Tanto los manejadores nativos de Telegram como de Discord deberían llamar al mismo helper para evitar divergencias de comportamiento.

3) Usar la coincidencia de vinculación como límite de bypass

Cuando la política permite bypass de ACP vinculado, autorizar solo si se resolvió una coincidencia de vinculación configurada para la conversación actual (no solo porque la clave de sesión actual parece de tipo ACP).

Esto mantiene el límite explícito y minimiza la ampliación accidental.

Por qué esto es mejor

  • Escala a futuros comandos sin agregar más condicionales por nombre de comando.
  • Mantiene el comportamiento consistente entre canales.
  • Preserva el modelo de seguridad actual al requerir coincidencia de vinculación explícita.
  • Mantiene las listas de permitidos como endurecimiento opcional en lugar de un requisito universal.

Plan de despliegue (futuro)

  1. Agregar campo de política de autenticación a los tipos del registro de comandos y datos de comandos.
  2. Implementar evaluador compartido y migrar los manejadores nativos de Telegram + Discord.
  3. Mover /new y /reset a política basada en metadatos.
  4. Agregar tests por modo de política y superficie de canal.

No objetivos

  • Esta propuesta no cambia el comportamiento del ciclo de vida de sesiones ACP.
  • Esta propuesta no requiere listas de permitidos para todos los comandos vinculados a ACP.
  • Esta propuesta no cambia la semántica de vinculación de rutas existente.

Nota

Esta propuesta es intencionalmente aditiva y no elimina ni reemplaza los documentos experimentales existentes.

Siguiente
Overview
arrow_forward