Un agente que resume una cuenta es una función de producto. Un agente que modifica facturación, cierra tickets, exporta informes o desactiva usuarios es un operador privilegiado. El backend debe tratarlo como tal.
El camino más corto también es el peor modelo de seguridad: dejar que el agente herede una cookie humana o credencial amplia y llame las mismas APIs internas del panel. Eso mezcla autoridad del usuario, identidad del agente, límite del tenant, intención y aprobación en un único bearer secret.
El agente debe ser un principal de primera clase. Cada acción debe conservar quién delegó y qué agente actuó, junto con tenant, objeto, operación, límites, expiración y contexto. OAuth Token Exchange aporta semántica de delegación y actor; Rich Authorization Requests permite expresar detalles estructurados y finos más allá de scopes genéricos.
El modelo puede interpretar intención y proponer un plan. No debe ser la autoridad final para decidir si una etapa está permitida. Convierte la propuesta en operaciones tipadas como draft_reply, issue_credit, disable_user o export_report. Valida schemas, resuelve IDs en servidor y pasa cada etapa por autorización y política conscientes del tenant.
Las herramientas deben exponer comandos de negocio estrechos, no acceso bruto a base de datos ni una función de “llamar cualquier API”. Prompt injection puede influir una propuesta, pero no debe fabricar permiso. OWASP describe excessive agency y riesgos agentic porque herramientas poderosas, permisos amplios y autonomía ambigua se multiplican.
Un diálogo que dice “¿Permitir que el agente gestione facturación?” no es aprobación útil. El revisor necesita ver factura, cliente, importe, motivo, efectos y datos que saldrán del tenant. La aprobación debe vincularse a un digest inmutable del plan y expirar si cambian el plan, los objetivos o el estado relevante.
Los niveles de riesgo hacen utilizable la interfaz. Resúmenes read-only y drafts pueden ejecutarse automáticamente. Mensajes, campos de bajo impacto o informes programados pueden usar límites de política. Reembolsos, créditos, suspensión, exportaciones, cambios de rol y acciones destructivas requieren aprobación fuerte, step-up authentication o varias personas.
| Clase de acción | Ejemplo | Autonomía predeterminada | Controles necesarios |
|---|---|---|---|
| Observar | Resumir historial de cuenta o analizar tendencias de soporte. | Automática dentro del permiso de lectura existente. | Filtro por tenant, redacción sensible, enlaces fuente y retrieval trazable. |
| Redactar | Preparar respuesta, informe o nota de factura. | Draft automático, sin efecto externo. | Marcar contenido generado, conservar fuentes y exigir envío o publicación explícitos. |
| Mutación rutinaria | Actualizar etiqueta, asignar ticket o programar informe existente. | Controlada por política dentro de campos y volumen limitados. | Autorización de objeto, clave idempotente, rate limit, verificación y undo. |
| Comunicación externa | Enviar email a cliente o payload de webhook. | Aprobación, salvo template y política de destinatario estrechos. | Preview de contenido y destinos; bloquear destinatarios ocultos y fuga sensible. |
| Cambio financiero o de acceso | Emitir crédito, cambiar plan, suspender usuario o modificar rol. | Aprobación step-up explícita; a veces control por dos personas. | Límites de importe y rol, segregación, token vinculado al plan y evidencia inmutable. |
| Acción destructiva o masiva | Eliminar datos, cerrar cuentas en lote o exportar todo el tenant. | Nunca totalmente autónoma por defecto. | Dry run, conteo de impacto, demora, quorum, ventana de cancelación y recuperación. |
Las acciones administrativas esperan aprobaciones, APIs externas, pagos, generación de informes, webhooks o respuestas humanas. Un workflow duradero conserva historial entre fallos, pero las actividades externas todavía necesitan claves idempotentes y verificación de poscondiciones. Un reintento no puede emitir otro reembolso ni reenviar el mismo mensaje.
Las llamadas al modelo y herramientas deben considerar replay. Persiste decisiones y resultados externos como eventos del workflow en vez de regenerarlos durante recuperación. Versiona workflows para que una tarea en curso no cambie de significado cuando se desplieguen prompts, políticas o schemas.
Una pista útil conecta solicitud, versiones de agente y modelo, contexto recuperado, plan, política, aprobación, credencial delegada, llamadas, resultados, poscondiciones, overrides y compensación. Context propagation de OpenTelemetry enlaza la interacción con policy engine, workflow y servicios; el ledger conserva evidencia de negocio que los traces pueden muestrear o redactar.
No registres prompts crudos, tokens ni datos sensibles por defecto. Guarda referencias estructuradas, hashes, versiones de política, entradas saneadas y evidencia con acceso controlado. Los auditores necesitan reconstruir sin crear otra superficie de fuga.
Construiría un gateway de operaciones de agentes entre el modelo y cada API mutable del SaaS. Ofrecería comandos tipados, autorización por tenant, políticas, dry-run, vinculación de aprobación, credenciales por tarea, idempotencia, ejecución duradera, verificación y ledger de evidencia.
El panel separaría trabajo propuesto de trabajo en ejecución. Los operadores verían alcance, riesgo, dependencias, aprobación, etapa actual, evidencia, cancelación y compensación sin leer transcripciones del modelo.
El agente puede decidir cómo proponer una solución; la plataforma decide qué autoridad existe. Haz estrecha la delegación, concreta la aprobación, duradera la ejecución, conscientes del resultado los reintentos y reconstruible cada acción relevante.
Artículo sobre integración segura de agentes de IA en paneles SaaS mediante autorización delegada, aprobaciones vinculadas al plan, workflows duraderos, idempotencia, verificación y auditoría.