Cómo implementamos AI de forma segura en Akua: los controles detrás de los agentes

En Akua la inteligencia artificial no es un experimento de laboratorio: hay agentes trabajando todos los días en soporte, prevención de fraude, KYC/KYB, reporting y operaciones internas. Y cuando un procesador de pagos opera agentes con ese nivel de integración, la pregunta de clientes y partners es inevitable: ¿cómo lo hacen de forma segura?

La respuesta no es una herramienta mágica ni una política en un PDF. Son capas de controles concretos, muchos de los cuales existían antes de la AI y no se flexibilizaron para adoptarla. Este post los recorre uno por uno.

PRINCIPIO 01

No se puede proteger lo que no se ve: visibilidad de datos primero

Antes de darle acceso a datos a cualquier agente, hay que saber exactamente qué datos existen y dónde viven. Para eso usamos capacidades de clasificación y descubrimiento de datos (DSPM, con Wiz) que nos dan un desglose continuo por tipo de dato (financiero, PII, confidencial de negocio, operaciones de IT) y por geografía.

Esto no fue algo que agregamos cuando llegó la AI: desde el día uno de Akua sabíamos que el buen manejo de datos iba a ser crucial. Cada vez que nace un proyecto, se define una estrategia de tagging y control de acceso según el tipo de datos que va a manejar. Es parte de cómo funciona nuestro Internal Developer Portal (la Plataforma de Akua): todos los recursos se crean por infraestructura como código, con un benchmark de seguridad y hardening preestablecido. Y como ninguna configuración inicial sobrevive intacta al tiempo, ese estado se monitorea de forma automática y continua para detectar y corregir desvíos.

Sobre ese mapa aplicamos mínimo privilegio a nivel de agente: cada agente accede únicamente a los datos que necesita para su función, y sabemos en todo momento qué personas y qué agentes tienen acceso a qué.

Esto nos permite ser honestos con un matiz que muchos evitan: sí, algunos agentes acceden a PII. El agente de KYC/KYB o el de prevención de fraude no podrían cumplir su función sin ella. La diferencia entre eso y un riesgo descontrolado es el scope: ese acceso es deliberado, acotado a la función, visible y auditado. Los datos de tarjeta, en cambio, quedan directamente fuera de juego: el PAN se tokeniza apenas ingresa a nuestra infraestructura y ningún sistema de AI tiene acceso a él.

Algunos agentes acceden a PII porque su función lo requiere. La seguridad no está en negarlo: está en que ese acceso sea deliberado, mínimo, visible y auditado.

PRINCIPIO 02

Los agentes tienen identidad, no una llave maestra compartida

Uno de los errores más comunes en implementaciones de AI es que todos los agentes operen detrás de un mismo service account con permisos amplios. En Akua tratamos la identidad de los agentes con la misma seriedad que la de las personas.

A los agentes con funciones estables los tratamos como si fueran colaboradores: tienen identidad propia y accesos comparables a los que tendría un empleado en ese rol, ni más ni menos. Para otros escenarios usamos OAuth 2.1 con delegación, donde el agente actúa "on behalf of" una persona concreta: por ejemplo, un agente que pide permiso para enviar mensajes de Slack en nombre de un colaborador específico, con el consentimiento y el contexto de esa persona.

Cada modelo aplica a un escenario distinto, y conviene no mezclarlos. La delegación con OAuth 2.1 es el camino correcto para los asistentes de AI: herramientas que actúan a pedido de una persona, donde cada acción debe ser atribuible a quien la delegó, con permisos otorgados explícitamente. Hoy el ecosistema todavía no soporta este protocolo de forma pareja, pero es hacia donde debería converger ese escenario.

Los agentes autónomos con identidad propia son otro caso: ahí OAuth 2.1 no aplica, porque no hay una persona detrás de cada acción. Lo que importa es tratarlos como a un colaborador más y aplicarles los mismos principios de seguridad de siempre (identidad propia, mínimo privilegio, accesos revisables, revocación) sumados a los riesgos específicos de AI, como el comportamiento no determinístico o la manipulación vía inputs. En ambos escenarios el principio de fondo es innegociable: ningún agente opera con más permisos de los que su función requiere.

