Cómo se aseguran los sistemas internos de Figma con agentes

Cuando se trata de proteger nuestras plataformas internas, las amenazas contra las que nos defendemos en el equipo de ingeniería de seguridad de Figma cambian constantemente. La infraestructura de nube cambia con frecuencia, los desarrolladores adoptan nuevas herramientas y lo que las personas instalan y ejecutan en sus portátiles es diferente cada trimestre (como cuando el equipo impulsor de diseño comienza a programar sus propias aplicaciones y automatizaciones).

Nuestro SIEM, Panther, nos ayuda a mantenernos al frente de todas estas amenazas al realizar una amplia gama de verificaciones en nuestra infraestructura en la nube, extremos, aplicaciones SaaS y sistemas de identidad. Cuando detectes un problema potencial, publica alertas en Slack y crea un ticket de Asana para que los ingenieros puedan recibirlo. Desde el punto de vista histórico, estar de guardia implicaba mucho trabajo manual. Reunir contexto fue el principal desafío. Teníamos que averiguar si la alerta se parecía a algo que habíamos visto la semana pasada, si había un PR pendiente que pudiera abordar el problema, si los hilos de Slack mencionaban algo relacionado, y así sucesivamente.

Al igual que muchos equipos, vimos que las capacidades del modelo LLM se aceleraron con rapidez durante el año pasado. Recientemente compartimos cómo Figma se mantiene a la vanguardia de las vulnerabilidades con agentes en nuestra base de código, que detectó problemas en los cambios de configuración de herramientas sensibles como Okta y AWS gracias a inversiones previas en almacenar su configuración como código. Pero para reducir significativamente el trabajo y mejorar la forma en que protegemos los sistemas internos de Figma, necesitábamos ir más allá del base de código y construir un nuevo sistema que pudiera ayudarnos a manejar el amplio rango de problemas que encuentra nuestro SIEM.

Empezamos con un objetivo limitado de construir una capa de recuperación que pudiera dar lugar al razonamiento previo del ingeniero cuando se activara una nueva alarma. Ese proyecto eventualmente creció hasta convertirse en un sistema agentic completo que investiga las alertas, consulta los registros de auditoría, programa cambios, abre PR y mejora con el tiempo a través de su propia memoria. Ha cambiado completamente la forma en que trabaja nuestro equipo de seguridad.

La capa RAG: Dando memoria a las alertas

Lo primero que hicimos fue un sistema de clasificación mejorado mediante la recuperación en las bases de conocimiento de AWS Bedrock y Amazon Kendra. Nuevamente, nuestro objetivo inicial fue simplemente revelar el contexto histórico de lo que había sucedido la última vez que se activó la misma alerta y tal vez suprimir las alertas duplicadas.

Cuando una alerta de Panther se activa, nuestro controlador de Lambda la convierte en un documento estandarizado y lo indexa en Kendra. Extraemos campos estructurados de la carga útil de la alerta en bruto: IP de p_any_ip_addresses, actores de p_any_usernames y varios campos de usuario específicos del proveedor, ID de cuentas de AWS de los ARN. Estos se convierten en atributos de documento Kendra que se pueden buscar junto al título de la alerta, la severidad, las etiquetas y las marcas de tiempo:

const attrs: DocumentAttribute[] = [
  { Key: 'alert_id', Value: { StringValue: doc.alert_id } },
  { Key: 'alert_type', Value: { StringValue: doc.alert_type } },
  { Key: 'severity', Value: { StringValue: doc.severity } },
  { Key: 'status', Value: { StringValue: doc.status } },
  { Key: 'created_at', Value: { DateValue: doc.created_at } },
  { Key: 'has_investigation_context', Value: { LongValue: doc.has_investigation_context } },
]

Cuando se active la próxima alerta similar, consultará Bedrock en busca de coincidencias semánticas utilizando el título de la alerta (que suele ser el nombre de la detección seguido del nombre de usuario del actor) como el vector principal:

function buildQueryFromAlert(alert: Alert): string {
  return `${alert.data.title}\n\nhas_investigation_context=1`
}

