---
type: OUT
asset_id: OUT-EL-SOO-Wargame-ConnectorX-Resultados-v01
version: v01
tipo: OUT — Resultados de proceso (wargame adversarial)
status: 🟡 Draft v01 · corrido con Fable 5 como BLANCO (7-jul-2026) · pendiente segunda pasada adversarial (Opus, foco en celdas ✅) · pendiente ratificación Victor (L3+)
owner: Victor Heredia
sherpa: Jay
corrio_el_room: Alex + SherpaX (Fable 5)
ratificador: Victor Heredia (L3+)
intellibank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank / PB-SOO-SistemaOperativoOrganizacional
proceso_fuente: SP-EL-SOO-Wargame-ConnectorX-Fable5-v01
insumos:
  - MAP-EL-SOO-EcosistemaProyectado-v01 (§4 Órbita 3, §9 benchmark)
  - Búsqueda externa fresca 7-jul-2026 (estado MCP/AAIF, incidentes de seguridad, Agentforce/Copilot/Agent 365, MCP vertical logística) — fuentes al pie
gate_g0: PASS · deriva del SP y el MAP; paisaje de amenaza con datos reales, no inventados
fecha_creacion: 2026-07-07
tags: [OUT, wargame, connectorx, mcp, conectores, orbita3, soo, resultados, adversarial]
---

# OUT · Wargame ConnectorX — Resultados
## La apuesta MCP-native + ConnectorX Registry bajo fuego de 5 células

> **Pregunta central que decidió la partida:** ¿la apuesta sobrevive a un mundo hostil —estándar que se mueve, competidores que comoditizan, seguridad que se rompe, verticales sin conector— sin rediseñar la arquitectura? ¿Y el Registry conserva valor defendible aunque los conectores base sean gratis?
>
> **Veredicto global del BLANCO:** la apuesta **sobrevive sin rediseño** (la arquitectura curar+gobernar es correcta y el mundo 2026 la valida), pero el wargame encontró **2 huecos rojos y 3 amarillos** que deben cerrarse en el SPEC del ConnectorX Registry — sobre todo en **admisión supply-chain** (R3) y **posicionamiento vs registries de plataforma** (R2). El moat NO está en el registry como feature: está en gobernanza cross-plataforma + outcomes auditables + el nicho instancia-equipo que los hyperscalers no persiguen.

---

## R0 · Encuadre (BLANCO + VERDE)

**Condiciones de victoria de AZUL (del SP):** V1 resiliencia de estándar · V2 cero exfiltración · V3 moat pese a gratis · V4 cobertura vertical (Posta) · V5 switching cost real.

**Supuestos del diseño AZUL en juego:** curar no fabricar; ConnectorX Registry (registry + auth + audit + HITL); autonomía por clase (leer=L2, escribir=L1, borrar=lista negra + kill-switch); el conector es un objeto gobernado con tripleta.

**Estado real del ecosistema (VERDE · verificado 7-jul-2026):**

- **El estándar ganó y está gobernado multi-vendor:** MCP donado a la Agentic AI Foundation (Linux Foundation) en dic-2025, con OpenAI y Block como co-fundadores y AWS, Google, Microsoft, Cloudflare y Bloomberg como miembros platinum. A julio 2026: **78% de equipos enterprise con agentes MCP en producción, 28% del Fortune 500 corriendo servers MCP, ~97M descargas mensuales de SDK, 10,000+ servers públicos**. Soporte nativo en Claude, ChatGPT, Gemini, Copilot y Cursor.
- **Pero el protocolo sigue moviéndose:** el release candidate 2026-07-28 vuelve el protocolo **stateless** — cambio estructural que afecta cómo se despliegan y balancean los servers. El estándar es estable como apuesta, **inestable como superficie técnica**.
- **La seguridad MCP está en crisis abierta:** flaw de diseño en el SDK oficial (divulgado abril 2026, OX Security) con RCE potencial en ~200,000 instancias y 150M+ descargas afectadas; 30+ CVEs en una ventana de 60 días con CVE-2026-33032 (CVSS 9.8) explotado activamente; operación **SmartLoader**: 3 meses construyendo un ecosistema developer falso para colar un server MCP troyanizado (Oura Ring) con infostealer; 492 servers MCP expuestos a internet **sin autenticación**; 82% de servers vulnerables a path traversal y **solo 8.5% usa OAuth**; 88% de organizaciones reportan incidentes de agentes confirmados o sospechados en el último año.
- **Los hyperscalers ya venden "registry gobernado":** Microsoft **Agent 365** con Registry sync (mayo 2026) inventaría agentes cross-plataforma — Agentforce y Databricks Genie ya conectados; **Federated Copilot Connectors** GA (mayo 2026) trae datos de SAP/Salesforce/ServiceNow sin mover data; 300+ conectores certificados con admin center dedicado. Agentforce gobierna nativo dentro de Salesforce (FLS, sharing rules, audit).
- **El vertical logístico ya tiene MCP real:** Shipwell opera un **MCP server de TMS production-grade**; los TMS líderes 2026 empiezan a traer MCP de fábrica; 4,000+ servers en registries para SaaS/enterprise. El "no hay qué curar" se está cerrando — en el mundo anglo. El stack LATAM (arquetipo Posta, CONTPAQi-adyacente) va atrás.

