Cómo solucionar tres "Big Problems" del "Agentic AI Coding" usando Neo

El avance de la IA Generativa y Agéntica no es nada menos que espectacular y, casi indudablemente, la mayor y más rápida revolución tecnológica de la historia. Llevamos unos años oyendo la promesa de agentes autónomos y desarrolladores multiplicados por diez, sin embargo, cuando miras a un equipo de desarrollo de software en un entorno corporativo, los atascos aún son los de siempre. La realidad es que aunque las demos presentan unos escenarios idílicos, esta tecnología no está todavía al nivel al que se nos presenta.

Figura 1: Cómo solucionar tres "Big Problems" del "Agentic AI Coding" usando Neo

Neo es el producto que hacemos en Sagittal AI, una empresa que no vende magia, sino que trata de maximizar el partido que se le puede sacar a la IA, aceptando sus limitaciones, y del cual hablé en esta conferencia que os dejo por aquí.

Figura 2: Por qué la IA no ha mejorado el rendimiento de tus Developers ... por ahora

Pero hoy os quiero hablar de tres problemas concretos que, si has trabajado en equipos de desarrollo de software seguro que conoces bien. Vamos a verlos uno a uno.

Problema: La interfaz. De secretario/a del bot a delegar trabajo

El patrón actual te será familiar: abres el chat o el plugin del IDE, te conviertes en “prompt engineer”, le explicas al agente lo que quieres, le pegas medio ticket, añades fragmentos de código, corriges lo que ha entendido mal… y vuelta a empezar. El asistente de IA no está tanto a tu servicio como tú al suyo. 

El problema es que con ese esquema no puedes delegar de verdad. Tienes que estar presente, pendiente del chat, confirmando el plan, cada paso, y desbloqueando al agente cuando se atasca, o reconduciendo cuando se pierde. El cuello de botella sigue siendo tu tiempo. Mientras el humano tenga que estar “en la sala” para que las cosas avancen, la productividad solo sube un poco, nunca un orden de magnitud. Algunos CLIs e IDEs han intentado introducir gestión de tareas en background pero, en la práctica, son difíciles de configurar y usar y casi nadie las adopta.

Figura 3: Neo funciona integrado en tus plataformas de ingeniería del software

Neo resuelve este problema de forma que la interacción entre IA y humano sea exactamente la misma que entre humano y humano. No hace falta una interfaz de usuario nueva. Si se trata de delegar, ya tenemos herramientas colaborativas para delegar y trabajar en equipo: Jira, GitHub, Azure DevOps, Confluence, Figma… 

Figura 4: Tools con las que se integra Neo

A Neo se le asignan tareas como a cualquier miembro del equipo, se encarga de buscar contexto en tus tickets, documentos, código, crear la rama, implementar cambios, escribir pruebas, resolver el CI si falla, y actualizar el estado de las tareas según el "Way of Working" del equipo. 

Figura 5: Pull request diagrams

Tú te vas a otra cosa y vuelves cuando hay PR lista para revisar, y lo haces en herramientas que llevan 15 años perfeccionando la UX para revisar código. ¿Que quieres iterar? Comentarios en la propia PR ¿Que no te gusta el resultado? Descarta la PR, y no has perdido ni el dinero ni el tiempo.

Problema: Seguridad. CVEs críticos y teatro de permisos

La mayoría de los desarrolladores trabajan en portátiles no plataformados y con permisos de administración. Los agentes que ejecutan corren con sus mismos permisos y las mismas credenciales que usan para acceder a repositorios, pipelines y entornos en la nube. Si alguien compromete el Agente IA o uno de sus conectores, no se queda en la máquina local: entra en la organización con la identidad del desarrollador.

Figura 6: Cosas que puede hacer Neo en tus equipos de ingeniería

Los MCPs y “tools” enchufados al Agente AI agravan aún más el tema. De repente el modelo puede hablar con bases de datos internas, paneles de administración o scripts de automatización. Cuando algo falla, lo que aparece publicado son CVEs de impacto alto o crítico, porque no estamos hablando de un pequeño leak, sino de ejecución remota, escaladas de privilegios o acceso directo a datos sensibles. Si no, respasa el libro de "Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment.

Figura 7:"Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment"

escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord

Los fabricantes de estas herramientas tratan de mitigar el problema interrumpiendo al Agente IA para que el usuario confirme el uso de la herramienta o recurso, pero esto deja de hacer al agente independiente y al final se acaban ejecutando en un modo “sí a todo” que invalida la mitigación.

Neo parte de un planteamiento distinto. La configuración es gestionada por los equipos de IT y seguridad, no por cada desarrollador en su portátil. Sus permisos se acotan por integraciones y políticas corporativas, de forma parecida a cuando incorporas a un contractor externo. Además, no es un sistema en el que se considera al LLM inteligente y se le pone en un loop hasta que consiga su objetivo.

Figura 8: Fix vulnerabilities before they happen

En su lugar, Neo tiene una serie de flujos deterministas optimizados para tareas de software, lo cual permite meter validaciones en cada paso del flujo, y dar a cada paso exclusivamente el contexto que necesita. Siguen siendo LLMs y el determinismo nunca está garantizado, pero Neo consigue de esta manera una ejecución mucho más predecible.

