--- title: "Claude Console ya deja amarrar tus API keys a una lista de IP: qué cubre, qué no y cómo prenderla sin bloquearte" url: https://hernandez.systems/es/articulos/claude-console-ya-deja-amarrar-tus-api-keys-una-lista-de-ip-que-cubre-que-no lang: es type: NewsArticle section: IA published: "2026-11-07T14:32:55+00:00" modified: "2026-11-08T17:12:27+00:00" publisher: Osky Networks image: https://oskydj.sfo3.cdn.digitaloceanspaces.com/calamardo/news_item/2026-11-07/e94-portada-c8951112.png alternate_en: https://hernandez.systems/en/articles/claude-console-now-lets-you-tie-your-api-keys-to-an-ip-list-what-it-covers-what-it-doesnt-and-how --- # Claude Console ya deja amarrar tus API keys a una lista de IP: qué cubre, qué no y cómo prenderla sin bloquearte > Anthropic agregó el 5 de noviembre, según sus notas de versión, una lista de IP permitidas (IP allowlist) para las organizaciones de Claude Console, por ahora en beta. La idea es sencilla y vieja como el firewall: si una petición a la API llega desde una dirección que no está en tu lista, se rechaza. Lo que cambia en la práctica es que una API key filtrada en un repo público, en un log o en el .env que alguien subió por error deja de servir para gran cosa fuera de tus redes. Para quien tiene bots, agentes o automatizaciones pagando tokens con una sola key, es una de esas funciones que no lucen en un demo pero te pueden ahorrar una factura muy fea. Anthropic agregó el 5 de noviembre, según sus [notas de versión](https://platform.claude.com/docs/en/release-notes/overview#ip-allowlisting), una lista de IP permitidas (IP allowlist) para las organizaciones de Claude Console, por ahora en beta. La idea es sencilla y vieja como el firewall: si una petición a la API llega desde una dirección que no está en tu lista, se rechaza. Lo que cambia en la práctica es que una API key filtrada en un repo público, en un log o en el `.env` que alguien subió por error deja de servir para gran cosa fuera de tus redes. Para quien tiene bots, agentes o automatizaciones pagando tokens con una sola key, es una de esas funciones que no lucen en un demo pero te pueden ahorrar una factura muy fea. ## Qué anunció Anthropic Las notas de versión dicen tres cosas: que la lista se configura para toda la organización desde Claude Console, que las peticiones a los servicios cubiertos que vengan de direcciones fuera de la lista se rechazan, y que puedes cargar direcciones IPv4 e IPv6 o rangos CIDR, **hasta 1,000 por organización**. La [documentación de IP allowlisting](https://platform.claude.com/docs/en/manage-claude/ip-allowlist) completa el cuadro: - La configura un admin u owner de la organización, en la página **Identity and access** de la consola, con el interruptor **IP allowlist**. Nada cambia hasta que guardas. - Anthropic compara la IP **pública** de cada petición cubierta contra tu lista. Si no está, la API responde `403 permission_error` con el mensaje "Your IP address isn't in this organization's allowed range." - Las personas que entran a la consola desde una red no permitida ven una página que dice que su red actual no puede acceder a la organización. Esto incluye a los admins. - Cada entrada puede ser una dirección suelta o un rango, pero no más amplio que `/8` en IPv4 ni que `/32` en IPv6. - Solo acepta direcciones públicas: rangos privados como `10.0.0.0/8` no tienen sentido aquí. - Los cambios pueden tardar **hasta 15 minutos** en aplicarse. ## Qué cubre y qué no En una organización de Claude Platform, la lista aplica al acceso web de Claude Console y a estos endpoints, ya sea con API key o con un token de Workload Identity Federation: - **Claude API:** Messages, Message Batches, Token Counting, Models, Files y Skills. - **Claude Managed Agents:** Agents, Sessions, Environments, Vaults y Memory stores. - **APIs de organización:** Admin API y Compliance API, con una key que cubra solo esa organización. Y aquí vienen los asteriscos, que también salen de la documentación. La lista **no aplica** a Claude en Amazon Bedrock, Claude Platform on AWS, Claude Models on Google Cloud ni Claude en Microsoft Foundry: si consumes Claude por un proveedor de nube, el control de red lo pones del lado de ese proveedor. Tampoco aplica a la red interna del runtime de Managed Agents: cubre las peticiones que tú haces a esos endpoints, no lo que el agente hace por dentro. ![Diagrama del IP allowlist de Claude Console: una petición desde una IP en la lista es aceptada y una desde fuera recibe 403 permission_error; abajo, lo que cubre y lo que no cubre](https://oskydj.sfo3.cdn.digitaloceanspaces.com/calamardo/news_item/2026-11-07/e94-diagrama-112deb6d.png) Para organizaciones de Claude Enterprise existe una lista equivalente con otro alcance: cubre las apps de Claude en web, escritorio y móvil, Claude Code cuando el usuario entra con su cuenta de Claude, Claude in Chrome, Cowork, los complementos de Office y Remote Tools. Ahí no entran Claude Design, Claude in Slack ni Claude Academy, y una tarea que Claude ya estaba haciendo en un chat puede seguir hasta 24 horas aunque el usuario quede bloqueado. ## Cómo encenderla sin dejarte afuera El mayor riesgo de esta función no es el atacante, eres tú bloqueando tu propia producción. La documentación lo reconoce: al guardar, la página revisa que tu IP actual esté en la lista, pero **no revisa tus servidores, a tus compañeros ni la dirección desde la que te vas a conectar mañana**. El orden que propone Anthropic: 1. **Haz inventario antes de prender nada.** Centros de datos, CI, oficinas, VPN, proxies y los workers de sandboxes autohospedados, con sus IP públicas IPv4 e IPv6. La documentación advierte que las direcciones de casa y de datos móviles suelen cambiar sin aviso. 2. **Activa la casilla de rescate.** "Allow admins to access this settings page from any IP address" deja que un admin corrija la lista desde cualquier lado, pero solo esa página. Anthropic la recomienda, aunque reconoce el costo: si alguien roba la sesión de un admin, también podría editar la lista. Si tienes la Compliance API, su Activity Feed registra esos cambios. 3. **Vigila los 403 después de guardar,** incluidos los trabajos que corren una vez al día o a la semana, que son justo los que se te olvidan en el inventario. 4. **Si te bloqueas:** conéctate desde una red permitida, pide a otro admin que agregue tu IP, usa la casilla de rescate si la dejaste activa o, como último recurso, pide al soporte de Anthropic que apague la lista. Un detalle de la documentación que conviene leer dos veces: si agregas la IP de un proxy compartido, cualquiera que pase por ese proxy con tu key robada también entra. La lista protege tanto como de cerradas tengas las salidas de tu red. ## La lista no es la única defensa Anthropic lo dice en la misma página: el allowlist limita **dónde** sirve una key, pero no **por cuánto tiempo**. Por eso recomienda combinarlo con dos cosas que ya existen en la consola: - **Expiración de keys.** Según la [guía de autenticación](https://platform.claude.com/docs/en/manage-claude/authentication), al crear una key eliges su vida útil: 3 horas, 1 día, 7 días, 30 días, una duración personalizada o "Never". La expiración no se puede cambiar después, y una key vencida responde `401 authentication_error`. - **Workload Identity Federation (WIF).** Según su [documentación](https://platform.claude.com/docs/en/manage-claude/workload-identity-federation), en lugar de una key estática tu workload presenta un token de tu proveedor de identidad (GitHub Actions, AWS, Google Cloud, Entra ID, Kubernetes y otros emisores OIDC) y recibe un token de Anthropic de corta duración, de 60 segundos a 24 horas según configures. No hay `sk-ant-api...` que guardar ni rotar. El allowlist también aplica a esos tokens. ## Lo que esto significa Mi lectura: para un equipo que corre sus llamadas a Claude desde uno o dos servidores con IP fija, esto es casi gratis y vale la pena prenderlo en cuanto salga de beta, o antes si la key vive en muchos lugares. Un VPS en DigitalOcean, un servidor en tu oficina o un runner de CI con IP de salida fija se listan en dos minutos. Donde se complica es en arquitecturas sin IP estable: funciones serverless que salen por direcciones compartidas del proveedor, desarrolladores que prueban desde su casa o desde el teléfono, y clientes que llaman a la API directo desde la app. Para esos casos la salida razonable es pasar el tráfico por un gateway propio con IP fija, o apoyarse más en la expiración corta y en WIF que en el allowlist. Y un recordatorio que no viene de la documentación, sino del sentido común: la lista reduce el daño de una key filtrada, no evita que se filtre. La key sigue sin ir en el frontend, ni en el repo, ni en el chat del equipo. ## Fuentes - [Claude Platform release notes, 5 de noviembre de 2026](https://platform.claude.com/docs/en/release-notes/overview#ip-allowlisting) - [Claude Platform Docs: IP allowlisting](https://platform.claude.com/docs/en/manage-claude/ip-allowlist) - [Claude Platform Docs: Authentication (expiración de keys)](https://platform.claude.com/docs/en/manage-claude/authentication) - [Claude Platform Docs: Workload Identity Federation](https://platform.claude.com/docs/en/manage-claude/workload-identity-federation)