Dinos cómo podemos ayudarte
Ventas y precios
Habla con un representante sobre las necesidades de tu empresa
Ayuda y soporte
Consulta nuestras opciones de soporte de productos
Consultas generales y ubicaciones
Contáctanos
Guardabarreras de ejecución para agentes de IA
Implementando barreras de seguridad de agentes de IA para la IA de producción
El problema no son las decisiones de los agentes. Es el acceso del agente a la ejecución.
Esto no va de hacer que los agentes sean más seguros en el sentido habitual.
El riesgo de agentes de IA tiene dos capas:
- Riesgo de decisión: ¿El agente eligió la acción correcta?
- Riesgo de ejecución: ¿Se permitió al agente ejecutarlo?
Esta guía se centra en el riesgo de ejecución. No se trata de ingeniería de prompts, alineación de modelos o filtrado de salida. Esos controles importan, pero los incidentes operativos más graves comienzan cuando se le está permitido ejecutar una acción que no debería haberse ejecutado.
Una vez que un agente puede activar flujos de trabajo, iniciar trabajos, modificar sistemas u orquestar procesos posteriores, la pregunta te debe plantearse están: "¿Qué se puede ejecutar, bajo qué condiciones y dónde están aplicado ese control?"
En el momento en que un agente de IA puede actuar, el acceso se convierte en un problema de control de ejecución. Ahí es donde entran en juego los límites de la ejecución.
Resumen rápido: Las decisiones del agente Crean la intención. El acceso de agentes genera exposición. El control de ejecución determina qué se puede ejecutar.
Dónde deben estar las barreras de seguridad de la ejecución (delante de la ejecución)
Los resguardos de ejecución son controles que determinan si la acción solicitada por un agente de IA está permitida para ejecutarse en producción. Antes de que se ejecute cualquier cosa, esos controles comprueban la identidad, el alcance, las aprobaciones, las dependencias, el tiempo y la política operativa a lo largo de un flujo de trabajo, trabajo, paso impulsado por API o cambio de sistema.
Estos controles pertenecen entre la intención y la ejecución del agente, no dentro del propio agente. No determinan qué decide el agente solicitar. Ellos determinan qué se puede correr. En la práctica, eso significa enrutar la ejecución iniciada por el agente a través de un plano de control, el punto centralizado donde las solicitudes de ejecución son evaluadas en relación con la política antes de que comience el trabajo aguas abajo.
Sin un punto de aplicación consistente, los sistemas aguas abajo son obligados a aplicar sus propias reglas, o no tener reglas, lo que genera oportunidades para acciones no autorizadas, aprobaciones inconsistentes y deriva de políticas.
Pero antes de que un sistema pueda evaluar una solicitud de ejecución, primero debe responder a una pregunta básica: ¿Quién, o qué, está haciendo la solicitud?
Cómo un agente de IA obtiene autorización para ejecutar cualquier cosa
El control de ejecución comienza con la identidad. Sin una identidad clara, controlada y atribuible, las solicitudes de un agente no pueden evaluarse según la política, vincularse a permisos aprobados ni rastrearse a través del historial de ejecución.
Una de las formas más rápidas de debilitar el control de ejecución están confiando en credenciales compartidas. Cuando varios agentes utilizan las mismas cuentas, claves API o identidades de servicio, es difícil determinar quién inició una acción, qué permisos se pretendían y si el acceso estaba correctamente alcanzado.
Para autorizar la ejecución dirigida por agentes de forma segura, la identidad y los permisos deben estar regulados, atribuibles y restringidos.
- Las solicitudes de ejecución deben utilizar identidades de servicio controladas y auditables
Las acciones impulsadas por agentes deben realizarse a través de identidades de servicio aprobadas en lugar de credenciales compartidas o cuentas humanas. - Los permisos deben estar restringidos a trabajos aprobados específicos
El acceso debe limitarse a trabajos, flujos de trabajo, servicios y entornos autorizados según roles y políticas definidos. - Cada solicitud debe ser atribuible
Las solicitudes de ejecución deben ser rastreables hasta una identidad específica y un conjunto de permisos para autorización, auditoría y visibilidad operativa. - Los derechos de ejecución deberían provenir de la política de orquestación y el RBAC
Lo que un agente puede ejecutar debe determinarse mediante políticas de orquestación aprobadas y controles de acceso basados en roles, no heredados implícitamente del código de la aplicación. - ASe deben evitar rutas de ejecución no anónimas o compartidas
La ejecución no debería depender de credenciales genéricas que Haz difíciles de establecer límites de propiedad, responsabilidad o acceso.
Cómo se ve esto en producción
Los agentes envían solicitudes de ejecución a través de un plano de control utilizando identidades y permisos aprobados. El acceso está limitado a flujos de trabajo y servicios autorizados, y las solicitudes de ejecución se evalúan en son las políticas establecidas antes de que el trabajo continúe.
Como resultado, las acciones siguen siendo atribuibles, el acceso se mantiene dentro de los límites definidos y la gobernanza de ejecución puede aplicarse de forma consistente.
Resumen rápido: la identidad controla el acceso a las rutas de ejecución. Ningún agente debe ejecutar nada sin una identidad distinta, permisos aprobados y control de ejecución basado en políticas.
Cómo interceptar a un agente de IA antes de que ejecute nada
La identidad te dice quién hace la petición. La intercepción convierte esa autorización en aplicación.
En producción, los agentes deben enviar solicitudes de ejecución a través de una interfaz controlada—por ejemplo, una interfaz basada en MCP como el Control-M MCP Server—en lugar de llamar directamente a scripts, trabajos o APIs operativas.
Esa interfaz enruta las solicitudes de cargas de trabajo orquestadas al plano de control, donde pueden evaluarse según la política antes de que avance el trabajo aprobado. Esto es diferente a intentar gobernar todas las APIs arbitrarias a las que un agente pueda acceder. El objetivo es interceptar y controlar las rutas de ejecución que más importan: los flujos de trabajo, los trabajos y los procesos operativos posteriores que se enrutan a través del plano de control.
Prácticamente, la aplicación de la ley es así:
- El agente planea una acción
- El agente genera una solicitud de ejecución
- La solicitud se están envía a través de una interfaz controlada
- El plano de control intercepta la solicitud y evalúa políticas como identidad, alcance, aprobación, temporización y requisitos previos
- El plano de control permite, pausa o niega la ejecución
- Los sistemas autorizados ejecutan el trabajo aprobado
- Registro de sistemas y resultados de retorno
Cada solicitud de ejecución controlada debe seguir este camino, permitiendo que las políticas se apliquen de forma consistente en lugar de depender de herramientas, flujos de trabajo o aplicaciones individuales para aplicar sus propios controles de forma independiente.
Resumen rápido: La intercepción solo funciona cuando la ejecución iniciada por el agente están enrutada a través de un plano de control común. Cuantos más caminos de ejecución salten ese plano de control, más difícil se vuelve la aplicación consistente.
8 Límites de ejecución: lo que debe hacerse cumplir
La intercepción es el punto de control. Las ocho barreras de seguridad que aparecen a continuación Define qué debe evaluarse antes de que una acción pueda ejecutarse. Si alguna de ellas está desaparecida, los agentes pueden encontrar una forma de eludir políticas, aprobaciones o salvaguardas operativas.
| Guardrail | Question | What to Control | Why it Matters |
|---|---|---|---|
|
Identity |
Who's executing this? |
Governed execution identities, scoped permissions, and no anonymous execution |
Each action can be tied back to a specific identity and permission set |
|
Scope |
What's the agent allowed to touch? |
Approved jobs, workflows, environments, and executable assets |
Agents stay within defined boundaries instead of drifting into unintended systems or workflows |
|
Delegation |
Can permissions expand through handoffs? |
Authorization context, policy checks, and routing for consequential downstream actions |
Permissions are less likely to expand unexpectedly as work moves between agents or services, especially when each consequential action is routed the control plane for independent evaluation |
|
Approval |
Which actions require human sign-off? |
Workflow-enforced approval gates for sensitive or high-impact actions |
Critical actions can be paused for review before execution. If interactive approval is part of the experience, the exact elicitation pattern may depend on the client or interface used to submit the request |
|
Rate, Timing & SLA |
Does execution exceed safe limits or violate operating constraints? |
Workload throttling, concurrency controls, execution windows, retry limits, and SLA-aware scheduling |
Helps prevent retry storms, runaway execution, resource contention, and avoidable SLA risk |
|
Readiness |
Should this run at all? |
Dependencies, data availability, and execution prerequisites |
Work runs only when required conditions have been met |
|
Rollback & Recovery |
How do you recover safely when an AI-triggered action fails? |
Recovery workflows, retries, and compensating actions |
Failures are more likely to remain contained and recoverable rather than cascading across systems |
|
Traceability |
Can you prove what happened? |
Logs, approvals, execution history, and workflow lineage |
Teams can reconstruct what happened, how it happened, and why |
Resumen rápido: Las barreras de seguridad de la ejecución determinan hasta dónde llega la confianza.
5 señales de que tu arquitectura de agente de IA no sobrevivirá a la producción
Si alguno de estos te suena, probablemente te estés enfrentando a un problema de control de ejecución, no a un problema de IA.
01
Los agentes pueden llamar directamente a los sistemas de producción
Warning signs:
- Agents call production APIs directly
- Execution decisions live in prompts or application code
- Multiple paths exist to trigger the same action
What it means: Execution is based on implementation, not policy.
02
Las credenciales compartidas son las que hacen el trabajo más duro
Warning signs:
- Generic service accounts
- Long-lived credentials
- No agent-specific identities
- Limited attribution during investigations
What it means: Access is difficult to control and actions become difficult to trace.
03
La aprobación existe en la documentación de proceso, no en la aplicación
Warning signs:
- Teams are expected to follow approval procedures manually
- Approval is handled through email, chat, or tickets
- High-risk actions can still execute if someone forgets a step
What it means: Control depends on people remembering the process instead of the system enforcing it.
04
La lógica de reintento reside dentro del agente
Warning signs:
- Agent frameworks control retries
- No centralized retry or concurrency controls
- No execution throttling
- Failures generate repeated execution attempts
What it means: Small failures can escalate into resource contention, workflow storms, and operational incidents.
05
te puede supervisa acciones, pero no te puede evitarlas
Warning signs:
- You receive alerts after execution occurs
- Audit trails exist, but pre-execution enforcement does not
- Teams discover problems through dashboards instead of policy checks
What it means: The system can explain what happened after the fact, but it can't stop unsafe actions before they run.
Resumen rápido: Si te reconoce aunque sea uno de estos patrones, las decisiones de ejecución son probablemente ocurrir en código, procesos o herramientas individuales en lugar de a través de un plano de control centralizado.
Por qué el control de ejecución se complica en producción
Es relativamente fácil Define políticas de ejecución. El reto están asegurarse de que se apliquen en todos los lugares donde pueda funcionar el trabajo. A medida que los entornos crecen, la ejecución se extiende a más sistemas, servicios y herramientas de automatización, y no todos son gobernados de la misma manera.
Ahí es donde el control empieza a desmoronarse:
- Los agentes descubren caminos de ejecución te no anticipaban
- Las acciones evitan los canales de orquestación aprobados
- Las comprobaciones de identidad, aprobación y políticas no se aplican de forma consistente
- Diferentes sistemas aplican distintas reglas
- La nueva automatización se despliega más rápido de lo que la gobernanza puede seguir el ritmo
Garantizar que cada ruta de ejecución están sujeta a los mismos controles se vuelve aún más difícil cuando la ejecución se está distribuida entre múltiples agentes coordinadores.
Resumen rápido: el riesgo no es que son falten pólizas. Es que un camino de ejecución encuentra la forma de rodearlos.
Qué cambios cambian los sistemas multiagente
En un modelo de agente único, la ejecución está relativamente sencilla: un agente envía una solicitud, la petición se está evaluada y se está tomando una decisión.
En sistemas multiagente, los agentes pueden delegar trabajo, intercambiar contexto y desencadenar acciones posteriores, convirtiendo una única decisión de ejecución en una cadena de decisiones de ejecución. Como resultado:
- El acceso puede ampliarse mediante delegación
- La atribución se vuelve más difícil de rastrear
- Los límites de aprobación pueden no sobrevivir a las transferencias
- El volumen de ejecución puede aumentar inesperadamente mediante la coordinación
Los controles se mantienen igual
Los sistemas multiagente no requieren nuevas barreras de protección. Requieren que se apliquen las mismas barreras de forma consistente en cada paso de ejecución consecuente.
En la práctica, eso significa enrutar las acciones aguas abajo a través del plano de control de ejecución para su evaluación independiente. No se puede asumir que la confianza establecida en un solo paso se traslade automáticamente.
Cómo se ve esto cuando funciona
La ejecución sigue siendo controlada incluso cuando aumenta la coordinación. Los permisos permanecen limitados, las aprobaciones se aplican cuando existe riesgo, y cada acción sigue siendo atribuible mientras fluye por el plano de control.
Resumen rápido: Los sistemas multiagente no requieren nuevos controles. Requieren controles existentes para sobrevivir a cada traspaso, delegación y acción posterior.
Por qué fracasan la mayoría de las estrategias de barrera de seguridad de IA
Muchos equipos Comienza con barreras de seguridad de la IA, pero a menudo se aplican al comportamiento de los agentes más que a la ejecución.
Ejemplos comunes incluyen:
- Alerta las barreras — ayuda a moldear el comportamiento, pero no determines si una acción está permitida. Un agente aún puede generar una solicitud válida para una acción que nunca debería ejecutarse.
- Acceso directo a la API — evita por completo el punto de control de ejecución. Las decisiones son aplicadas en código en lugar de mediante políticas centralizadas.
- Autonomía todo o nada — trata cada acción como igualmente confiable o no confiable, independientemente del riesgo. Los equipos son obligados a elegir entre bloquearlo todo o confiar demasiado.
- Orquestación en sombras — introduce la lógica de ejecución en frameworks de agentes, código personalizado y herramientas desconectadas. te acaban con expansión de herramientas, controles débiles y problemas de sala de guerra.
Cada enfoque intenta influir en lo que hace el agente. Ninguna garantiza el control sobre lo que el agente está autorizado a ejecutar.
Resumen rápido: Influir en lo que un agente pretende hacer no es lo mismo que controlar lo que se le permite hacer.
El camino desde el acceso del agente hasta el control del agente
Los equipos no pasan directamente de pilotos de IA a agentes autónomos listos para producción. Pasan de dar acceso a los agentes a establecer control sobre lo que ese acceso puede ejecutar.
Utiliza el modelo de abajo para Ve dónde se encuentra tu arquitectura.
Level 1
Ejecución por Agente Directo
- Agents call APIs directly
- No centralized enforcement
- Decisions made in code
- Execution Risk: Very High
Level 2
Consciente de la identidad
- Agent identity exists
- Basic authorization
- Limited visibility
- Execution Risk: High
Level 3
Controles distribuidos
- Some approvals
- Some policy enforcement
- Controls spread across tools
- Execution Risk: Medium
Level 4
Plano de Control Centralizado
- Orchestrated execution is intercepted
- Requests route through a common control plane
- Consistent policy enforcement
- Execution Risk: Low
Level 5
Ejecución controlada a gran escala
- Multi-agent execution is controlled consistently
- Coordinated policy enforcement across orchestrated workflows
- Execution governance scales across teams and systems
- Execution risk: Lowest
La mayoría de las organizaciones que experimentan con agentes de IA operan entre el Nivel 1 y el Nivel 3. Las operaciones de IA listas para producción suelen comenzar en el Nivel 4, donde la ejecución orquestada están interceptada a través de un plano de control común. La transición del Nivel 3 al Nivel 4 está donde muchas iniciativas de IA pasan de la experimentación al control de ejecución a escala de producción.
Límites de ejecución: con y sin
Vamos a explorar un escenario real para unirlo todo.
Es cierre de fin de mes. Un flujo de trabajo de conciliación financiera falló porque una fuente de datos ascendente llegó tarde y los datos de transacciones requeridos están incompletos. Un agente de operaciones de IA está encargado de investigar trabajos fallidos y restaurar automáticamente flujos de trabajo estancados.
El agente decide que el proceso de conciliación debe ejecutarse de nuevo y genera una solicitud de ejecución. Lo que ocurre a continuación depende de si existen o no salvaguardas para la ejecución.
Sin barreras de ejecución
The agent reruns the workflow directly:
- Selects the production workflow instead of the test environment
- Retries execution without verifying whether the upstream data feed has successfully completed
- Repeats execution attempts after multiple failures based on the assumption that the failure was due to a temporary issue
- Triggers downstream reporting and settlement processes using incomplete data
Result: What started as a delayed data feed becomes a broader operational incident. Reconciliation results are inaccurate because required transactions weren’t available when processing occurred. Invalid outputs propagate across dependent systems, teams have to manually identify and correct downstream impacts, and recovery is significantly more complex than the original problem.
Con barreras de ejecución
The same execution request is intercepted before anything runs:
- Scope controls prevent access to production workflows
- Dependency validation detects that critical reconciliation data is still missing
- Retry policies prevent repeated execution attempts when prerequisite conditions haven’t been met
- Approval policies pause actions affecting financial reporting until a designated approver signs off
Result: The workflow doesn’t execute under unsafe conditions. The issue is contained at the point of execution, preventing downstream reporting errors while preserving a clear, controlled path to recovery.
¿Se te puede hacer cumplir todo en un solo lugar?
Sí, si las acciones de alto impacto con consecuencias posteriores son enrutadas a través de un plano de control común. Cuantos más caminos de ejecución fluyan por ese plano de control, más consistentemente se pueden aplicar las barreras de seguridad.
En este punto, surge una pregunta obvia: "Si ya tengo una pasarela API o malla de servicios, ¿no tengo ya un plano de control?"
Por qué una API Gateway o Service Mesh no es suficiente
La mayoría de los entornos cuentan con gateways API, sistemas IAM, limitación de velocidad y controles de malla de servicios. Esos controles son importantes. Solo están resolviendo otro problema.
Las pasarelas de API y la malla de servicios responden a la pregunta: "¿Puede esta solicitud llegar a este servicio?" Los controles de ejecución responden a otra pregunta: "¿Debería ejecutarse esta acción?"
No controlan la ejecución
Las pasarelas API y la malla de servicios no están diseñadas para evaluar si un flujo de trabajo, un trabajo u una acción operativa debe ejecutarse en función de dependencias, aprobaciones, riesgos de negocio o requisitos de recuperación.
Y no hacen cumplir decisiones como:
- "Pausa esto hasta que un humano lo apruebe"
- "No ejecutéis esto hasta que lleguen los datos aguas arriba"
- "Deja de intentarlo de nuevo tras 3 intentos fallidos"
Qué hace diferente un plano de control
Un plano de control toma decisiones a un nivel diferente:
- Rige acciones, no solicitudes.
- Evalúa el contexto, no solo la identidad.
- Hace cumplir las precondiciones, las aprobaciones y la lógica de recuperación.
- Controla flujos de trabajo completos, no solo llamadas individuales.
Por qué esto es importante para los agentes de IA
Los agentes de IA no solo llaman a las APIs. Pueden seleccionar acciones dinámicamente, encadenar flujos de trabajo y desencadenar la ejecución según los planes generados.
Sin controles a nivel de ejecución, cada API o ruta de ejecución a la que el agente pueda acceder está efectivamente "permitida". Las decisiones de riesgo ocurren implícitamente en el código y la configuración, en lugar de explícitamente a través de la política.
No hay un punto de control entre intención y ejecución.
Resumen rápido: las pasarelas de API y la malla de servicios determinan a qué puede llegar un agente. Los controles de ejecución determinan qué está autorizado a ejecutar un agente.
Cómo es un plano de control de ejecución
A lo largo de esta guía, hemos vuelto a la misma idea: el acceso al agente no es lo mismo que el control de ejecución. El acceso al agente determina a qué sistemas puede acceder un agente. El control de ejecución determina si una acción específica debe ejecutarse, bajo qué condiciones y con qué responsabilidad. Un plano de control de ejecución están lo que convierte el acceso en ejecución controlada.
Uso de Control-M como plano de control de ejecución
Para los equipos que ya usan Control-M, pueden enrutar las solicitudes de ejecución de agentes a través del Control-M MCP Server (actualmente una función de Vista Previa), mientras que Control-M aplica autenticación, permisos basados en roles, condiciones de flujo de trabajo y políticas de ejecución en el momento de la ejecución.
Control-M no construye el agente. Aplica control de ejecución a lo que el agente está autorizado a ejecutar. Eso significa que los agentes pueden interactuar con trabajos y flujos de trabajo a través de una interfaz controlada, pero solo dentro del alcance que permiten sus permisos existentes y solo cuando la ejecución se están enrutada a través de Control-M.
En lugar de que los agentes llamen scripts o APIs directamente, el flujo se presenta así: el agente solicita la ejecución → Control-M evalúa permisos, condiciones de flujo de trabajo, aprobaciones y restricciones de políticas → Trabajo autorizado
Cómo Control-M ayuda a controlar la ejecución iniciada por agentes
Antes de la ejecución, Control-M aplica...
- Authentication and role-based authorization
- Scope restrictions on approved jobs, workflows, and environments
- Dependency, prerequisite, and condition checks
- Approval workflows for higher-risk actions
- Auditability across agent-initiated activity
Durante la ejecución, Control-M proporciona...
- Execution control through existing RBAC and workflow policy
- Independent authorization of each execution request
- Visibility into execution status, logs, history, and outcomes
- Execution limited to permitted scope
- Structured audit trails for review and investigation
Para pasos de mayor riesgo, los flujos de trabajo nativos de aprobación Control-M pueden requerir la aprobación humana antes de la ejecución. La confirmación interactiva puede añadir otra comprobación cuando el cliente la permita, pero los flujos de trabajo de aprobación siguen siendo el punto de control más fiable.
Resumen rápido: Control-M no construye al agente. Ayuda a controlar lo que el agente está autorizado a ejecutar.
La monitorización no es control
A estas alturas, vale la pena hacer una distinción importante: observar la ejecución no es lo mismo que controlarla.
La vigilancia está control de detective. Las barreras de ejecución son control preventivo. Cuando las alertas de monitorización te, la acción ya se ha ejecutado y cualquier impacto están ya en marcha.
Eso puede ser aceptable en desarrollo, no en producción.
Lo que más importa
Production systems don’t assume agents will make the right decision every time. They enforce the conditions under which actions are allowed to run, regardless of what the agent can access or request. Every request is intercepted. Every request is evaluated. Nothing runs without enforcement.
Anything less is control by assumption.
¿Está tu modelo de ejecución de agentes listo para producción?
Marca la casilla si te puedes decir "Sí, lo tenemos cubierto."
- Cada agente tiene una identidad única
- Cada solicitud de ejecución está interceptada
- Las acciones de alto riesgo requieren aprobación
- El alcance se está aplicado a nivel de flujo de trabajo
- Las acciones delegadas conservan los permisos originales
- Las condiciones previas son validadas antes de la ejecución
- Los flujos de trabajo de recuperación son definidos
- Existe trazabilidad total de ejecución
Tu puntuación:
- 0-3 Sí respuestas Alto riesgo de ejecución.
- 4-6 Respuestas sí Gobernanza parcial de la ejecución.
- 7-8 Respuestas sí Base sólida para la ejecución de agentes de IA a escala de producción.
Próximos pasos
Press Release