Un detalle de implementación que hace una gran diferencia: nuestros agentes no operan con API keys eternas escondidas en archivos de configuración. Usan roles de AWS, con credenciales temporales que se emiten al momento de asumir el rol y expiran solas. Un secreto de larga vida filtrado es una campaña de ataque; una credencial temporal filtrada es un incidente que se autolimita. No es casualidad que los principales marcos de riesgo de identidades no humanas pongan a los secretos de larga vida y al offboarding deficiente al tope de la lista: son los problemas de higiene de siempre que los agentes heredan y amplifican.

Una forma útil de pensarlo: la identidad responde quién es el agente, los permisos responden a qué puede acceder, y la función responde por qué ese acceso debería existir. Si alguna de las tres preguntas no tiene respuesta clara, el acceso no se otorga.

PRINCIPIO 03

Adoptar AI no significó flexibilizar ninguna política

Este punto es quizás el más importante del post: la implementación de AI en Akua no requirió relajar ni una sola política de seguridad.

Todo cambio en producción sigue exigiendo control dual: nadie, ni persona ni agente, puede llevar un cambio a producción sin la aprobación de alguien que no haya participado de ese cambio. Los agentes proponen, analizan, preparan; las decisiones críticas pasan por revisión humana.

Creemos que ese requisito de revisión humana va a cambiar en el futuro. Pero hoy necesitamos que las decisiones críticas tengan el accountability de una persona. Hace poco, OpenAI y Hugging Face reportaron un incidente en el que modelos bajo evaluación escaparon de su entorno de pruebas explotando una vulnerabilidad zero-day y terminaron comprometiendo infraestructura productiva de un tercero. Cuando un agente autónomo causa un incidente así, la pregunta incómoda es: ¿quién se hace cargo? Como industria, todavía no tenemos una buena respuesta para esos escenarios, y mientras no la tengamos, en Akua la responsabilidad sobre las decisiones críticas seguirá teniendo nombre y apellido.

CONTRA EL PROMPT INJECTION

El prompt injection (instrucciones maliciosas escondidas en datos que el agente procesa) es hoy uno de los vectores más discutidos en seguridad de AI. Y conviene llamarlo por su nombre: en un agente con permisos reales, una inyección de prompts no es una curiosidad de moderación de contenido, es escalación de privilegios con otro nombre. Nuestra defensa es en capas: trabajamos siempre con las últimas versiones de los modelos de Anthropic, que incorporan hardening específico contra este tipo de ataques, y asumimos igualmente que ninguna defensa del modelo es perfecta. Por eso el mínimo privilegio y el control dual importan tanto: aunque una inyección lograra manipular a un agente, su radio de impacto está acotado por diseño a los permisos de ese agente, y ningún cambio crítico se ejecuta sin aprobación humana.

PRINCIPIO 04

Observabilidad total: cada prompt, cada respuesta, cada tool

No se puede gobernar lo que no se observa. Tenemos visibilidad completa del comportamiento de nuestros agentes: los prompts, las respuestas, el razonamiento intermedio y las herramientas que invocan quedan registrados y disponibles para revisión, algo esencial para investigar una alucinación, un comportamiento inesperado o un incidente.

Sobre esa telemetría separamos responsabilidades: las trazas completas de inferencia se conservan en un entorno de acceso restringido, mientras que las métricas operativas (tiempos de respuesta, costos, tasas de error) alimentan nuestro monitoreo centralizado, donde tenemos alertas para detectar desvíos en cualquier servicio, incluyendo los causados por agentes de AI.

Y la observabilidad viene acompañada de capacidad de acción: si un agente se comporta de forma anómala, podemos revocar su autoridad y detenerlo de inmediato. Cuando un incidente puede desarrollarse a velocidad de máquina, poder verlo no alcanza; hay que poder frenarlo igual de rápido.

