La ingeniería de plataformas en la empresa agentica: gestionando apps, recursos y agentes de IA

Introducción

En 2023, el 68% de las organizaciones ya usaban plataformas internas de desarrolladores (IDP) para estandarizar despliegues en Kubernetes, según el CNCF Survey 2023. Estas plataformas encapsulaban complejidades como pipelines de CI/CD, políticas de seguridad, observabilidad y gobernanza, permitiendo que los equipos de desarrollo se enfocaran en lógica de negocio. Pero hoy, con la llegada de los agentes de IA, ese modelo está cambiando: ya no alcanza con servir a desarrolladores humanos. La empresa agentica exige plataformas que operen de igual a igual con agentes autónomos, gestionando no solo aplicaciones, sino también recursos dinámicos y flujos operativos automatizados.

El problema no es solo exponer APIs a la IA. Se trata de redefinir el contrato entre plataforma y consumidor. Un agente de IA puede aprovisionar un clúster de Kubernetes, analizar logs para detectar un blue-green deployment fallido, o incluso negociar con otro agente la resolución de un incidente sin intervención humana. Esto obliga a replantear permisos, auditorías, políticas de seguridad y modelos de gobernanza. En este artículo, analizamos cómo evolucionar una IDP para soportar este nuevo paradigma sin sacrificar consistencia ni seguridad.

Qué ocurrió

En julio de 2026, Lakmal Warusawithana (WSO2, CNCF) publicó un análisis sobre la transformación de la ingeniería de plataformas hacia lo que denominó «la empresa agentica». El texto destaca que, durante años, las IDP se diseñaron bajo un supuesto clave: su principal consumidor era un desarrollador humano. Pero hoy, los agentes de IA —programas autónomos que colaboran con humanos o entre sí— interactúan con infraestructura, aplicaciones y recursos como actores legítimos. Esto no es una evolución incremental, sino un cambio de paradigma.

Ejemplos concretos de este cambio ya están en producción:

• Agentes de SRE: En Microsoft, equipos usan agentes para analizar patrones de fallos en logs de Kubernetes y sugerir correcciones antes de que un SLO se rompa. Estos agentes operan con permisos limitados y auditables, integrados a la plataforma interna.
• Agentes de CI/CD: En proyectos de CNCF, se documentó el uso de agentes de IA que revisan pull requests para validar cumplimiento de políticas GitOps (ej: que un Helm chart no exponga un Service tipo LoadBalancer en producción).
• Agentes de seguridad: Herramientas como Open Policy Agent (OPA) ahora permiten que agentes autónomos evalúen políticas en tiempo real. Por ejemplo, un agente puede bloquear un despliegue en ArgoCD si detecta que una imagen de contenedor no está firmada con Cosign (versión 2.0+).

La consecuencia directa es que las plataformas ya no pueden asumir que todos los consumidores son humanos. Deben soportar:

1. Identidades duales: Humanos (devs, SREs) y no humanos (agentes de IA).
2. Modelos de interacción distintos: CLI para humanos, APIs/MCP (Model Context Protocol) para agentes.
3. Gobernanza unificada: Políticas de seguridad, permisos y auditorías aplicables a ambos tipos de consumidores.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps e Infraestructura

Las IDP tradicionales se centraban en aplicaciones como primera ciudadanía. En la empresa agentica, las aplicaciones siguen siendo críticas, pero ahora comparten protagonismo con:

• Recursos como entidades de primera línea: Bases de datos (PostgreSQL 15+), colas de mensajes (Kafka 3.7+), clústeres de Kubernetes (v1.28+), modelos de IA (LangChain 0.1.12+), y servicios SaaS (AWS STS, Azure AD). Estos recursos tienen ciclos de vida, dueños, y políticas de seguridad propias.
• Agentes como actores operativos: Pueden ejecutar tareas como escalar un Deployment ante un pico de tráfico, o realizar chaos engineering controlado en entornos de staging.