Nos inclinamos hacia la recuperación de alertas que tengan investigation_context, que son comentarios de un ingeniero de guardia en Slack sobre lo que encontró. (Un aviso cerrado sin comentarios no dice casi nada.) Capturamos el contexto de la investigación sin modificar los procesos de trabajo existentes de nuestros ingenieros. Cuando alguien deja una nota en un hilo de alertas de Slack (y tenemos un procedimiento similar para los tickets de Asana), indexamos ese comentario de nuevo en Kendra como contexto de investigación sobre la alerta original:

export async function addInvestigationContext(
  alertId: string, contextText: string
): Promise<void> {
  const existingDoc = await findAlertDocument(alertId)
  if (!existingDoc) return

  let updatedContext: string[]
  updatedContext = [...existingDoc.investigation_context, contextText]

  const updatedDoc: AlertDocument = {
    ...existingDoc,
    investigation_context: updatedContext,
    has_investigation_context: 1,
  }
  await reindexDocument(updatedDoc)
}

Cada vez que alguien escribe un comentario útil sobre un hilo de alertas, hace que todas las alertas similares futuras sean menos costosas de calificar. No necesitábamos una herramienta especial de anotación ni un proceso de entrenamiento, porque el flujo de trabajo existente ya era el proceso de entrenamiento.

Lo que la recuperación podría hacer y dónde se detuvo

Our retrieval system generates and posts a summary (for human consumption) into Slack/Asana for each alert. Esto comenzó a aliviar nuestra carga de guardia casi de inmediato. De manera anecdótica escuchamos que estaba reduciendo el tiempo de clasificación de alertas, y también nos permitió hacer algunos cambios programáticos para reducir la fatiga de las alertas. Cuando encontramos alertas similares con un alto grado de seguridad de ser benignos o duplicados, degradamos automáticamente la gravedad:

if (autoResolutionConfidence >= 7) {
  if (updatedSeverity === 'high' || updatedSeverity === 'critical') {
    await alertsDb.updateAlertSeverity(alert.alertId, 'medium')
  }
}

Vimos una disminución del 20 % en las páginas de llamadas de guardia solo con este cambio.

Con nuestro sistema RAG en marcha, comenzamos a pensar en cuál sería el siguiente paso, que parecía obvio: algún tipo de capa agentic para ayudar con la investigación de alertas y resolver problemas automáticamente.

Adición de una capa agentic encima

Usamos Tines para crear una capa agentic encima de nuestro RAG. Cuando Panther detecta un evento, nuestro manejador de flujo Lambda publica la alerta en Slack con el resumen inicial del LLM y referencias de alertas similares de la capa RAG, y luego etiqueta automáticamente a @Tines seguridad Slackbot en el hilo. Los ingenieros de guardia también pueden etiquetar al bot manualmente en cualquier hilo para invocarlo a demanda y hacer preguntas de seguimiento o obtener otros datos específicos según lo requiera la situación.

Cuando se etiqueta al bot, un webhook se activa en Tines y lo primero que se ejecuta es el enrutamiento de intenciones. Un modelo más ligero (como Claude Sonnet) lee todo el hilo de Slack y clasifica la solicitud: ¿es una clasificación de alertas, una pregunta de seguridad de la plataforma, una consulta de aprobación de aplicaciones o algo más? Cada clasificación está dirigida a un agente especializado con su propio inventario de instrumentos, su nivel de autorización y su notificación del sistema. El agente de clasificación de alertas maneja la mayor parte del trabajo, pero tener agentes separados para diferentes propósitos significa que podemos darle a cada uno un conjunto enfocado de herramientas sin el riesgo de un agente desordenado que tiene acceso a todo.

El kit de herramientas del agente de clasificación de alertas

El agente de clasificación de alertas (utilizando un modelo como Claude Opus) es el que lleva a cabo la mayor parte de la investigación. Recibe el historial completo del hilo de Slack como contexto, su propia memoria de control (más sobre esto más adelante), y un conjunto de herramientas que se ajustan a lo que normalmente necesita un ingeniero de seguridad de guardia durante la clasificación, incluyendo:

