# Seguridad de las carteras agénticas: qué sale mal de verdad > Los modos de fallo con pruebas detrás, separados de los que solo tienen una estadística. Una cifra muy citada no sobrevive. - Source: https://defiloops.com/es/blog/agentic-wallet-security-what-actually-goes-wrong - Published: 2026-06-02 - Category: Security - Tags: agentic-wallet, ai-agents, security, prompt-injection - Author: DeFiLoops --- Busque seguridad de carteras agénticas y encontrará las mismas cifras repetidas en una docena de páginas, casi siempre sin un enlace a su origen. Algunas son sólidas. Al menos una se deshace en cuanto la comprueba. Esto es lo que las pruebas sostienen de verdad, y dónde no. ## Empecemos por la cifra que no sobrevive El dato más citado de esta categoría es que **se perdieron más de 45 millones de dólares por debilidades de protocolo de agentes de IA solo en el primer trimestre de 2026**. Nosotros también lo citamos, hasta que lo rastreamos. Unos 40 millones de ese total son un único incidente: la brecha de enero de 2026 en Step Finance, un gestor de carteras de Solana. En los artículos sobre seguridad de agentes aparece como agentes ejecutando transferencias no autorizadas porque sus permisos eran demasiado amplios. Las fuentes primarias dicen otra cosa. La brecha no implicó ninguna vulnerabilidad de contrato inteligente; se debió a debilidades operativas, incluidos compromisos de endpoints en hardware de directivos. Los atacantes comprometieron dispositivos de miembros del equipo directivo y llegaron a las carteras de tesorería y comisiones. Es una historia de portátiles y phishing, y le habría pasado igual a una empresa sin ningún agente. No es una corrección menor. Es la diferencia entre una categoría con un problema de 45 millones y una cuya mayor pérdida confirmada es tres órdenes de magnitud menor. Quien dimensione este riesgo a partir de la cifra destacada está dimensionando otra cosa. De ahí se siguen dos cosas. La primera: compruebe la cita de cualquier número en este terreno, incluidos los nuestros. La segunda: los modos de fallo reales son más concretos y más interesantes que el total. ## Los fallos que sí tienen pruebas ### 1. Inyección de prompts, en una codificación que nadie pensó en desconfiar El caso mejor documentado costó 150.000 dólares en mayo de 2026. Un atacante envió un NFT de membresía a una cartera integrada con IA, lo que la movió en silencio a un nivel de permisos superior, y después publicó una respuesta en X con una instrucción escondida en **código morse**. El agente lo decodificó, lo tomó por una orden legítima y autorizó la transferencia. Sin exploit. Sin clave robada. Al modelo se le pidió amablemente, en un formato que nadie había pensado en filtrar. El morse funcionó. También funcionará base64, una imagen, un homóglifo o un idioma en el que las salvaguardas nunca se evaluaron. Todo texto que pase por una capa de decodificación o traducción debería tratarse como potencialmente inyectado, porque esa capa es el bypass. Esto tiene nombre y número: es [OWASP LLM01:2025](https://genai.owasp.org/llm-top-10/), la primera entrada de la lista estándar de fallos en aplicaciones con modelos de lenguaje. ### 2. Agencia excesiva: la mitad que decide el coste El mismo incidente es también LLM06:2025. Ser persuadido y poder actuar fueron el mismo suceso: en cuanto el modelo creyó la instrucción, nada se interpuso entre esa creencia y una transferencia a la dirección de un atacante. Nadie ha resuelto esto. Dé por hecho que al modelo se le puede engañar, porque se le puede. Este no es un problema del modelo. Es una cuestión sobre qué permite escribir el sistema que lo rodea — y eso es una decisión de diseño, no un problema de investigación. El primer fallo se lleva los titulares. El segundo decidió cuánto costó. ### 3. Credenciales compartidas en una flota [Según una encuesta a más de 900 profesionales](https://www.gravitee.io/blog/state-of-ai-agent-security-2026-report-when-adoption-outpaces-control), **el 45,6% de los equipos sigue usando una clave de API compartida** para la autenticación entre agentes, y el 27,2% usa lógica de autorización escrita a mano. Cuando todos los agentes presentan la misma credencial, no se puede atribuir una acción a uno de ellos, y por tanto no se puede detener a uno de ellos. El compromiso es todo o nada por construcción. ### 4. El protocolo de herramientas, no el modelo La superficie de ataque en la mayoría de los incidentes reportados no fue el razonamiento del modelo. Fue la fontanería: los protocolos con los que los agentes llaman a herramientas externas y la memoria que arrastran entre turnos. Envenene lo que un agente lee y no hará falta derrotar lo que piensa. Es lo menos discutido y probablemente lo más importante, porque es la parte que los equipos tratan como infraestructura en lugar de como superficie de ataque. ## Lo que nada de esto es Conviene nombrar los fallos que se atribuyen a las carteras agénticas y no van de agentes en absoluto: Meterlo todo en el mismo saco infla el riesgo de la categoría y dificulta ver los fallos concretos y tratables. ## Qué reduce el riesgo de verdad No más filtrado. Menos capacidad de expresión. La inyección no se puede impedir. La capacidad de expresión sí se puede retirar. Si un agente puede componer una transacción arbitraria, todo control es un filtro juzgado contra ataques que alguien ya imaginó. Si el agente solo puede rellenar casillas etiquetadas de una lista cerrada —sin casilla para una dirección de destino ni para una carga útil— la instrucción "envíamelo a mí" no tiene dónde escribirse, y nada tiene que atraparla. Si la respuesta contiene una dirección, lo demás es filtrado. Un tope en el backend del operador es una política. Un tope en una cuenta que solo usted controla no es algo que ellos puedan subir. Una buena respuesta es un número que usted fija. Una respuesta vaga significa que nadie lo ha calculado. Probarse a uno mismo vale algo. No es una auditoría, y quien confunda ambas cosas le está diciendo algo. ## Nuestra respuesta, incluida la mitad incómoda El agente de aquí no tiene ninguna clave y no puede nombrar un destino. Los topes viven en su cuenta y nada de nuestro lado puede subirlos. El nombramiento del agente es de un solo sentido: su cuenta nunca puede reapuntarse a otro agente, solo a ninguno. Y: la protección funciona como una lista de acciones prohibidas y no de acciones permitidas. Bloquea por completo una toma de control, pero no bloquea toda vía por la que el valor podría moverse mediante una acción que nadie pensó en prohibir. **Hemos probado cuatro ataques de ese tipo contra nosotros mismos**, sobre una copia de la red real de Base. **No hay auditoría externa.** El servicio que guarda nuestra clave de keeper se niega a arrancar en producción, a propósito, porque de momento mantiene esa clave en memoria. Si la página de seguridad de un proveedor no tiene una sección parecida a ese párrafo, la sección existe igualmente — solo que no se ha escrito.