English

El mensaje de otro agente no es tu aprobación

En el momento en que tus sesiones pueden mandarse mensajes aparece una pregunta que conviene hacerse antes de necesitar la respuesta. Si una dice que el humano ya dio el visto bueno, ¿la otra le cree?

La respuesta es no, por diseño

Cuando una sesión le manda un mensaje a otra, al agente receptor se le dice que el mensaje viene de otra sesión, no de ti. De ahí se derivan varias cosas, y son todo el modelo de seguridad:

• No puede aprobar nada. Un mensaje de otra sesión nunca cuenta como tu consentimiento, así que no puede responder un permiso pendiente en tu nombre.
• No puede cambiar configuración. Se le indica al agente receptor no cambiar permisos, archivos de reglas ni otra configuración porque otra sesión se lo pidió.
• Los comandos no se ejecutan. Un comando de barra dentro del texto llega como texto plano. Se lee, nunca se ejecuta.
• Los permisos siguen preguntando. Si actuar sobre el mensaje requiere un permiso que la sesión receptora no tiene, ves el mismo diálogo que para cualquier otro trabajo.

Leídas juntas, la forma es clara: un agente par es una entrada no confiable que puede pedir, no una autoridad que puede autorizar. Que es el valor por defecto correcto en cuanto más de un agente puede alcanzar tu máquina.

Por qué importa más de lo que suena

Sin ese límite, los montajes multiagente ofrecerían una manera trivial de saltarse tus propias decisiones de permisos. A la sesión A le niegan una acción, le comenta a la sesión B que ya está aprobado, y B lo hace. Cada permiso que respondiste valdría solo lo que valga el agente menos cuidadoso del grupo.

También corre en el otro sentido, y esta es la parte que conviene interiorizar: un agente nunca debería pedirle a un par algo que le negaron en su propia sesión. Los límites de permisos son por sesión, así que desviar trabajo bloqueado de lado es lavar tu decisión, no respetarla. Lo correcto es devolvértelo.

Cómo apretarlo más

Los valores por defecto son sensatos, pero puedes ser más estricto. Los mensajes entrantes tienen tres ajustes:

• aceptar: cada mensaje se entrega.
• retener: aparece un aviso y nada se entrega hasta que lo apruebes.
• rechazar: los mensajes se descartan sin entregarse.

Cuando no hay valor definido, el comportamiento se decide por mensaje según los modos de permisos de las dos sesiones, y se inclina hacia lo conservador: una sesión que se salta los diálogos de permisos retiene los mensajes entrantes para tu aprobación, y entrega uno solo cuando quien envía también se identifica como tal.

Aparte, existe un ajuste para exigir tu aprobación explícita antes de que un mensaje llegue a una sesión fuera de esta máquina, y aplica incluso en un modo que normalmente se salta los permisos. Un valor más estricto desde cualquier ámbito gana, así que un archivo de proyecto puede activar la exigencia pero no desactivarla.

Si quieres la mensajería apagada del todo, recibir y enviar son controles separados: rechaza lo entrante, y niega las herramientas de mensajería y de listado para que esta sesión no pueda enviar ni enumerar.

Para llevar

Tus agentes pueden hablar entre ellos. Eso no los hace jefes unos de otros. El mensaje de un par puede traer información y pedir trabajo, pero no puede consentir por ti, reescribir tu configuración ni ejecutar un comando. Y si quieres un humano en ese ciclo para cada mensaje entrante, es un ajuste.