---

## Rondas — jugada Roja · respuesta Azul · shock Verde · fallo del Juez

### R1 · Riesgo de estándar — "MCP se mueve debajo de tus pies"

**Jugada Roja:** no ataco con el fork clásico (la AAIF multi-vendor lo hace improbable: los 5 hyperscalers ya están DENTRO de la fundación). Ataco con el **drift del protocolo**: el RC 2026-07-28 (stateless) obliga a re-desplegar servers; tu Registry curó 40 conectores contra la spec de marzo y en agosto la mitad corre en modo legacy. *Segundo orden:* los mantenedores de servers chicos no migran, sus servers quedan abandonados → tu catálogo curado envejece solo.

**Respuesta Azul:** curar-no-fabricar nos protege del fork (curamos lo que gane, quien gane), y la gobernanza AAIF con OpenAI/Google/MS/AWS dentro hace la captura unilateral casi imposible — V1 aguanta en su núcleo. **Concedo parcialmente el drift:** el diseño actual no tiene política de versión de protocolo por conector.

**Shock Verde:** regulación de data-residency LATAM exige saber dónde procesa cada conector — los servers legacy no lo reportan.

**Fallo del Juez: 🟨 PARCIAL.** La apuesta estratégica es correcta (no reescribir nada si el estándar gira), pero el Registry necesita **version-pinning + estado de mantenimiento** como atributos de primera clase de cada conector aprobado. Sin eso, la curaduría se pudre en silencio. → Hueco H3.

### R2 · Comoditización — "Microsoft te regala tu producto"

**Jugada Roja (la más fuerte de la partida):** Agent 365 YA es un registry de agentes cross-plataforma con sync a Agentforce; Copilot trae 300+ conectores certificados gratis con su licencia; Salesforce gobierna nativo. El CIO pregunta: *"¿por qué pago un ConnectorX Registry aparte si mi plataforma lo incluye?"* *Segundo orden:* los partners (Órbita 4) prefieren certificarse en Microsoft, que les da pipeline.

**Respuesta Azul:** tres capas que el hyperscaler no cubre: (1) **cross-plataforma real** — Agent 365 gobierna el universo Microsoft y sus aliados; el mid-market LATAM vive en mezclas (WhatsApp Business + CONTPAQi + Sheets + un TMS local) que ningún admin center de Redmond inventaría; (2) **outcomes, no inventario** — su registry lista agentes; el nuestro liga cada conector a ritmos WORX, tripleta, ROI Tracker: gobernanza que audita *resultados*, no existencia; (3) **arquetipo** — MS/SF venden por seat al enterprise; WorX vende instancia-equipo al mid-market (§6 del MAP). **Concedo:** como producto standalone, el Registry pierde contra "gratis en la plataforma".

**Shock Verde:** Microsoft baja Agent 365 al SMB con bundle de M365 — el argumento "ellos solo van al enterprise" se erosiona en 2027.