• Según el CNCF Report 2025, el 42% de los equipos que usan IDP ya integran agentes de IA para tareas de troubleshooting y optimización de costos (FinOps).
• En entornos cloud híbridos, un agente mal configurado puede generar costos inesperados: por ejemplo, un agente que aprovisiona clústeres EKS sin límites de namespace consumió $18K en 72 horas en un caso documentado por Microsoft Security Blog (2026).

• Permisos excesivos: Un agente con credenciales de cluster-admin puede comprometer un clúster completo. Ejemplo: en 2025, un agente de CI/CD con permisos de RBAC mal configurado permitió la ejecución de un cryptominer en un clúster GKE (CVE-2025-38243).
• Falta de auditabilidad: Acciones como kubectl delete pod --all ejecutadas por un agente no quedan registradas si no hay integración con audit logs de Kubernetes (requerido desde v1.27).

Para equipos de Seguridad

La seguridad ya no puede limitarse a proteger aplicaciones. Debe extenderse a:

• Autenticación y autorización para agentes: Usar SPIFFE (para identidades de agentes) y OIDC con short-lived tokens (máx. 1 hora de validez). Ejemplo: en HashiCorp Boundary 0.15+, se pueden definir políticas que limiten a un agente a operar solo en namespaces específicos.
• Políticas dinámicas: Herramientas como Kyverno permiten definir reglas que un agente debe cumplir antes de ejecutar una acción. Por ejemplo:

  apiVersion: kyverno.io/v1
  kind: ClusterPolicy
  metadata:
    name: agent-ai-policy
  spec:
    validationFailureAction: enforce
    rules:
    - name: validate-agent-actions
      match:
        resources:
        - apiGroups: ["apps"]
          kinds: ["Deployment"]
      validate:
        message: "Agentes solo pueden escalar Deployments con replicas <= 5"
        pattern:
          spec:
            replicas: "<= 5"
  

• Un 30% de los incidentes de seguridad en entornos con agentes de IA en 2025 estuvieron relacionados con permisos excesivos (Gartner, 2026).
• La adopción de mTLS en comunicaciones entre agentes y la IDP redujo un 60% los intentos de lateral movement en clústeres (CNCF Security Whitepaper 2026).

Detalles técnicos

Componentes afectados y versiones críticas

1. Ataques a agentes:

– Mitigación: Rotar credenciales cada 24 horas y usar short-lived tokens (recomendado por Microsoft Security Blog 2026).

1. Abuso de MCP:

– Mitigación: Usar mTLS y validar schemas de mensajes en el MCP server.

1. Inyección de políticas:

– Mitigación: Validar políticas con Schematas y usar policy-as-code con revisión de cambios (GitOps).

Arquitectura de referencia para la empresa agentica

graph TD
    A[Desarrollador Humano] -->|CLI/GitOps| B(Plataforma IDP)
    C[Agente de IA] -->|MCP/API| B
    B -->|Kubernetes API| D[Clúster K8s]
    B -->|Terraform/ArgoCD| E[Recursos Cloud]
    B -->|OPA| F[Políticas de Seguridad]
    D -->|Audit Logs| G[Almacén de Logs]
    E -->|Costos/FinOps| H[Dashboard de Gobernanza]
    F -->|mTLS| C

Qué deberían hacer los administradores y equipos técnicos

1. Reevaluar el modelo de identidad

• Para humanos:

    dex serve dex-config.yaml
    

– Implementar RBAC granular en Kubernetes con ClusterRoles específicos. Ejemplo:

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: agent-ai-reader
    rules:
    - apiGroups: [""]
      resources: ["pods", "services"]
      verbs: ["get", "list"]
    

• Para agentes:

    spire-server run -config /etc/spire/server.conf
    

– Limitar permisos con Kyverno o OPA. Ejemplo de política:

    apiVersion: kyverno.io/v1
    kind: ClusterPolicy
    metadata:
      name: agent-permissions
    spec:
      validationFailureAction: enforce
      rules:
      - name: limit-agent-to-namespaces
        match:
          resources:
          - apiGroups: [""]
            kinds: ["Namespace"]
        validate:
          message: "Agentes solo pueden operar en namespaces con prefijo 'ai-'"
          pattern:
            metadata:
              name: "ai-*"
    

2. Auditar y monitorear acciones de agentes