Problema: Productividad. acelerar solo al programador no mueve la aguja

Si preguntas a los desarrolladores, la mayoría dice que con IA va más rápido. Pero cuando miras las métricas del equipo, ya sea tiempos de entrega, funcionalidades desplegadas, bugs resueltos, … parece que los datos no concuerdan con la experiencia individual.

Al mirar el ciclo completo de una funcionalidad, queda bastante claro lo que está pasando: alguien pide una funcionalidad, se redacta y refina la especificación, se espera a dependencias (diseño, traducciones, otros equipos), se asigna, se desarrolla, se revisa el código, se diseña el plan de pruebas, se ejecutan los tests, se corrigen fallos y, si todo va bien, se despliega. 

Figura 9: Project Plan de Ingeniería del Software

El tiempo que el desarrollador pasa escribiendo código es sólo un tramo de esa cadena. Aunque reduzcas a la mitad este tiempo, las dependencias, revisiones, validaciones y esperas siguen igual. El lead time de la funcionalidad casi no se mueve.

Figura 10: Code and test plans in Azure DevOps

Neo está diseñado para este escenario. A Neo no le das un prompt de dos líneas y por el otro lado sale un producto terminado, porque a un miembro del equipo tampoco le pides algo así. Neo ayuda a todos los miembros del equipo en todas las fases del ciclo de vida, aportando un poco a cada uno, acortando cada espera, y automatizando cada tarea monótona.

Como todo esto ocurre en las mismas herramientas colaborativas que ya usas para medir, el impacto se ve en lead time, throughput y calidad, no solo en la sensación subjetiva.

Cómo probar Neo en tu empresa.

Neo no es una herramienta para un proyecto individual ni para un equipo pequeño. Para eso, hay otras herramientas mejores. Neo no es tan potente como el último agente del que hayas oído hablar esta semana trabajando en un problema de forma autónoma todo un fin de semana. Ninguna demo de Neo te va a dejar boquiabierto.

Neo está específicamente diseñado para un entorno corporativo con equipos de entre 5 y 15 personas que siguen un proceso, ya sea ligero o pesado, coordinado en herramientas colaborativas y donde la especificación suele estar dispersa en varias herramientas y cambia constantemente.

Figura 11: Comienza a probar Neo desde hoy mismo

Puedes ver varias demos de Neo en acción para hacerte una mejor idea del concepto, y contactar con Sagittal AI para un piloto en tu empresa.

Un saludo,

Autor: José Palazón, CEO de Sagital.ai

 Contactar con José Palazón

¿Qué se necesita para tener seguras las identidades digitales en la empresa?

La semana pasada un amiguete y compañero de profesión me hizo esta pregunta: "¿Que necesitaría para tener seguras las identidades digitales en mi empresa?" ¿Necesitaríamos invertir más en Soluciones de Gobierno de la Identidad, de Gestión de Cuentas Privilegias, Control de Acceso, CIAM, Multifactor Authentication? ¿O sería conveniente que empezáramos a mirar soluciones de ISPM (Identity Security Posture Management) o ITDR (Identity Threat Detection and Response)?

Figura 1: ¿Qué se necesita para tener seguras

las identidades digitales en la empresa? 

Una pregunta de muñeca rusa, donde una pregunta lleva a otra y a otro. Para responderle fácilmente, y comenzar la conversación con un poco más de contexto, la respondí cariñosamente que eso dependerá de los resultados de la Evaluación de Riesgos. Así que si ya tenía una duda, yo le acababa de meter un nivel más de complejidad, que hizo que se le quedara cara de sorprendida.

Figura 2: Open Source INTelligence (OSINT): Investigar personas e Identidades en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

Hay que tener en cuenta que no en todas las organizaciones, los departamentos que gestionan la Seguridad de las Identidades Digitales, están integrados en el área de seguridad, y en muy pocos se realiza una evaluación de riesgos más o menos formal para concluir los controles a implementar en base a los riesgos identificados.

Riesgos de Seguridad de la Gestión de Identidades

Seguidamente la invite a reflexionar de manera una poco más profunda, y estuvimos comentando los escenarios riesgos principales que afectan a la Gestión de Identidades Digitales y que controles mitigantes en formato de soluciones de seguridad de la identidad sería conveniente implementar en base a los mismos:

• Leavers: Casos frecuentes de personas que abandonan la compañía y cuyas cuentas de acceso a la organización no se desactivan a tiempo - o nunca- o usuarios que cambian de departamento y arrastran sus permisos de acceso a sistemas. En este caso deberíamos priorizar una herramienta de Gobierno de Identidades Digitales.

• Cuentas Privilegiadas Sin Control: Administradores de sistemas o aplicaciones que mantienen el acceso privilegiado asignado de manera permanente y no se monitoriza / controla cómo usan sus privilegios. En este caso deberíamos priorizar la implementación de una solución que nos permita movernos a un escenario de Zero Standing Privileges (ZSP) y que asigne los permisos de administrador durante el tiempo que se necesiten para realizar la tarea administrativa y siguiendo el flujo de aprobación necesario.