**Fallo del Juez: 🟨 PARCIAL.** La defensa técnica es real pero el **posicionamiento** es el hueco: el ConnectorX Registry NO puede venderse ni narrarse como producto separado — es una capacidad del SOOI. Si el pitch dice "registry", ya perdimos. → Hueco H2 (decisión de pricing/naming para Victor).

### R3 · Brecha de seguridad — "tu curaduría es teatro"

**Jugada Roja:** SmartLoader construyó 3 meses de reputación falsa antes de trojanizar — tu "curaduría" por reputación del mantenedor cae exactamente ahí. Peor: el flaw del SDK oficial (abril 2026) significa que un conector **legítimo y bien mantenido** puede ser RCE-able por diseño; curarlo no lo arregla. Con solo 8.5% de servers usando OAuth, tu catálogo curable-real es minúsculo o inseguro. *Segundo orden:* un incidente en UN cliente (exfiltración vía conector aprobado) mata la palabra "gobernado" de todo el portafolio — riesgo existencial de marca, no técnico.

**Respuesta Azul:** la **contención** sí está diseñada: autonomía por clase (leer=L2, escribir=L1 con HITL, borrar=lista negra), kill-switch por conector, audit trail. Un conector comprometido no puede borrar y sus escrituras pasan por humano. **Concedo el frente de admisión:** el diseño actual dice "registry de conectores aprobados" pero no define QUÉ aprueba — no hay verificación de procedencia, ni pinning por hash, ni auditoría de versión de SDK, ni sandbox de egreso. Contra SmartLoader, hoy, entraríamos.

**Shock Verde:** el Pentágono clasifica proveedores de agentes como riesgo de supply-chain; el enterprise LATAM copia el discurso y pide evidencia de admisión formal en cada RFP.

**Fallo del Juez: 🟥 HUECO (admisión) / ✅ CUBIERTA (contención).** La mitad runtime del diseño aguanta; la mitad supply-chain no existe todavía. El criterio de admisión al Registry es LA pieza que el SPEC debe traer — y paradójicamente, la crisis de seguridad MCP 2026 es el mejor argumento de venta del Registry si la cerramos. → Hueco H1 (el más severo) + Regla de decisión C3.

### R4 · Hueco vertical — "el TMS de Posta no tiene MCP"

**Jugada Roja:** Shipwell tiene MCP server production-grade... y Posta no usa Shipwell. El stack logístico LATAM (TMS/WMS regional, a veces on-premise) no está en los 10,000 servers. "Curar" falla porque no hay qué curar; "fabricar" contradice tu apuesta. *Segundo orden:* cada vertical LATAM repetirá esto — tu arquetipo prioritario vive exactamente donde el ecosistema MCP es más flaco.

**Respuesta Azul:** la apuesta nunca fue "solo curar" — el MAP ya prevé Vertical Packs saliendo del caso Posta. La respuesta es la **regla Curar/Adaptar/Build-mínimo** (Regla C1): si el sistema tiene API, un **wrapper MCP delgado** (adaptar) cuesta días, no meses — el estándar es justamente lo que hace barato fabricar la última milla sin volverse fabricante de conectores. El wrapper de Posta se vuelve el primer activo del Vertical Pack logística: el hueco es negocio, no amenaza.

**Shock Verde:** los TMS 2026 líderes empiezan a traer MCP de fábrica — la ventana en la que "adaptar" es diferenciador se cierra en ~18 meses; después es commodity.

**Fallo del Juez: 🟨 PARCIAL → ✅ con la Regla C1 fijada.** El diseño cubre el caso si y solo si la regla de decisión existe con umbrales explícitos y el wrapper entra al Registry por el mismo pipeline de admisión que un server externo (mismo rigor, cero excepciones "porque es nuestro").

### R5 · Economía / BYO — "tu gobernanza es fricción"

**Jugada Roja:** el cliente sofisticado llega con sus propios servers MCP (los bajó gratis, 97M/mes) y ve tu Registry como peaje burocrático. El partner implementador lo secunda: la gobernanza le alarga el proyecto. *Segundo orden:* los clientes usan WorX OS con conectores no-registrados "temporalmente" → el shadow-IT interno vacía el Registry y el switching cost se evapora.