PRINCIPIO 05

Cada herramienta nueva de un agente es un acceso más

Un agente es tan riesgoso como las herramientas a las que está conectado. Por eso tratamos cada tool nueva de un agente igual que un pedido de acceso de un colaborador: si un agente ahora necesita acceso a Jira, el proceso es el mismo que si lo pidiera una persona. El equipo de ciberseguridad evalúa si ese acceso es realmente necesario para la función y, solo si lo es, lo otorga, con el alcance mínimo que la función requiere.

La resiliencia también es parte del diseño: nuestros sistemas tienen fallback entre modelos, de modo que la degradación de un modelo específico no interrumpe la operación, y la capa de infraestructura administrada sobre la que corren desacopla nuestra disponibilidad de la de cualquier proveedor individual. En esa capa trabajamos especialmente cerca del proveedor: el equipo de Akua tiene el privilegio de formar parte del Amazon Bedrock AgentCore Consortium, donde colaboramos con el equipo de AWS para utilizar la tecnología de la forma más segura posible, con feedback mutuo sobre la plataforma.

Y un detalle que suele pasarse por alto: los modelos no se actualizan solos. Cada cambio de versión de modelo es una decisión deliberada, se prueba antes de desplegar y se valida que los outputs sigan siendo correctos para cada caso de uso. Un modelo nuevo es un cambio en producción como cualquier otro, y se gestiona como tal.

PRINCIPIO 06

El ciclo de vida de desarrollo solo se agilizó

La AI no cambió nuestro ciclo de vida de desarrollo: lo aceleró en cada etapa. Hoy tenemos agentes que ayudan en el diseño de soluciones teniendo en cuenta riesgos de seguridad desde el primer boceto, escriben código y generan pruebas unitarias y end-to-end. Todo se agilizó, y la calidad mejoró: más cobertura de tests, más consistencia, más tiempo del equipo para pensar en dónde hay oportunidades para sumar valor.

Lo que no cambió son las reglas del juego. Los pipelines de CI/CD que construimos siguen funcionando y aplicando los mismos requisitos de calidad: análisis estático (SAST), escaneo de secretos y seguridad de infraestructura como código. Estos controles no son opcionales ni salteables: están embebidos en el pipeline, y las vulnerabilidades high o critical bloquean el despliegue. No pueden llegar a producción, sin importar quién (o qué) haya escrito el código. Esa es la ventaja de tener los controles viviendo en el proceso y no en la buena voluntad de quien programa: escalar la velocidad de desarrollo no degrada la seguridad.

Pentesting continuo, potenciado por AI

La validación externa es donde más se nota el salto. Veníamos haciendo pentesting semestral, algo que ya nos ponía por encima del estándar de la industria, donde muchas organizaciones lo hacen una vez al año y otras directamente no lo hacen. Pero con la velocidad de despliegue que habilita la AI, hasta el semestral queda corto: Akua suma funcionalidades y servicios nuevos a un ritmo en el que, entre un pentest y el siguiente, hay demasiado que ya salió a producción sin esa validación.

Por eso desarrollamos una plataforma interna de pentesting continuo potenciado por AI, disponible para toda la compañía: cualquier equipo, sea de Seguridad, Ingeniería, AI o incluso Marketing, puede lanzar un pentest cuando lo necesita. Y fuimos un paso más allá: la plataforma expone un MCP interno, de modo que un agente puede decidir por sí mismo lanzar un pentest sobre lo que está construyendo. El mismo agente recibe el reporte en Markdown (un formato amigable para la AI), lo interpreta y remedia los hallazgos.

El impacto en los tiempos es difícil de exagerar: lo que antes demoraba como mínimo dos meses entre el threat modeling en la etapa de diseño y el pentest en pre-producción, hoy lo hacemos en un día. Esta plataforma amerita un blog post dedicado, con arquitectura y aprendizajes incluidos: si te interesa conocerla en profundidad, dejanos un comentario o escribinos y lo armamos.

