Cada oración era cierta. El sistema seguía siendo inseguro.
La versión corta: cada oración de la sección de seguridad era cierta, y el sistema seguía siendo inseguro. La precisión y la seguridad son propiedades distintas. Las revisiones deben atacar el texto, no leerlo.
La skill de Airtable sobre la que construimos nuestra práctica tiene una sección sobre portales multi-tenant, es decir, varios clientes atendidos sobre la misma base: cómo darle a un cliente una vista de sus propios registros sin exponer los de nadie más. Antes de publicarla, esa sección pasó todas las verificaciones que sabíamos correr. Cada oración era factualmente cierta. La leímos tres veces. Un ingeniero cuidadoso podría haberla seguido y sentirse responsable al hacerlo.
Aun así describía un sistema que filtraba datos.
Esa brecha, entre un texto que es cierto y un texto que es seguro de seguir, es lo más útil que aprendimos construyendo la skill. También es la razón por la que nuestro trabajo con clientes pasa por una compuerta que la mayoría del trabajo de entrega nunca ve.
Dos propiedades distintas
Tendemos a tratar "preciso" y "seguro" como la misma virtud. En documentación, y en diseño de sistemas, no lo son. Una oración es precisa si corresponde a la realidad. Un procedimiento es seguro de seguir si, cuando una persona competente lo ejecuta exactamente como está escrito, el resultado no puede quedar equivocado en silencio.
Se puede escribir un párrafo donde cada afirmación es cierta y cada lector que lo sigue construye un hueco. La verdad de las oraciones individuales no hace nada por cerrar el hueco, porque el peligro vive en lo que las oraciones dejan sin decir: el comportamiento por defecto, la ruta de error, el alcance de un token. La corrección de estilo encuentra oraciones falsas. No encuentra oraciones ciertas que suman una instrucción insegura.
Así que dejamos de leer la sección de seguridad y empezamos a atacarla. La regla era estricta. El texto no se publica hasta que un revisor que intenta romperlo ya no pueda construir una fuga concreta siguiéndolo palabra por palabra. El revisor encontró tres.
Ataque uno: el caché que olvidó quién preguntaba
La sección recomendaba guardar en caché los resultados de las consultas para mantenerse bajo los límites de velocidad. Cierto y sensato. El API de Airtable tiene topes, y habíamos probado en vivo el límite real de lote, 25 registros por solicitud en julio de 2026, cuando la documentación pública todavía decía 10, así que sabemos exactamente cuánto importa el caché en la práctica.
Pero el texto describía el caché sin exigir que la llave del caché incluyera al cliente. Sígalo tal como está escrito y construirá un almacén donde al segundo cliente que pida "mis pedidos abiertos" se le sirven los pedidos abiertos del primero, porque la llave era la consulta, no la consulta más el cliente. Nada en el párrafo era falso. El párrafo seguía siendo una instrucción para filtrar datos. La solución fue una oración innegociable: el identificador del cliente es parte de cada llave de caché, siempre, y un caché que no puede expresar eso es el caché equivocado.
Ataque dos: el filtro que fallaba abierto
El patrón del portal filtraba los registros al cliente con sesión iniciada mediante una fórmula. Correcto hasta donde llegaba. El revisor hizo la pregunta que el texto no hacía. ¿Qué pasa cuando el filtro arroja un error? ¿Un identificador de cliente vacío, un valor malformado, un error transitorio en la expresión?
El comportamiento por defecto no declarado era fallar abierto. Ante un error, la consulta devolvía el conjunto sin filtrar, que son los registros de todos los clientes. El valor por defecto seguro es el opuesto: ante cualquier falla en identificar positivamente al cliente, no devolver nada y levantar una alerta. "Falla cerrado" no es una manera más amable de decir "falla abierto". Es la diferencia entre una pantalla en blanco y una brecha de datos. El texto corregido hizo del fallar cerrado la regla, y trató un filtro que puede degradarse en silencio a todos-los-registros como un defecto y no como un caso límite.
Ataque tres: el agente con la llave maestra
El hueco más moderno estaba en el patrón más nuevo. La sección cubría darle a un agente impulsado por Claude acceso a los datos para que pudiera responder preguntas y ejecutar acciones. Lo que no fijaba era el alcance del token detrás de ese agente.
Con un token de acceso a toda la base en la mano, el agente puede alcanzar a cada cliente de la base. No necesita ser atacado con un prompt ingenioso. Una pregunta razonable, hecha por el usuario equivocado, es suficiente, porque el token no traza ninguna frontera que el modelo esté obligado a respetar. Oración cierta en el original: el agente necesita acceso a los datos. Faltante y estructural: la credencial del agente debe estar acotada exactamente a la porción de un solo cliente, para que lo peor que pueda hacer un agente confundido o manipulado sea quedarse dentro de las paredes que el token ya traza. La solución movió la frontera fuera del prompt, donde es un deseo, y la puso en el token, donde se hace cumplir.
Las revisiones deben atacar, no leer
Ninguna de las tres correcciones convirtió una oración falsa en cierta. Convirtieron una sección cierta en segura, al nombrar el comportamiento por defecto, la ruta de error y el alcance que la prosa precisa había dejado al azar. Un corrector de estilo habría aprobado el original. Tres pasadas adversariales construyeron tres fugas funcionales y bloquearon la publicación hasta que cada ataque fracasó contra el texto corregido.
Esa es toda la lección, y llega mucho más allá de Airtable y de la seguridad. En la era de la IA, generar texto fluido y factualmente limpio es barato, y los sistemas producirán muchísimo. Lo que sigue siendo escaso es la revisión que asume que el texto intenta hacerle daño y sale a buscar cómo. La precisión es una afirmación sobre oraciones. La seguridad es una afirmación sobre consecuencias. Solo la segunda mantiene a un cliente lejos de una llamada para notificar una filtración.
La misma compuerta en el trabajo de clientes
Cada proyecto que tomamos pasa por esta disciplina, no solo la skill. Los hechos se verifican contra la plataforma en vivo y se fechan, porque la documentación se desvía y nuestra propia memoria también es un documento vencido. Los volátiles se vuelven a revisar en un calendario mensual automatizado en lugar de confiarse indefinidamente. Y cualquier cosa que toque los datos de más de un cliente recibe la pasada adversarial: no "¿esto se lee correctamente?" sino "si intentara servir los registros de la persona equivocada, ¿por dónde empezaría?".
Es más lento que publicar la primera versión que se lee bien. Ese es el punto. Tomamos un número pequeño de clientes a la vez precisamente para que los sistemas que entregamos hayan sobrevivido a alguien intentando romperlos, y no apenas a alguien intentando que le gusten.
Si sus sistemas son más viejos que sus ambiciones de IA, el método explica por dónde empezaríamos, y una conversación es la manera en que comienzan los proyectos.