**Respuesta Azul:** BYO no se bloquea — se **absorbe**: cualquier conector del cliente entra por el pipeline de admisión (C3) y queda gobernado igual; el Registry es un servicio de gobernanza sobre conectores de cualquier origen, no un catálogo cerrado. El switching cost real no es el conector (commodity): es el **historial** — audit trail, outcomes en ROI Tracker, autonomía calibrada por meses de operación. Eso no se exporta a Copilot. **Concedo:** si la admisión tarda semanas, el "temporalmente sin registrar" gana; la admisión debe ser autoservicio con LabPraxis en horas.

**Shock Verde:** 88% de organizaciones con incidentes de agentes en el año — el CFO que ayer llamaba "fricción" a la gobernanza hoy la exige por el seguro cibernético.

**Fallo del Juez: 🟨 PARCIAL.** La tesis del moat-por-historial es sólida y el viento regulatorio sopla a favor, pero exige que (a) la admisión BYO sea rápida y autoservicio, y (b) el modo "conector no gobernado" NO exista en el producto — ni siquiera temporal. → Hueco H4.

---

## SALIDA A · Matriz de resiliencia (células × condiciones de victoria)

| | V1 estándar | V2 exfiltración | V3 moat | V4 vertical | V5 switching |
|---|---|---|---|---|---|
| **R1 estándar** | 🟨 (drift/pinning) | — | ✅ (curar sobrevive fork) | 🟨 (servers abandonados) | — |
| **R2 comoditización** | — | — | 🟨 (posicionamiento, no feature) | — | 🟨 (partners se van a MS) |
| **R3 seguridad** | — | 🟥 admisión / ✅ contención | ✅ (la crisis vende gobernanza) | — | — |
| **R4 vertical** | — | — | — | 🟨→✅ (con Regla C1) | ✅ (wrapper = activo propio) |
| **R5 BYO** | — | 🟨 (shadow-IT) | 🟨 (historial no exportable) | — | 🟨 (si admisión es lenta) |

**Lectura:** ninguna célula tumba la arquitectura (cero rediseños). Los rojos/amarillos se concentran en **admisión** y **posicionamiento** — piezas del SPEC y del pitch, no del diseño estructural. La apuesta MCP-native queda **confirmada**.

## SALIDA B · Huecos priorizados (severidad × probabilidad)

| # | Hueco | Sev × Prob | Dueño | Mitigación |
|---|---|---|---|---|
| **H1** | **No existe criterio de admisión supply-chain** (procedencia, pinning por hash, versión de SDK parchada, sandbox de egreso). SmartLoader entraría hoy. | 🔴 Alta × Alta | Alex (SPEC técnico) + Jay | Regla C3 al SPEC del Registry como sección obligatoria; ningún conector (ni propio) entra sin pasar el pipeline. |
| **H2** | **Posicionamiento vs registries de plataforma**: como producto standalone pierde contra "gratis en el bundle". | 🔴 Alta × Alta | Victor (decisión de negocio) | El Registry se vende/narra como capacidad del SOOI (gobernanza + outcomes), nunca como SKU aparte. Decidir ANTES del pitch de H1. |
| **H3** | **Drift de protocolo**: sin version-pinning ni estado de mantenimiento por conector, el catálogo curado envejece en silencio (RC stateless 2026-07-28 lo demuestra). | 🟡 Media × Alta | Alex | Atributos `protocol_version`, `pinned_hash`, `maintenance_status` en el objeto conector; re-validación programada (patrón TTL, como el `true_map`). |
| **H4** | **Shadow-IT de conectores**: si la admisión BYO es lenta, el cliente opera "temporalmente" sin gobernanza y el moat se vacía. | 🟡 Media × Media | Alex + Equipo WORX | Admisión autoservicio con LabPraxis en horas; el producto no ofrece modo no-gobernado. |
| **H5** | **Fuga de partners a certificaciones de hyperscaler** (Órbita 4 secuestra Órbita 3). | 🟡 Media × Media | Victor/Anahí | Certificación WorX incluye lo que MS no da: outcomes auditados por el propio OS como credencial del partner. |

## SALIDA C · Reglas de decisión que el wargame obliga a fijar