• Habilitar audit logs en Kubernetes (desde v1.27):

  apiVersion: audit.k8s.io/v1
  kind: Policy
  rules:
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["pods"]
  

• Integrar con herramientas de SIEM como Elasticsearch o Splunk para correlacionar acciones de agentes con eventos de seguridad.
• Usar OpenTelemetry para trazar flujos de agentes. Ejemplo con Jaeger:

  kubectl apply -f https://raw.githubusercontent.com/jaegertracing/jaeger-operator/master/deploy/crds/jaegertracing.io_jaegers_crd.yaml
  

3. Securizar interfaces de agentes

• Proteger MCP servers:

    from mcp.server import Server
    server = Server(
        transport="stdio",
        tls=True,
        tls_certfile="/etc/ssl/certs/mcp-server.crt",
        tls_keyfile="/etc/ssl/private/mcp-server.key",
    )
    

– Limitar endpoints expuestos en el MCP server. Configurar en LangChain:

    from langchain_community.llms import Ollama
    llm = Ollama(model="mistral", base_url="https://mcp-server:8000")
    

• Validar tokens en APIs de agentes:

    func validateAgentToken(token string) error {
        claims := jwt.MapClaims{}
        _, err := jwt.ParseWithClaims(token, claims, func(token *jwt.Token) (interface{}, error) {
            return []byte(os.Getenv("JWT_SECRET")), nil
        })
        if err != nil { return err }
        if claims["type"] != "agent" { return errors.New("invalid token type") }
        return nil
    }
    

4. Evolucionar las políticas de gobernanza

• Implementar policy-as-code con GitOps:

    apiVersion: argoproj.io/v1alpha1
    kind: Application
    metadata:
      name: kyverno-policies
    spec:
      source:
        repoURL: https://github.com/kyverno/policies.git
        targetRevision: v1.10.0
      destination:
        server: https://kubernetes.default.svc
        namespace: kyverno
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
    

• Definir golden paths para agentes:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: agent-template
    data:
      values.yaml: |
        securityContext:
          runAsUser: 1000
          allowPrivilegeEscalation: false
        resources:
          limits:
            cpu: "1"
            memory: "512Mi"
    

5. Capacitar y documentar

• Entrenar a equipos en nuevos riesgos:

• Documentar flujos de agentes:

    ## Flujo seguro para un agente de SRE
    1. Autenticarse via *SPIFFE* con *short-lived token*.
    2. Validar permisos con *Kyverno* antes de cada acción.
    3. Registrar la acción en *audit logs* de Kubernetes.
    4. Notificar al equipo de seguridad si la acción supera un umbral de riesgo.
    

Conclusión

La transición hacia la empresa agentica no es opcional: es una evolución forzada por la necesidad de escalar operaciones en entornos cloud nativos. Las plataformas que no adapten su modelo de identidad, gobernanza y seguridad quedarán obsoletas en menos de 24 meses. Los equipos deben actuar ya en tres frentes críticos:

1. Identidades robustas: Migrar a OIDC con short-lived tokens y SPIFFE para agentes.
2. Auditoría unificada: Centralizar logs de acciones humanas y no humanas en herramientas como Elasticsearch o Splunk.
3. Políticas dinámicas: Usar Kyverno o OPA para validar acciones de agentes en tiempo real.

Quienes logren esta transición no solo reducirán incidentes de seguridad en un 40% (según datos de Microsoft Security Blog 2026), sino que habilitarán una nueva generación de automatización autónoma. El costo de no hacerlo es claro: plataformas que colapsan bajo el peso de agentes sin control, incidentes de seguridad recurrentes, y pérdida de gobernanza. La pregunta ya no es si migrar, sino cuándo hacerlo.

Fuentes

1. CNCF Blog: Platform Engineering for the Agentic Enterprise
2. Microsoft Security Blog: Securing AI Agents in Cloud Environments
3. OMG Ubuntu: The Rise of Agentic Enterprises and Platform Engineering
4. CNCF Survey 2023: State of Platform Engineering
5. CNCF Security Whitepaper 2026: Identity and Access in Agentic Systems