Figura 3: Demostración de Robot de Tokens OAuth de identidades

También dependiendo del escenario podría ser conveniente implementar una solución que haga grabación e indexación de sesiones como las que aportar los Privileged Access Manager (PAM) tradicionales, aunque de manera generalista no es algo que, a mí personalmente, me guste del todo, ya que la telemetría que ofrecen hoy en día los End-Point Detection & Response (EDR) es suficiente en la mayoría de los casos para tener un tracking que nos permita identificar cómo los administradores utilizan sus permisos administrativos.

• Acceso con una autenticación débil: Tanto a aplicativos como a servicios expuestos en Internet - e incluso que no están expuestos en Internet hoy en día 😊 -. En este caso los  Identity Providers (IDP) que la mayoría de las empresas tienen, como pueden ser Azure AD o Google IDP, ya tiene capacidades más que suficiente para proveer una autenticación robusta, pero claro hay que configurarlos bien. Sin embargo, hoy en día una autenticación con usuario y contraseña + un Multi-Factor Authentication (MFA) compartido por SMS es algo que se nos queda un poquito cortito en cuanto a seguridad.

Figura 4: Las Yubikeys para gestión de Passkeys

Por lo tanto deberías abogar por implementar Passkeys en la medida de los posible, y ya de paso, quitamos a los usuarios el dolor de las passwords añadiendo unas políticas de acceso condicional que tengan una inteligencia mínima que haga que el sistema sea capaz de reaccionar frente amenazas del sistema de autenticación como puede ser cambios de ubicación imposibles o un usuario que se autentica con una parámetros que difieren bastante de sus comportamientos, tales como horarios y localizaciones de login.

• Riesgos asociados con las identidades de Business Partners: Ya sean clientes, proveedores, o fabricantes, que consumen servicios digitales que provee la empresa. En este caso sería conveniente contar con un Customer Identity & Access Management (CIAM) que nos permita unificar la experiencia de usuario en su proceso de autenticación, aportando seguridad y reducción fricción, así como asegurar el cumplimiento a normativas que puedan ser aplicables como el Reglamento General de Protección de Datos (RGPD) y tunear la experiencia del usuario

• Riesgo de Fraude debido a Conflictos de Segregación de Funciones: o dicho de otra de manera  más sencilla con un par de ejemplos, que el mismo usuario tenga permisos para hacer las nóminas y liberar los pagos, o que el mismo usuario tenga permisos para crear solicitudes de pedidos de compras y aprobar la mismas. 

En este caso necesitaremos una solución de estilo  Government Risk & Compliance (GRC) que nos permita controlar conflictos de segregación de funciones, idealmente de manera proactiva, y que sea multi aplicación, es decir, que no se limite a los permisos de una sola aplicación, como el ERP. Esto es algo que algunas herramientas de Gobierno de Identidades proveen, y también, obviamente, existen soluciones dedicadas a mitigar este tipo de riesgos

 

No creo que sea necesario seguir con más ejemplos, entiendo que con estos cinco casos se ve bastante bien que los riesgos que se busquen proteger en la gestión de identidades deben priorizar la decisión sobre que tecnologías debes implantar. Como habéis visto, además, no he querido tirarme al barro del riesgo relacionado las Non-Human Identities - y las tecnologías de seguridad para las Non-Human Identities -o las Identidades de Agentes IA, ya que estos actúan en nombre del usuario, o con su propia identidad, por lo que se debe tener en cuenta que los mismos van a trabajar en base objetivos y no de manera determinista, por lo tanto sus permisos es fácil que necesiten cambiar mientras estás realizando una tarea.

Figura 5: Identidades NO Humanas (NHI "Non-Human Identities").

La Gestión de un Riesgo de Seguridad Emergente

Esto seguro que nos da para otro artículo dedicado, aunque si me gustaría mencionar que esto a día de hoy es un riesgo relevante real, principalmente para organizaciones mas avanzadas tecnológicamente hablando (por supuesto que llegará al resto). Esta es una categoría que aún está siendo construida - no olvidéis que el primer Agentic AI lo vimos en diciembre de 2024, con lo que llevamos menos de un año y medio con los agentes, y empresas como Cloudflare están construyendo arquitecturas de referencia para la gestión de la seguridad de estas identidades.

Figura 6: Arquitectura de MCP Security en Cloudflare

Como conclusión, me gustaría resaltar la importancia de definir un roadmap de trabajo dentro del Plan Director de Seguridad con todas las iniciativas relacionadas con la Seguridad de Identidades en base a los riesgos que necesitemos mitigar. Y por supuesto, que seamos conscientes de que la seguridad de la identidad digital en muchas ocasiones (cada más) es la única capa de defensa, por lo tanto debemos tomarnos muy en serio esta labor, e implementar las medidas de protección pertinentes hasta llevar el nivel de riesgo a ratios aceptables para nuestra organización. O atente a las consecuencias.

Saludos,

Autor: Samuel López Trenado, especialista en Gestión de Identidades Digitales

Contactar con Samuel López Trenado