**C1 · Curar / Adaptar / Build-mínimo (árbol para verticales · disparado por R4/Posta):**
1. ¿Existe server MCP mantenido (commit <90 días) que pase admisión C3? → **CURAR** (registrar, pinnear, gobernar).
2. ¿No existe, pero el sistema expone API estable? → **ADAPTAR**: wrapper MCP delgado (solo las operaciones que el Motor necesita, por clase de autonomía), que entra al Registry por el MISMO pipeline C3. Presupuesto: días. El wrapper es activo del Vertical Pack.
3. ¿Sin API (pantallas, archivos, EDI viejo)? → **BUILD-MÍNIMO** solo si el caso lo paga como parte del Kit (nunca especulativo) y con fecha de revisión: si el vendor saca MCP nativo, se migra a CURAR.
4. Regla de salida: todo ADAPTAR/BUILD se re-evalúa cada 6 meses contra el ecosistema (la ventana commodity de ~18 meses del shock R4).

**C2 · Autonomía por clase de operación — confirmada con 2 ajustes:**
- Se confirma: **leer=L2 · escribir=L1 con HITL · borrar=lista negra + kill-switch por conector**.
- Ajuste 1 (por R3): las **lecturas** de clases con datos sensibles (ERP/finanzas, CRM con PII) suben a L1 la primera vez que un conector nuevo las ejecuta ("primera lectura auditada"), luego L2. La exfiltración entra por lecturas, no solo escrituras.
- Ajuste 2 (por shock R1): cada conector declara **residencia de procesamiento** (dónde corre el server); operaciones cross-frontera con datos regulados requieren HITL sin importar la clase.

**C3 · Criterio de admisión al Registry (la pieza que cierra H1) — un conector es "aprobado" solo si:**
1. **Procedencia verificable**: fuente oficial del vendor o repo con historia real (edad, contribuidores, releases — anti-SmartLoader; la reputación reciente NO basta).
2. **Pinning**: versión + hash fijados; actualización = re-admisión (rápida, pero nunca automática).
3. **SDK sano**: versión del SDK MCP ≥ la parchada contra el flaw de abril 2026; sin CVEs abiertos críticos.
4. **Auth real**: OAuth/credenciales gestionadas por la capa Identity/Security del OS — nunca tokens planos en config (recordar: solo 8.5% del ecosistema usa OAuth; esto descalifica mucho catálogo, y está bien).
5. **Sandbox de egreso en LabPraxis**: el conector corre en cuarentena observada; se registra a dónde intenta hablar; egress allowlist resultante viaja con el objeto conector.
6. **Audit trail nativo**: toda operación queda atribuida (usuario, conector, clase, veredicto) — mismo patrón de atribución del ARQ IntelliBanks.
7. **Tripleta**: Owner + Sherpa + Ratificador del conector, como cualquier activo.

## SALIDA D · Input directo a los NEXTs del MAP

- **SPEC del ConnectorX Registry (MAP §11):** incorporar C3 como sección obligatoria (admisión), C2 como matriz de autonomía (con los 2 ajustes), H3 como atributos del objeto conector, y H4 como requisito de UX (admisión autoservicio). El argumento de venta del SPEC es la crisis de seguridad MCP 2026 con datos citados — la gobernanza dejó de ser fricción, es lo que el mercado pide con 88% de incidentes.
- **"Validar Órbita 3 contra caso Posta" (MAP §11):** cerrar con hallazgo, no supuesto — inventariar el TMS/WMS real de Posta contra el árbol C1: si tiene API → ADAPTAR (wrapper, días, primer activo del Vertical Pack logística); el wrapper entra por C3 sin excepción.
- **Decisión §10.3 de Victor (confirmar apuesta MCP-native):** el wargame la **confirma con evidencia** — 78% enterprise, AAIF multi-vendor, fork improbable. Recomendación: ratificar, condicionada a cerrar H1 y H2 antes del primer pitch externo.
- **Órbita 4 (partners):** añadir H5 al diseño del Rally de Certificación — la credencial diferencial es outcomes auditados por el OS.

---

## Cierre del BLANCO

