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.
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.
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.
Esto tiene nombre y número: es OWASP LLM01:2025, 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, 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:
- Compromiso de endpoint
- El portátil de alguien. Habría pasado sin agentes. La mayor pérdida de la categoría hasta ahora
- Phishing a un operador
- La misma categoría. Que haya un agente en la pila no cambia nada
- Errores de contrato corrientes
- Una vulnerabilidad en un protocolo que el agente llamó es una vulnerabilidad de ese protocolo
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.
- Pregunte qué puede escribir el agente
Si la respuesta contiene una dirección, lo demás es filtrado.
- Pregunte dónde se hace cumplir el tope de gasto
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.
- Pregunte cuánto cuesta un agente comprometido, como cifra
Una buena respuesta es un número que usted fija. Una respuesta vaga significa que nadie lo ha calculado.
- Pregunte qué se ha probado, y quién
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.