Caso de uso
Puerta de riesgo para llamadas a herramientas
Puntúa una llamada a herramienta propuesta por un agente antes de que toque datos de producción.
El problema
Los agentes inventan SQL y borrados de archivos que parecen plausibles y son catastróficos.
Qué hace tu código con la respuesta
Bloquea o pide confirmación para cualquier llamada cuyo score de riesgo esté por encima de tu umbral.
Leer la respuesta del guardarrail
Tres señales en una llamada: needs_confirmation y matches_intent como probabilidades sí/no, y risk como un score a lo largo de Inofensivo → Recuperable → Pérdida de datos irreversible. El ejemplo de arriba es deliberadamente feo — una petición de «limpia staging» cuya llamada a herramienta tira una tabla de producción. El risk puntúa hacia arriba y la coincidencia de intención cae por debajo de la confianza, que es lo que tu wrapper convierte en bloquear-y-registrar.
Dónde va la puerta en tu bucle
Llama a la puerta exactamente una vez, después de que el agente proponga una llamada y antes de la ejecución. Pasa la petición original del usuario y la llamada propuesta como estado — no hace falta nada más. Mantén las líneas de política en código (bloquear con score ≥ 1,5 o intención por debajo de 0,8; confirmar en medio), y pon puerta solo a las herramientas cuyo radio de blast justifique un viaje de ida y vuelta de 400–600 ms: SQL, sistema de archivos, deploys, correo. Las llamadas de solo lectura pueden pasar sin puerta.
Riesgos propios de las puertas de herramientas
Nunca le mandes a la puerta solo la llamada a herramienta: sin la petición original del usuario, la coincidencia de intención no tiene nada con qué comparar y se colapsa en una puerta de solo score de destrucción. No pongas puerta a todas las herramientas el primer día — empieza con las pocas cuyos fallos son cuando mucho recuperables, y revísalo a medida que los umbrales se estabilicen. Por último: trata un timeout en esta llamada como «preguntar a un humano», no «proceder y cruzar los dedos».
La forma de la solicitud
Esta es la solicitud completa que el playground envía para este preset — el mismo JSON que tu servidor envía a /v1/systemone con una clave Bearer.
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": {
"user_request": "Clean up the old test data in the staging database.",
"proposed_tool_call": {
"tool": "sql.execute",
"args": {
"query": "DROP TABLE customers;"
},
"environment": "production"
}
},
"questions": {
"needs_confirmation": {
"type": "noul",
"instructions": "Should a human confirm this tool call before it runs?"
},
"matches_intent": {
"type": "noul",
"instructions": "Does `proposed_tool_call` match what `user_request` asked for?"
},
"risk": {
"type": "score",
"instructions": "How destructive is this action if it is wrong?",
"criteria": [
"Harmless",
"Recoverable",
"Irreversible data loss"
]
}
}
}'Preguntas frecuentes sobre este caso de uso
- ¿La puerta ralentiza cada llamada a herramienta?
- Solo a las que le envíes. La mayoría de los equipos pone puerta a las escrituras y deja pasar las lecturas; los viajes de ida y vuelta se agrupan en 400–600 ms en mediciones reales, así que a las lecturas de menos de 100 ms no les apetece pagarla.
- ¿Puede el modelo ver toda mi base de código?
- No — solo ve el estado que envíes. Incluye el entorno (staging vs producción) y la intención del solicitante; esos dos datos deciden la mayoría de las puertas.
- ¿Basta una probabilidad para fiarse?
- Ningún número suelto basta en una acción irreversible. Por eso el preset envuelve tres preguntas — coincidencia de intención, confirmación humana y score de destrucción — cada una con un umbral distinto en tu política.