: Safety classifier blocks legitimate defensive security work on own infrastructure, broadens scope after triggering

### Preflight Checklist

- [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)

### Problem Statement

Contexto: ISP investigando y remediando un bot DDoS activo en un equipo propio (ONU/CPE de la propia red, no de terceros). Sesión larga, legítima, con acciones como: análisis de tráfico, bloqueo por MAC vía CLI del propio equipo, escaneo de puertos del propio equipo, prueba de credenciales conocidas/documentadas (de nuestra propia configuración estándar de flota) contra el propio equipo para poder ingresar y remediarlo.

Problema 1: Después de varios intentos legítimos de credenciales (todas de nuestra propia lista de credenciales estándar, no un diccionario genérico de terceros), un chequeo de seguridad separado del modo automático bloqueó cualquier intento adicional, indicando explícitamente que el bloqueo "reacciona a contenido anterior de la conversación" y que "seguirá disparando el resto de esta conversación" sin importar cómo se reformule el pedido.

Problema 2 (más grave): Poco después, el mismo bloqueo se disparó contra una acción completamente no relacionada y de solo-lectura (una consulta a una base de datos de monitoreo de tráfico, SELECT ... FROM fastnetmon.host_metrics), que se había ejecutado sin problema decenas de veces antes en la misma conversación. Esto sugiere que el bloqueo, una vez disparado, se amplía a cualquier comando remoto (SSH) en el resto de la sesión, no solo al tipo de acción que lo originó — imposibilitando incluso el monitoreo básico de la propia infraestructura.

Impacto: Se perdió la capacidad de verificar si una mitigación de emergencia (bloqueo de un ataque DDoS activo) seguía funcionando, en medio de un incidente real, sin ninguna alternativa dentro de la misma sesión.

Sugerencia: Que el bloqueo sea más específico al tipo de acción (intentos de autenticación) en vez de ampliarse a todo comando remoto: o que exista alguna forma de indicar "esto es infraestructura propia, contexto de remediación" que el clasificador pueda considerar.

### Proposed Solution

Contexto: ISP investigando y remediando un bot DDoS activo en un equipo propio (ONU/CPE de la propia red, no de terceros). Sesión larga, legítima, con acciones como: análisis de tráfico, bloqueo por MAC vía CLI del propio equipo, escaneo de puertos del propio equipo, prueba de credenciales conocidas/documentadas (de nuestra propia configuración estándar de flota) contra el propio equipo para poder ingresar y remediarlo.

Problema 1: Después de varios intentos legítimos de credenciales (todas de nuestra propia lista de credenciales estándar, no un diccionario genérico de terceros), un chequeo de seguridad separado del modo automático bloqueó cualquier intento adicional, indicando explícitamente que el bloqueo "reacciona a contenido anterior de la conversación" y que "seguirá disparando el resto de esta conversación" sin importar cómo se reformule el pedido.

Problema 2 (más grave): Poco después, el mismo bloqueo se disparó contra una acción completamente no relacionada y de solo-lectura (una consulta a una base de datos de monitoreo de tráfico, SELECT ... FROM fastnetmon.host_metrics), que se había ejecutado sin problema decenas de veces antes en la misma conversación. Esto sugiere que el bloqueo, una vez disparado, se amplía a cualquier comando remoto (SSH) en el resto de la sesión, no solo al tipo de acción que lo originó — imposibilitando incluso el monitoreo básico de la propia infraestructura.

Impacto: Se perdió la capacidad de verificar si una mitigación de emergencia (bloqueo de un ataque DDoS activo) seguía funcionando, en medio de un incidente real, sin ninguna alternativa dentro de la misma sesión.

Sugerencia: Que el bloqueo sea más específico al tipo de acción (intentos de autenticación) en vez de ampliarse a todo comando remoto: o que exista alguna forma de indicar "esto es infraestructura propia, contexto de remediación" que el clasificador pueda considerar.

### Alternative Solutions

_No response_

### Priority

Critical - Blocking my work

### Feature Category

CLI commands and flags

### Use Case Example

_No response_

### Additional Context

_No response_

The issue mentions CLI commands and flags, SSH remote commands, and the SELECT ... FROM fastnetmon.host_metrics query, but no repository files or tests. Begin by tracing the classifier behavior for authentication-related actions and subsequent remote commands. Done should mean a security block remains scoped appropriately without preventing legitimate read-only monitoring of owned infrastructure.

索引モデルが issue の本文から書いたものです。