Pruebas de denegación antes de conectar un agente IA a SAP

Un intento exitoso de consultar el stock muestra que la conexión funciona, pero no garantiza que sea segura para el siguiente usuario, planta o entorno de producción.

Para una integración SAP MCP, conviene que los casos de denegación formen parte de los criterios de aceptación antes de ampliar el catálogo de herramientas. Se trata de una lista de comprobación de diseño, no de una declaración de que un despliegue concreto ha pasado todas las pruebas.

Pasos recomendados

1. Define una pregunta empresarial limitada. Por ejemplo, un usuario de compras solicita órdenes abiertas dentro de su ámbito organizacional permitido.
2. Usa datos sintéticos y un entorno descartable.
3. Registra el principal esperado, el entorno objetivo, el alcance organizacional autorizado y los campos antes de ejecutar la solicitud.
4. Modifica una condición a la vez: cambia la solicitud, la política o el sistema objetivo.
5. Verifica el comportamiento esperado.
6. Inspecciona los datos de la solicitud fuera del alcance del usuario y deniega la petición o constrúyela dentro del alcance autorizado bajo una política explícita.
7. Revisa la decisión de la política y los registros devueltos.
8. Repite el proceso cambiando el sistema objetivo fuera de la lista blanca, rechazando antes de contactar.
9. Comprueba los eventos de denegación y la ausencia de llamadas posteriores.
10. Reutiliza una sesión caducada, rechaza la autenticación y valida el resultado.
11. Llama a una operación oculta del catálogo del usuario directamente y fuerza la autorización nuevamente.
12. Asegura que la decisión del servidor sea la única que autoriza o niega cada llamada.
13. Añade pruebas de escritura solo cuando el caso de uso lo requiera; una prueba de solo lectura no necesita acción persistente.
14. Si las escrituras son reales, separa la recuperación de contexto, la preparación del borrador y la ejecución.
15. Verifica que una modificación del borrador después de la aprobación invalide la aprobación anterior, así como los casos de aprobación ausente, caducada o perteneciente a otra operación.
16. Crea un caso propio para los timeouts; el cliente puede perder la respuesta después de que SAP acepte la acción.
17. Al reconectar, usa el mecanismo de prevención de duplicados de la aplicación y el resultado comercial.

Es crucial diferenciar entre una interfaz cómoda y una frontera impuesta. Ocultar una operación de la detección reduce errores, pero no autoriza ni deniega la invocación directa; esa decisión debe quedar en el servidor para cada llamada.

En cuanto a la autorización, la especificación MCP no reemplaza los roles SAP, objetos de autorización o comprobaciones de aplicación. Cuando sea posible, ejecuta en el contexto del usuario real; si se necesita una identidad técnica, limita tanto esa identidad como la política de la aplicación.

Para cada prueba permitida, inspecciona el principal realmente utilizado en SAP; para cada prueba denegada, identifica dónde ocurrió la decisión. Una denegación en la capa de aplicación y otra en SAP pueden ser evidencia útil, pero explican controles diferentes.

El registro de aceptación debe incluir el caso de prueba, el resultado esperado, el resultado real y una referencia de trazabilidad. Generalmente no necesita el prompt completo, las credenciales o una copia del documento comercial devuelto. Registra los resultados de permitir, denegar y errores con suficiente contexto para reconstruir la decisión. Revisa la enmascaración y retención como parte de la prueba; de lo contrario, la evidencia misma puede convertirse en un almacenamiento innecesario de datos sensibles.

La pregunta práctica de la liberación es: ¿puede el equipo demostrar una denegación correcta tan claramente como una respuesta exitosa? Para una arquitectura más amplia, consulta la guía NeKuDos sobre diseño de SAP MCP con conciencia de permisos.

La especificación MCP de autorización describe la capa de acceso cliente-servidor; la frontera de permisos de SAP todavía necesita su propio diseño y verificación.