• Okta: obtén el perfil de un usuario, enumera sus grupos, verifica el historial de inicio de sesión, busca usuarios por filtro. Cuando se activa una alerta sobre actividad sospechosa de un actor específico, lo primero que suele hacer el agente es extraer su perfil de Okta para entender quiénes son y a qué se supone que deben tener acceso.
• Taller de Seguridad del Polo Norte (que gestiona nuestra herramienta de seguridad de extremo, Santa): reglas de búsqueda, eventos de búsqueda, comprobar el estado de sincronización del host, transicionar reglas a los hosts. Si la alerta involucra un binario bloqueado o una violación de políticas de extremo, el agente puede buscar el ID de firma, verificar el historial de eventos para ese binario y ver si otros usuarios están experimentando el mismo bloqueo.
• Wiz: obtén registros de auditoría, inventario de recursos en la nube, hallazgos de vulnerabilidad, cuestiones abiertas y recursos expuestos. Cuando se trata de alertas de infraestructura en la nube, el agente puede comprobar si un recurso marcado tiene vulnerabilidades conocidas o configuraciones incorrectas.
• Slack: lee las respuesta de los hilos, busca perfiles de usuario, envia actualizaciones de progreso. El agente lee los hilos anteriores que están relacionados con alertas similares para obtener el razonamiento de los ingenieros de guardia de las discusiones pasadas y relacionadas.
• Panther: obtener los datos de alerta, obtener los eventos sin procesar que desencadenaron una alerta, la lista de las alertas relacionadas. De esta forma, el agente puede acceder a la carga de alerta estructurada más allá de lo publicado en Slack.
• Modificación de código: abrir PR en nuestro repositorio de detecciones Panther o en nuestro monorepo. Más sobre esto más adelante.
• El subagente de investigación Panther: un agente autónomo con LLM que puede escribir y ejecutar Snowflake SQL en nuestro lago de datos de seguridad completos. Se trata de la herramienta más potente del conjunto y de la que hablaremos más tarde.

Consulta del lago de datos de seguridad

El agente de clasificación puede responder a muchas preguntas con sus herramientas directas: “¿Quién es este usuario en Okta?”, “¿Qué reglas de Santa se aplican a este binario?”, “¿Es este un recurso en la nube en Wiz?” No obstante, muchas investigaciones han de ir más lejos. ¿Qué estaba haciendo ese usuario en AWS dos horas antes de la alerta? ¿Qué procesos se llevaron a cabo en el extremo e hicieron algo inusual? ¿Accedieron a otras aplicaciones o realizaron cambios de configuración durante ese tiempo?

Para esas preguntas, el agente de clasificación delega a un subagente de investigación independiente. Este subagente (también un modelo como Claude Opus) toma una consulta en lenguaje natural del agente principal y la traduce a Snowflake SQL. Se ejecuta contra nuestro almacén de datos Panther, que consume registros de auditoría de toda la empresa: AWS CloudTrail, registros del sistema Okta, eventos de auditoría de GitHub, registros de auditoría de GCP, telemetría de extremo osquery, eventos de Workshop/Santa, hallazgos de Wiz y alrededor de un centenar de otras tablas.

El agente principal lo llama de la misma manera que le pedirías a un colega que ejecute una consulta: "Encuentra los inicios de sesión más recientes de Okta para el usuario X en las últimas 48 horas" o "Verifica qué procesos ha estado ejecutando el usuario Y en su extremo durante los últimos 2 días" o "¿Qué estaba haciendo el usuario Z en AWS EKS entre las 10:21 y las 20:21 UTC el 10 de marzo?" El subagente determina qué tablas consultar, qué columnas usar y cómo filtrar por tiempo.

Esto funciona, pero los esquemas de tablas pueden ser un poco desordenados. Los nombres de columna son incoherentes entre las fuentes del registro, las claves de enlace no están bien documentadas y las funciones de partición temporal varían según la tabla. Sin ayuda, el subagente emplearía cuatro o cinco consultas solo para descubrir el esquema antes de poder responder la pregunta real. O peor aún, realizar una consulta de manera que devuelva resultados inexactos o incompletos. Veremos cómo resolvimos esto en la sección de memoria que aparece a continuación.

Desarrollo y segmentación de la memoria del agente

La memoria demostró ser el factor más influyente de la utilidad del sistema a lo largo del tiempo. Tenemos varios tipos, y mantenerlos alejados resultó ser importante.