PRINCIPIO 07

Gobernanza con dueño, y con alguien que la desafía

Los riesgos de AI tienen un dueño claro en el organigrama: el Head of AI. Y como todo dueño de riesgo en Akua, no se audita a sí mismo: el equipo de ciberseguridad revisa y hace red teaming sobre los procesos de AI, igual que lo hace sobre los de Ingeniería o cualquier otra área.

Esa práctica incluye ejercicios de simulación: realizamos tabletop exercises (TTX) de escenarios de incidentes específicos de AI, para probar que nuestros playbooks de respuesta funcionan también cuando el actor del incidente es un agente y no un sistema tradicional.

PRINCIPIO 08

La mejor defensa contra el shadow AI es no necesitarlo

El shadow AI (el uso de herramientas de AI por fuera de todo control, con cuentas personales y datos sin clasificar) nace casi siempre del mismo lugar: la prohibición. Cuando la organización bloquea la AI, las personas no dejan de usarla; dejan de usarla donde seguridad puede verla.

Nuestra estrategia es la inversa: le damos al equipo todas las herramientas de AI que necesita para trabajar, evaluadas y aprobadas por ciberseguridad. Cuando el camino oficial es mejor que el atajo, el atajo pierde sentido.

Y como la confianza no reemplaza a la verificación, mantenemos un inventario automático y continuo de todo lo que corre en nuestra infraestructura, que identifica workloads de AI, agentes hosteados y herramientas de AI como servicio. Si algo nuevo aparece, lo vemos.

Pero el inventario es la línea de largada, no la meta. Un inventario de agentes que no se conecta con reglas de qué puede hacer cada uno es solo otra lista estática, y genera una confianza peligrosa: la sensación de control sin el control. Por eso cada agente descubierto queda atado a un dueño, una función y permisos que se aplican, no que solo se listan.

Cuando el camino oficial es mejor que el atajo, el atajo pierde sentido. Esa es nuestra estrategia contra el shadow AI.

En resumen

Akua es una empresa AI native. No adaptamos una organización vieja a una tecnología nueva: los procesos, las tecnologías y el conocimiento que hay en la empresa son exactamente lo que nos permite adoptar AI de forma segura a velocidades increíbles. La plataforma de datos clasificada desde el día uno, los pipelines con seguridad embebida, el control dual, la observabilidad, la gestión de identidades y accesos: todo eso estaba antes de los agentes, y es la razón por la que los agentes pudieron llegar sin abrir una sola grieta.

Y esa es la conclusión que más nos interesa compartir: la gran mayoría de los principios y procesos tradicionales de seguridad siguen sirviendo en esta nueva era de AI. Mínimo privilegio, segregación de funciones, control dual, gestión de identidades, revisión de accesos, monitoreo, respuesta a incidentes, red teaming: nada de eso quedó obsoleto. Lo que cambia es a quién se aplican (ahora también a agentes) y la velocidad a la que hay que operarlos. Los riesgos nuevos existen (comportamiento no determinístico, prompt injection, autonomía) y hay que sumarles controles específicos, pero se gestionan desde una base conocida, no desde cero.

La AI no creó los problemas de seguridad de identidades y privilegios: los industrializó. La cuenta de servicio sobrepermisada, el secreto que nunca rotó, el acceso que nadie revocó: esa deuda ya existía, solo que ahora puede pensar y actuar. Las organizaciones que tenían esa higiene al día adoptan agentes sin drama; las que no, están viendo cómo la AI les cobra la deuda.

La AI segura no requiere reinventar la seguridad. Requiere no abandonarla justo cuando más rápido se mueve todo. Y la buena noticia es que nunca es tarde para empezar: cada uno de los principios de este post se puede adoptar hoy, en cualquier organización, con las prácticas de seguridad que la industria ya conoce.