La apuesta entra al wargame como hipótesis y sale como **decisión defendible con condiciones**: la arquitectura no requiere rediseño; el SPEC del Registry requiere las 3 reglas (C1–C3); el negocio requiere una decisión de posicionamiento (H2) que es de Victor, no de ingeniería. La ironía útil de la partida: **el peor enemigo técnico de la apuesta (la crisis de seguridad MCP) es su mejor argumento comercial** — pero solo si la admisión C3 existe de verdad. Un Registry sin C3 es exactamente el "teatro de gobernanza" del que acusó R3.

**Pendiente obligado (regla del SP):** segunda pasada con **Opus** atacando las celdas ✅ de la matriz — en particular "la contención aguanta" (R3) y "curar sobrevive el fork" (R1), donde este BLANCO pudo ser auto-complaciente.

---

## Fuentes externas (paisaje VERDE · consultadas 7-jul-2026)

- [Linux Foundation — formación de la AAIF (MCP, goose, AGENTS.md)](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation)
- [Anthropic — donación de MCP a la AAIF](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation)
- [MCP Enterprise Adoption — July 2026 State of Play](https://andrew.ooo/answers/mcp-model-context-protocol-enterprise-adoption-july-2026/)
- [AAIF — MCP Is Growing Up (RC 2026-07-28, stateless)](https://aaif.io/blog/mcp-is-growing-up/)
- [The Hacker News — flaw de diseño del SDK MCP (RCE, abril 2026)](https://thehackernews.com/2026/04/anthropic-mcp-design-vulnerability.html)
- [CSA — MCP Security Crisis: Systemic Design Flaws](https://labs.cloudsecurityalliance.org/research/csa-research-note-mcp-security-crisis-20260504-csa-styled/)
- [Practical DevSecOps — MCP Security Statistics 2026](https://www.practical-devsecops.com/mcp-security-statistics-2026-report/)
- [UpGuard — Six MCP Security Incidents (SmartLoader et al.)](https://www.upguard.com/blog/mcp-security-incidents)
- [Microsoft — What's New in Agent 365, May 2026 (Registry sync)](https://techcommunity.microsoft.com/blog/agent-365-blog/what%E2%80%99s-new-in-agent-365-may-2026/4516340)
- [Smartbridge — Agentforce vs Copilot Studio 2026](https://smartbridge.com/salesforce-agentforce-vs-microsoft-copilot-studio-2026-comparison/)
- [Microsoft Learn — Copilot connectors overview (Federated Connectors GA)](https://learn.microsoft.com/en-us/microsoft-365/copilot/connectors/overview)
- [Shipwell — MCP Server de TMS production-grade](https://www.shipwell.com/blog/what-is-an-mcp-server-shipwell-gives-your-ai-a-tms-brain)
- [LogiAI — MCP Logistics at 97M Installs](https://logiai.blog/2026/04/03/mcp-97-million-installs-integration-layer-logistics/)

---

## NEXTs

- [ ] **Jay/equipo** — segunda pasada adversarial con Opus sobre las celdas ✅ (R3-contención y R1-fork).
- [ ] **Victor** — ratificar este OUT + decidir H2 (Registry como capacidad del SOOI, no SKU) + confirmar §10.3 del MAP condicionada a H1/H2.
- [ ] **Alex** — volcar C1/C2/C3 + H3/H4 al `SPEC del ConnectorX Registry` (NEXT del MAP §11).
- [ ] **Equipo** — inventario del TMS/WMS real de Posta contra el árbol C1 (cierra "Validar Órbita 3 contra caso Posta").
- [ ] **Victor/Anahí** — incorporar H5 al diseño del Rally de Certificación de Implementadores.

---

## CHANGELOG
| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-07 | Creación. Wargame corrido con Fable 5 como BLANCO según SP-EL-SOO-Wargame-ConnectorX-Fable5-v01: R0 con paisaje externo real (AAIF, crisis de seguridad MCP 2026, Agent 365/Federated Connectors, MCP logístico), 5 rondas Rojas con shocks Verdes, matriz de resiliencia 5×5, 5 huecos priorizados (H1 admisión supply-chain y H2 posicionamiento como rojos), 3 reglas de decisión (C1 curar/adaptar/build, C2 autonomía ajustada, C3 admisión de 7 puntos) y salida D a los NEXTs del MAP. Veredicto: apuesta confirmada sin rediseño, condicionada a H1+H2. |