El corpus RAG es lo que se conoce como memoria de casos. Es el sistema que ya hemos descrito: alertas históricas más contexto de investigación de Slack y Asana. Cuando el agente necesita saber cómo eran las situaciones similares, o lo que un ingeniero de guardia concluyó acerca de un incidente anterior, aquí es donde se ve.

Además de esto, tenemos lo que denominamos memoria de direcciones. Se trata de una guía de comportamiento para el agente, almacenada como un documento de marcado que se carga en el contexto del agente al comienzo de cada ejecución. Piensa en él como un archivo AGENTS.md o el modelo de amenazas que un agente escaneando la base de código en busca de vulnerabilidades necesitaría. Contiene reglas como “cuando veas alertas de sincronización de Okta obsoletas, verifica tanto los trabajos de recurso-sincronizar como de grupo-sincronizar antes de concluir que es sistémico” o “el usuario X está haciendo mantenimiento en el sistema Y esta semana, trata esas alertas como esperadas.”

El agente puede actualizar su propia memoria de direcciones cada vez que un ingeniero de seguridad la corrige. Si alguien dice "esto lo gestionaste mal, mejor haz esto otro", la solución persiste para futuras versiones. Pero aprendimos a tener cuidado con lo que entra en la memoria de direcciones en comparación con lo que queda en la capa RAG. Una lección única sobre un tipo específico de alerta debe ir dentro del contexto de la investigación para que parezca un precedente para futuras alertas similares. La memoria de control contiene una regla de comportamiento que debe cambiar la forma en que el agente maneja todas las alertas. Un error inicial fue guardar todo como memoria de control, lo que comenzó a invalidar el comportamiento del agente de manera indeseada. Los precedentes y la política son cosas distintas y pertenecen a lugares distintos.

También utilizamos registros respaldados por bases de datos en Tines para objetos con estado: PR abiertos que el agente ha creado, estado de investigación de Panther, cosas que necesitan claves estables y seguimiento de estado en lugar de recuperación en lenguaje natural. Estos son más triviales pero necesarios.

La capa de memoria más interesante es procesal, y soluciona directamente el problema de descubrir esquemas descritos anteriormente. Dimos al subagente de investigación su propia memoria organizada por etiquetas (aws, okta, osquery, workshop, etc.). Antes de iniciar una consulta, el agente carga las memorias pertinentes para las fuentes de datos a las que va a tener acceso. Después de completar una investigación que requirió el descubrimiento de esquemas, guarda lo que aprendió:

Title: Job Description Fields in Workiva Logs (2026-03-12T16:25:21 UTC)
Memory: Job descriptions for each user within the system can be found within the field 'jd' in the table 'WORKIVA_USERS'.

Un segundo LLM (que usa un modelo liviano) se encarga del formato real de la memoria: toma el hallazgo sin procesar, genera un título con una marca de tiempo UTC, lo etiqueta y escribe la memoria. Cuando le preguntamos al investigador por la actividad de Zoom, necesitó varias consultas de detección. Después de que guardó una memoria, la misma pregunta solo necesitaría una consulta. Esa pauta se repitió en todas las fuentes de datos a medida que el agente elaboraba su propio manual de operaciones mediante pruebas y errores.

Ejemplos de investigaciones de agentes

Para ilustrar cómo funciona el agente en la práctica, he aquí tres ejemplos recientes.

Primero, está el caso de cuando se activa una alerta porque alguien instaló una aplicación de transcripción de audio macOS que no se ha revisado ni aprobado para su uso en Figma. El agente de clasificación leyó el hilo de alerta, extrajo alertas históricas similares de la capa RAG, y luego utilizó sus herramientas de Okta y Workshop para juntar las piezas: ¡El actor era el mismo ingeniero que había creado la regla de detección: yo, Matthew! El taller mostró una regla de un día, de alcance individual, que se había creado para probarla. Conclusión: el autor de la regla estaba probando su propia detección. No se necesita ninguna acción. El agente incluso envió una nota que decía que, de acuerdo con mi estado en Slack, estaba completamente perdido y puede que tarde un tiempo en confirmar mis actividades.

