Saltar al contenido
PhiloCyber logo
Trabajo con clientes / Anonimizado

Prueba, no promesas.

Cuatro trabajos, anonimizados por contrato y por diseño. Se quitaron los detalles que podrían identificar a un cliente; lo que queda es la forma del problema, el trabajo y las clases de resultado — para que puedas juzgar cómo opero sin que la confidencialidad de nadie pague el costo.

  1. C/01

    Pentest de una aplicación LLM, antes de que fuera una categoría

    Early mover · 2023

    Ver el servicioHablemos de tu sistema

    Situación

    Un chatbot LLM de cara al público, a semanas del lanzamiento, construido para responder preguntas desde datos institucionales. El equipo había probado calidad y precisión — nadie lo había probado adversarialmente.

    Restricción y anonimización

    Anonimizado quitando geografía y detalle institucional; la fecha (principios de 2023) se mantiene a propósito — es el punto de este caso. Fue una de las primeras evaluaciones ofensivas sobre una aplicación LLM, unos dos años antes de que la mayoría de las firmas sumara “IA” a su página de pentesting.

    Enfoque

    1. 01Autorización escrita con scope y un espejo no-productivo del chatbot antes de cualquier prueba
    2. 02Testing adversarial manual de la capa conversacional: prompt injection directa e indirecta, extracción del system prompt, exfiltración de datos a través del modelo
    3. 03Cada hallazgo candidato reproducido dos veces y encadenado a su impacto de negocio antes de entrar al reporte

    Clases de hallazgos

    • Caminos de prompt injection que anulaban las instrucciones del sistema y reorientaban al asistente
    • Divulgación de información sensible: el modelo podía ser guiado a revelar datos fuera del alcance previsto
    • Falta de manejo de salidas y de límites de tasa que convertía el mal comportamiento del modelo en riesgo para el usuario

    Clases de resultado

    • El lanzamiento salió sobre una superficie de ataque corregida en lugar de una sin probar
    • Los hallazgos se convirtieron en el primer argumento concreto de la organización para una revisión de IA pre-lanzamiento
    • Remediación validada en retest, con evidencia de cierre presentable ante stakeholders

  2. C/02

    Construir capacidad interna de AI security, no una dependencia

    Programa de enablement

    Ver el servicioHablemos de tu sistema

    Situación

    Una organización de ingeniería lanzando features con GenAI sin expertise interno en seguridad de IA. El plan por defecto de la dirección era “contratar internamente eventualmente” — y lanzar sin probar hasta entonces.

    Restricción y anonimización

    Anonimizado quitando industria y fecha. Este caso existe para responder una objeción: “vamos a construir esta capacidad nosotros mismos.” Exactamente — ese es el producto.

    Enfoque

    1. 01Serie de workshops construida sobre la arquitectura del propio equipo, no slides genéricos: sus agentes, sus herramientas, sus flujos de datos
    2. 02Baseline de desarrollo seguro para features de IA: qué revisar antes del merge, qué escalar, qué no lanzar nunca
    3. 03Labs hands-on donde los ingenieros atacaron réplicas sanitizadas de sus propios sistemas y leyeron hallazgos reales

    Clases de hallazgos

    • La intuición de amenazas del equipo era fuerte en AppSec clásico y nula en abuso de la capa del modelo
    • Sin vocabulario compartido para riesgo de IA: “¿esto del prompt injection es real?” era debate abierto
    • Había caminos de revisión para código, ninguno para prompts, herramientas o comportamiento del modelo

    Clases de resultado

    • El equipo interno hoy corre la revisión de seguridad de IA de primer paso sobre sus propias features
    • El tiempo del especialista queda reservado para lo que realmente es: validación adversarial, no higiene básica
    • La pregunta “contratar vs. comprar” se resolvió en “construir internamente, validar externamente” — la configuración duradera

  3. C/03

    Evaluación de sistema multi-agente y MCP en producción

    Flagship · agentes + MCP

    Ver el servicioHablemos de tu sistema

    Situación

    Un sistema multi-agente en producción actuando a través de integraciones de herramientas MCP: un orquestador delegando en agentes especializados, con herramientas capaces de leer y actuar sobre datos de negocio reales.

    Restricción y anonimización

    Anonimizado quitando industria y fecha. Los sistemas agénticos suelen construirse in-house — ningún scanner vio jamás el tuyo — así que este caso se mantiene al nivel de clases de arquitectura y cadenas de ataque.

    Enfoque

    1. 01Threat modeling de la topología de agentes primero: fronteras de confianza entre orquestador, agentes, policy gates y servidores MCP
    2. 02Testing adversarial de cadenas de herramientas: qué podía ser inducido a hacer un agente, con permisos de quién, sobre datos de quién
    3. 03Revisión de identidad y autorización en la frontera agente-herramienta, donde vivía la mayor parte de la exposición real

    Clases de hallazgos

    • Agencia excesiva: permisos de herramientas más amplios que el trabajo real del agente, convirtiendo manipulación de prompts en acciones consecuentes
    • Prompt injection indirecta a través de contenido recuperado que cruzaba la frontera de confianza sin inspección
    • Brechas de autorización entre la capa de agentes y la capa de herramientas — cada lado asumía que el otro verificaba

    Clases de resultado

    • Cadenas de explotación validadas y encadenadas con impacto de negocio adjunto — no una lista de hallazgos teóricos
    • Roadmap de remediación dividido en fixes rápidos y cambios arquitectónicos, dimensionado para el equipo que tenía que ejecutarlo
    • Evidencia de cierre confirmada en retest, usable frente a clientes y auditores

  4. C/04

    Política de seguridad de IA y gobernanza desde cero

    Construcción de gobernanza

    Ver el servicioHablemos de tu sistema

    Situación

    Una empresa ya lanzando features con GenAI — y con empleados ya usando shadow AI — sin inventario, sin ownership y sin reglas. El disparador fue externo: clientes y auditores empezaron a hacer preguntas que nadie podía responder.

    Restricción y anonimización

    Anonimizado quitando industria. La gobernanza nunca se vende como programa en frío: arrancó con un diagnóstico pago, y el cliente podía irse con el roadmap. Se quedó para la construcción.

    Enfoque

    1. 01Diagnóstico pago primero: scoring guiado por cuestionarios sobre las dimensiones de gobernanza, luego entrevistas dirigidas a stakeholders
    2. 02Arquitectura de políticas: inventario de IA incluyendo shadow AI, reglas de uso aceptable y manejo de datos que la gente realmente seguiría
    3. 03Diseño del camino de revisión: revisión de seguridad pre-lanzamiento para features de IA, con modelos de evidencia mapeados a los frameworks que citan sus clientes

    Clases de hallazgos

    • Uso de IA mucho más amplio de lo que la dirección creía — el inventario fue la primera imagen honesta
    • Existían políticas sobre papel en áreas adyacentes, pero nada enforceado ni con dueño para IA
    • Exposición a vendors y IA de terceros sin cuestionario, sin evidencia, sin responsable

    Clases de resultado

    • Un programa de gobernanza funcionando con dueños nombrados — readiness, no teatro de certificación
    • Las preguntas de clientes y auditores ahora se responden con evidencia en lugar de disculpas
    • Una cadencia de re-score trimestral que hace visible el movimiento de postura a los ejecutivos que lo financian

Tu sistema podría ser el próximo.

Cada trabajo corre bajo las mismas reglas: scope escrito antes del acceso, especialista nombrado de punta a punta, evidencia anonimizada por defecto.

Contame qué estás construyendo
Casos de estudio | PhiloCyber