Bedrock protege el prompt, no siempre la herramienta: cómo cerrar el hueco

Para proteger las herramientas de un agente con Amazon Bedrock Guardrails y Strands Agents SDK, hay que controlar tres fronteras: la entrada antes de procesarla, los parámetros antes de ejecutar la herramienta y el resultado antes de devolverlo al agente. Un guardrail asociado solo a la inferencia protege el intercambio con el modelo, pero no inspecciona automáticamente cada llamada a servicios externos.

La arquitectura combina BeforeInvocationEvent, BeforeToolCallEvent y AfterToolCallEvent con ApplyGuardrail y validaciones deterministas. Guardrails clasifica y filtra contenido; los esquemas, las reglas de negocio y los permisos de AWS deciden si la operación es válida y está autorizada.

El límite del modelo no cubre toda la herramienta

La documentación de usos de Bedrock Guardrails delimita por separado su aplicación a la inferencia, los agentes, las bases de conocimiento y determinados nodos de flujos. En un agente de Amazon Bedrock, el guardrail asociado evalúa los prompts enviados al agente y las respuestas que este devuelve; esa cobertura no implica que valide por sí misma todos los argumentos y resultados de una herramienta usada por otro entorno de agentes.

La diferencia importa porque la llamada puede producir efectos fuera del modelo. Un argumento sintácticamente correcto todavía puede incluir un identificador perteneciente a otro cliente, un destino no permitido o una cantidad superior al límite de negocio. Del mismo modo, una API, un servidor MCP o una búsqueda web puede devolver datos sensibles o instrucciones hostiles que no deberían incorporarse al contexto.

Guardrails tampoco sustituye la autorización. Que un texto supere el filtro de contenido no demuestra que el usuario pueda consultar ese recurso, modificar la infraestructura o enviar un mensaje en nombre de otra identidad.

Inserta tres controles en el ciclo de Strands

El patrón publicado por AWS Security registra tres callbacks en un HookProvider: BeforeInvocationEvent revisa la entrada, BeforeToolCallEvent examina los parámetros y puede cancelar la llamada, y AfterToolCallEvent inspecciona el resultado y puede reemplazarlo por un error controlado. Los hooks se añaden al agente sin modificar la implementación interna de cada herramienta.

1. BeforeInvocationEvent: localiza el mensaje entrante relevante y evalúa sus bloques textuales. Si infringe la política, elimina el contenido rechazado del recorrido y devuelve un estado estable; el texto original no debe llegar al modelo ni provocar una herramienta.
2. BeforeToolCallEvent: identifica la herramienta, valida primero el objeto de entrada y somete después el contenido textual pertinente al guardrail. Si falla cualquiera de los controles, asigna la cancelación al evento antes de que comience la operación externa.
3. AfterToolCallEvent: extrae los bloques textuales del resultado y evalúalos como salida. Ante una intervención, reemplaza el resultado original por un estado de error seguro para que el agente no razone sobre el contenido bloqueado.

La política puede variar por herramienta. Una búsqueda que consume páginas externas necesita especial atención en la salida; una función que consulta clientes exige comprobar identidad y pertenencia del recurso antes de ejecutarse. El filtro por nombre de herramienta debe ser una lista permitida explícita: una herramienta nueva no debería quedar fuera de control por omisión.

Combina ApplyGuardrail con validación estructural

La guía oficial de ApplyGuardrail indica que la API evalúa texto sin invocar un modelo fundacional, distingue contenido INPUT y OUTPUT y devuelve una acción que permite saber si hubo intervención. Esto permite reutilizar una función común desde los tres hooks, con el identificador, la versión y la región del guardrail configurados de forma centralizada.

Antes de serializar parámetros, conserva su estructura y valídala contra un esquema estricto: campos obligatorios, tipos, longitudes, formatos, enumeraciones y rechazo de propiedades adicionales. Recorre también listas y objetos anidados; el ejemplo básico que examina solo cadenas del primer nivel no cubre un valor peligroso oculto dentro de una estructura más profunda.

El orden reduce ambigüedades: rechaza primero la forma inválida, después comprueba identidad, pertenencia del recurso y límites de negocio, y por último aplica el análisis de contenido. Para acciones sensibles, añade destinos permitidos o aprobación humana. Un resultado de Guardrails nunca debe elevar permisos ni convertir una operación prohibida en autorizada.

Define asimismo el comportamiento ante errores y tiempos de espera de ApplyGuardrail. Las herramientas que escriben datos, envían mensajes o cambian infraestructura deberían fallar de forma cerrada. Una consulta de bajo riesgo puede admitir una degradación prevista, pero la decisión debe ser explícita, observable y distinta de una autorización normal.

Reduce permisos y registra decisiones

La identidad que ejecuta el hook necesita las acciones de Bedrock estrictamente requeridas, incluida bedrock:ApplyGuardrail, mientras cada herramienta debe operar con credenciales limitadas por recurso, acción y entorno. Cancelar una llamada desde el hook añade una barrera, pero no reemplaza el recorte de permisos heredados antes de conceder capacidad de ejecución.

Registra un identificador de correlación, la herramienta, el punto de control, la versión del guardrail, la decisión, un motivo normalizado y la duración. Evita almacenar por defecto prompts, argumentos y resultados completos: los registros de seguridad no deberían crear una copia adicional de secretos o datos personales.

Distingue una intervención de política, un esquema inválido, una denegación de autorización y un fallo del servicio. Con códigos separados es posible detectar una indisponibilidad sin confundirla con un aumento legítimo de solicitudes bloqueadas.

Prueba que la acción bloqueada no ocurrió

Una prueba negativa debe demostrar la ausencia del efecto externo, no solo la aparición de un mensaje. Sustituye las herramientas con escritura por dobles de prueba y verifica que registran cero invocaciones cuando BeforeToolCallEvent cancela los parámetros. Para AfterToolCallEvent, comprueba que el resultado original no aparece en el historial ni en la siguiente entrada del modelo.

• Una entrada prohibida no debe exponer su contenido original al modelo ni activar herramientas.
• Un valor textual prohibido dentro de un objeto anidado debe cancelar la llamada.
• Un identificador válido pero ajeno al usuario debe fallar en la autorización aunque Guardrails no intervenga.
• Un resultado externo con datos sensibles o instrucciones hostiles debe sustituirse antes de volver al agente.
• Un error o tiempo de espera de ApplyGuardrail debe seguir la política definida para el riesgo de la herramienta.
• Una solicitud permitida debe completar el recorrido sin alterar parámetros ni resultados válidos.

La cobertura queda completa cuando toda herramienta incluida en el alcance pasa por el control previo, ningún resultado relevante vuelve al contexto sin evaluación y los permisos mínimos limitan el efecto de un fallo en la lógica del agente.

Lee también:

• Tu agente de código hereda tus permisos: cómo recortarlos antes de ejecutar
• Cómo aislar agentes de IA sin falsear una prueba de ciberseguridad
• Tu idea gusta, pero nadie paga: cómo validarla antes de construir