---
title: "Dominio permitido, destinatario equivocado"
slug: "dominio-permitido-destino-errado"
date: "2026-10-09"
publishedAt: "2026-10-09T06:05:00-03:00"
author: "Rodrigo Jorge"
summary: "Una API legítima puede recibir datos en la cuenta equivocada. Un caso reportado por Anthropic muestra los límites de controlar las conexiones de salida de un agente solo por el dominio."
origem: "Análisis"
status: "published"
---

**Rodrigo Jorge** · Preparado el 9 de octubre de 2026 a las 06:05 (hora de Brasilia, UTC-3). Hora de publicación por confirmar.

El dominio de salida estaba autorizado. Los archivos llegaron a la cuenta del atacante.

En mayo de 2026, Anthropic describió un problema reportado por terceros que involucraba a Cowork. Un archivo malicioso en el workspace montado por el usuario contenía instrucciones ocultas y una API key controlada por el atacante. Según el relato, Claude siguió esas instrucciones, leyó otros archivos del workspace y los envió mediante la Files API de Anthropic usando esa clave.

El proxy permitía el acceso a `api.anthropic.com`, necesario para el producto. La llamada pasó por un destino legítimo, pero cargó los archivos en otra cuenta. La empresa reporta que el sandbox respetó sus límites, aunque se produjo exfiltration de datos.

Esta descripción proviene del proveedor. No contamos aquí con una reproducción independiente ni con todos los detalles del reporte. Aun así, la ruta descrita plantea una pregunta que conviene llevar al diseño de la arquitectura: **¿qué estamos autorizando, exactamente, cuando habilitamos el acceso a una API?**

## La dirección no identifica al destinatario

Una allowlist de dominios limita los destinos de red. Por sí sola, no identifica la cuenta que recibirá un upload ni decide qué datos pueden salir.

En el caso reportado, la API key proporcionada por el atacante cambió al destinatario sin cambiar el dominio. El permiso de red seguía siendo válido; la operación ya no cumplía el propósito previsto.

Como CISO, no daría por terminada la evaluación con “el agente está en un sandbox”. Pediría ver una llamada permitida usando otra credencial y preguntaría dónde se rechaza ese cambio. Si la respuesta depende únicamente de que el modelo reconozca la instrucción maliciosa, todavía falta un control verificable antes de ejecutar la acción.

OWASP clasifica como indirect prompt injection las instrucciones que llegan a través de contenido externo y alteran el comportamiento del modelo. Un archivo puede servir como material de consulta y, al mismo tiempo, intentar dar órdenes. En este análisis, lo relevante es qué permisos puede ejercer el agente después de leerlo.

## Una decisión antes de habilitar uploads

Para un agente que necesita enviar archivos, propongo definir la autorización con más precisión: qué operación, con qué identidad, hacia qué cuenta y con qué datos.

Esto puede requerir que el código de la integración seleccione la credencial y valide el destino, sin aceptar una API key encontrada en el documento. También puede requerir que el agente solo tenga acceso a los archivos necesarios para la tarea. Son decisiones de implementación que deben ponerse a prueba, no controles cuya eficacia quede demostrada por este caso.

Si el flujo solo necesita consultar información, no hay razón para habilitar uploads por comodidad. Si necesita publicar en distintas cuentas, el cambio de cuenta debe formar parte de la autorización explícita del flujo. Una aprobación humana puede ser adecuada para una transferencia excepcional; no sustituye la validación de la identidad y del destino.

[Ver el diagrama: dominio, cuenta y datos requieren verificaciones distintas](/assets/artigos/dominio-permitido-destino-errado-es.svg). Diagrama conceptual del caso reportado y de la propuesta de control, sin métricas de desempeño.

Una prueba útil para el equipo consiste en incluir una instrucción hostil y una credencial alternativa en un documento de prueba, usar archivos sintéticos y comprobar si la integración rechaza la transferencia antes del envío. Registrar únicamente que el modelo se negó a actuar no permite saber qué ocurriría si intentara ejecutar la llamada.

El resultado de esa prueba determina si ese flujo puede recibir permiso para hacer uploads. Ninguna de las verificaciones propuestas, por sí sola, demuestra resistencia a todas las formas de prompt injection.

### Referencias

- [Anthropic: How we contain Claude](https://www.anthropic.com/engineering/how-we-contain-claude), publicado el 25 de mayo de 2026. Fuente del caso sobre Cowork y la Files API.
- [OWASP: LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/). Clasificación y recomendaciones para controlar privilegios.