Un caso diferente: las páginas de alerta de Snowflake repetidas seguían activándose para la misma cuenta de servicio. El agente describió el estado actual, delegó al subagente de investigación para consultar los registros de auditoría relevantes, identificó por qué las alertas se estaban repitiendo, encontró que ya se había abierto un PR en borrador para suprimirlas, y explicó la solución a largo plazo que estaba bajo discusión en otro hilo. El ingeniero de guardia consiguió un cuadro completo sin abrir una sola pestaña, que era incomprensible unos meses atrás.

Por último, a menudo emitimos alertas para situaciones que podrían estar relacionadas con malware, pero la mayoría de las veces son comportamientos bastante legítimos (por ejemplo, un servicio de lanzamiento desconocido instalado en MacBook de Figma). En el pasado, esto habría sido impensable; nuestro equipo apoya a miles de Figmates, y rápidamente nos hubiese abrumado el volumen de alertas. Sin embargo, en este nuevo modelo, nuestro agente puede verificar que el binario está firmado por una entidad de confianza, usar la capacidad de consulta de Panther para averiguar cómo se instaló (brew, App Store, etc.) y luego escribir automáticamente los cambios de código necesarios para suprimir la alerta en condiciones seguras conocidas en el futuro, todo sin intervención humana.

De la investigación a los cambios en los códigos

El paso que nos sorprendió más, en términos de cuánto tiempo ahorra, es cuando el agente va de "He descubierto lo que está sucediendo" a "aquí hay un PR que lo corrige".

Hay dos rutas de código. Para realizar cambios en las reglas de detección, las listas de permisos y las eliminaciones de alertas, el agente abre PR en nuestro repositorio de detecciones de Panther. Este es el caso común: una alerta sigue activándose para un patrón benigno conocido, un ingeniero de guardia confirma que es un falso positivo en el hilo de Slack, y el agente genera una entrada en la lista de permitidos o ajusta la regla de detección. Para todo lo demás, como cambios de infraestructura, configuraciones de servicio, configuración de Terraform o RBAC e IdP, el agente trabaja con nuestro monorepo.

Si un revisor deja comentarios en el PR, el agente los recopila a través de un webhook de GitHub y es posible que realice cambios adicionales o responda. También puede reemplazar las ramas viejas con el último máster cuando el PR permanezca abierto por un tiempo.

Barreras de seguridad

Todas las llamadas de herramienta incluyen salvaguardias determinantes para asegurar que el agente no intente hacer algo que no queremos que haga. Por ejemplo, cada solicitud de extracción que crea el agente se configura automáticamente como borrador. Esto se lleva a cabo como un paso posterior determinante en el flujo de trabajo de Tines, no como una instrucción de aviso, porque descubrimos desde el principio que confiar en el LLM para recordar "crear siempre como borrador" no era lo suficientemente fiable.

Usamos este tipo de contrato de llamadas de herramientas para imponer todo tipo de controles de manera determinista, desde asegurar que el agente no recibiera ni procesara información sensible de los empleados al recuperar datos de Okta, hasta garantizar que el agente no intentara cerrar o modificar solicitudes de extracción que no hubiera creado. Debido a que la seguridad de cualquier sistema depende de tener controles en capas, también tuvimos mucho cuidado para asegurar que las herramientas disponibles para el agente estuvieran adecuadamente definidas, autorizadas y monitoreadas, y que el propio agente trabajase en nombre de un miembro del equipo autorizado.

También nos hemos esforzado por contener las consecuencias de un entorno negativo. El agente no tiene acceso al entorno para completar los canales de Slack y, fuera del DM, solo puede leer un subproceso cuando se ha vuelto a etiquetar de forma explícita en el mensaje más reciente.

Por último, nos sentimos mucho más a gusto con la autonomía cuando la acción es limitada, reversible y respaldada por pruebas claras que cuando es amplia, destructiva o difícil de auditar. En la práctica, eso significa que la investigación intensiva en lectura, la detección de duplicados, la recuperación de precedentes y la corrección de borradores encajan mejor para la ejecución agentic que los caminos de escritura genéricos de alta potencia.

Esperamos que una mayor parte de las alertas se manejen automáticamente con el tiempo, pero solo detrás de barreras más estrictas: alcances de acción más estrechos, mejor evaluación (como este ejemplo de construir confianza en agentes de IA a través de métricas), y una procedencia más clara sobre por qué el sistema llegó a una conclusión.

