Seguridad de webhooks: valida cada petición

Tu webhook es el punto exacto donde termina el razonamiento del modelo y empieza tu código ejecutando algo real. Tratarlo como confiable porque «lo llamó el agente» es el error de seguridad más común al conectar Powers: el agente propone, pero la petición que le llega a tu servidor debe validarse como cualquier entrada pública.

El agente no es tu perímetro de seguridad

El modelo decide cuándo llamar a un Power y arma los parámetros a partir de la conversación, pero no impone ningún control de acceso sobre lo que tu endpoint hace con esos datos. Si tu backend confía en que un campo viene bien formado solo porque lo puso el agente, estás delegando seguridad a un sistema que nunca la tuvo como responsabilidad.

Tres controles que no deberían faltar

• Autentica cada petición con la cabecera que configuraste en el Power, y rechaza cualquier llamada que no la traiga o la traiga mal.
• Valida el tipo y el formato de cada parámetro en tu endpoint, exactamente como validarías un formulario público.
• Aplica límites de monto, frecuencia o alcance en tu propio código para las acciones que mutan estado, no solo en la descripción del Power.

Un Power de lectura y uno de escritura no cargan el mismo riesgo

Consultar el estado de un pedido y cancelarlo no deberían tratarse con la misma cautela. Separa explícitamente las acciones de solo lectura de las que cambian algo real, y reserva controles más estrictos —confirmación explícita, límites, registro detallado— para las segundas. Un error en un Power de consulta produce una respuesta incorrecta; un error en uno que mute estado produce un daño real.

Qué hacer si sospechas que una URL se filtró

Si la URL de un webhook —la que lleva el secreto embebido, como en Slack o Telegram— se expone accidentalmente en un log, un repositorio o el cliente, rota la integración del lado del proveedor y actualiza el Power con la nueva URL de inmediato. No hay forma de invalidar solo el acceso filtrado: hay que reemplazar el secreto completo.