En retrospectiva

Aquí hay algunas cosas que haríamos de manera diferente si comenzáramos desde cero:

• La memoria de procedimiento debería haber estado presente desde el principio. La memoria de esquema autoconstruida del agente de investigación fue una adición tardía, y la mejora fue tan dramática que todo lo anterior parece casi trabajo desperdiciado en retrospectiva.
• La configuración como código es esencial para evitar que la capa de agente se fragmente. Dado que los miembros del equipo quieren iterar rápidamente, al final, terminas con personas que crean y operan con copias ligeramente diferentes del mismo agente principal con configuraciones de herramientas ligeramente diferentes, utilizadas para propósitos diferentes. Como te puedes imaginar, se vuelve muy difícil garantizar que todas las herramientas disponibles para estos agentes sean coherentes y funcionen de la misma manera. Hoy, nuestro kit de herramientas básico ahora se configura y gestiona fuera de cualquier agente, en configuración como código, asegurando que todos los agentes puedan beneficiarse de un conjunto de acciones estandarizado y bien mantenido.
• Si vas a crear un agente para que se integre con Slack, el modelo de confianza para los canales públicos merece que se le preste atención. Nuestros agentes tienen controles de autorización para asegurar que solo los miembros del equipo de seguridad puedan comandarlos, pero si un agente decide buscar a través de registros detallados de actividad de usuarios, podrían surgir todo tipo de datos sensibles. Los datos que describen la actividad de un usuario ese día están completamente bien en un hilo de seguridad privada, pero se convierte en un gran problema en una sala con un centenar de personas. Manejamos esto a través de un diseño de alerta sensible al canal y otros controles deterministas, pero es el tipo de cosa que desea diseñar de antemano en lugar de añadirlo más adelante.

Dónde estamos ahora y qué nos depara el futuro

El sistema se encarga de todos los trabajos de respuesta de seguridad inicial de los equipos. El trabajo del ingeniero de guardia pasó de "investigar desde cero" a "revisar lo que el agente encontró, confirmar o corregir, y tratar casos que requerían un juicio humano".

Hemos visto una reducción del 70 % en el tiempo de resolución de alertas complejas, una reducción del 20 % en las páginas de llamadas de emergencia gracias a la bajada de categoría de la severidad impulsada por la IA, un 25 % menos de solicitudes de aprobación de software de extremo (el agente detecta cuando un usuario está preguntando sobre una herramienta y los dirige a alternativas aprobadas comparables), y un aumento significativo en la confianza de los ingenieros de guardia en la calidad de la resolución porque la cadena de evidencia del agente es explícita y revisable.

Dentro de un año, el sistema habrá interiorizado miles de decisiones de clasificación, asignaciones esquemáticas y correcciones de comportamiento que nadie en el equipo podría mantener en su cabeza. Eso es lo que más nos entusiasma: no una sola ejecución de agente, sino el hecho de que cada ejecución hace que la siguiente sea más económica y precisa.

Gran parte de la próxima fase trata sobre la construcción de un mejor plano de control en torno al modelo. Queremos establecer distinciones más claras entre nuestros niveles de memoria para precedente, política y estado. Queremos mejores maneras de decidir cuándo es seguro cerrar automáticamente una alerta y cuándo es necesario ampliarla, incluso si el modelo parece seguro. Y queremos que nuestros flujos de trabajo pasen de un comportamiento rápido a una automatización determinista e inspeccionable.

Una nota final: hay mucho debate sobre si vale la pena usar IA para investigar problemas, porque la IA no es perfecta. Pero los humanos tampoco lo son. Creemos que no es una elección entre humanos o IA. En cambio, hay muchas cosas que pueden hacerse entre estos dos extremos para reducir el riesgo y mejorar la eficiencia, y el manual todavía se está redactando.

Estamos entusiasmados y orgullosos de lo que hemos construido, pero sabemos que esto es solo el comienzo de un viaje más largo con una gran cantidad de promesas y posibles dificultades. Si hay otros equipos construyendo sistemas similares, ¡contáctenos! Nos encantaría comparar notas.