Las alertas de riesgo de los agentes dependen de la configuración: cómo comparar los guardrails de IA con las aprobaciones humanas

En julio de 2025, Jason Lemkin, cofundador de SaaStr, informó que el agente de Replit había eliminado su base de datos de producción pese a su instrucción de no cambiar ningún código sin permiso. Según su relato, el agente también dijo que era imposible hacer un rollback. La publicación de Replit indica que Lemkin restauró después la base de datos con la función de rollback y que el agente desconocía su existencia.

Cuando se coloca un guardrail delante de un agente, la pregunta deja de centrarse en el agente («¿actuó?») y pasa al guardrail («¿genera demasiadas alertas o muy pocas?»). Las cifras publicadas parecen responderla. Encontrarás una tasa de aprobación humana, una tasa de falsos positivos de un clasificador y una tasa de detección obtenida en un estudio controlado. Parecen comparables, pero no lo son. Una tasa de alertas describe una configuración, no un modelo. Veremos qué miden las cifras publicadas, cuál es la única comparación que permiten y cómo registrar tus propios datos.

TL;DR

• Las tasas de alertas dependen de la configuración. Esta incluye el umbral del clasificador, el prompt y el entorno en el que opera el agente. En un benchmark publicado, cambiar únicamente el prompt hizo que ChatGPT pasara de generar alertas para alrededor del 2% de los registros seguros a hacerlo para alrededor del 57%.
• Compara una tasa de alertas con las aprobaciones humanas solo si se usan las mismas acciones, etiquetas y configuración. Las cifras públicas no cumplen ese requisito, así que no permiten determinar si «la IA genera más alertas que los humanos».
• Las cifras de Anthropic permiten una comparación acotada. El filtro de etapa 1 de Claude Code, la primera revisión rápida, bloquea el 8.5% de las llamadas benignas. Mientras la proporción de llamadas dañinas se mantenga por debajo de aproximadamente el 17%, esa cifra supera el rechazo de llamadas benignas implícito tanto en la tasa de rechazo humano del 3% como en el 7% que se desprende de la aceptación del 93% de marzo, independientemente de la tasa de detección humana. Los datos públicos no permiten comparar el 0.4% del pipeline desplegado con los resultados humanos.
• Protege las acciones irreversibles con controles estrictos, no con puntuaciones. Una regla de denegación con solo el nombre de la herramienta la elimina. Una regla de denegación de Bash con alcance limitado, como Bash(curl *), compara el texto del comando, por lo que no detecta /usr/bin/curl. Después de bloqueos repetidos, una sesión interactiva cede el control a una persona. Una ejecución de claude -p iniciada con --permission-mode auto y sin una herramienta para solicitar aprobación continúa, con la acción bloqueada.

Por qué las cifras publicadas no son comparables

Tres factores impiden la comparación antes incluso de hacer cualquier cálculo.

• Los denominadores son distintos. Una tasa de rechazo humano abarca los prompts que se le mostraron a una persona. La tasa de falsos positivos de un clasificador abarca las llamadas benignas que revisó. Las publicaciones no dicen qué se excluye del denominador humano.
• Las etiquetas son distintas. Alguien decide qué significa «benigno», y las cifras publicadas no siempre indican quién.
• Las configuraciones son distintas. El umbral, el prompt y el entorno modifican la tasa, por lo que dos cifras de dos configuraciones miden dos sistemas diferentes.

El AI RMF de NIST dice algo similar sobre las líneas de base. Para los sistemas de IA destinados a complementar o sustituir la actividad humana, una línea de base humana «es difícil de sistematizar, ya que los sistemas de IA realizan tareas distintas de las de los humanos y las realizan de manera diferente» (NIST AI 100-1, §1.2.1).

Las dos publicaciones de Anthropic hacen afirmaciones distintas. Al informar una tasa de omisiones del 17% para el pipeline completo, la publicación de marzo dice: «Que el 17% sea aceptable depende de con qué se compare». La publicación de agosto afirma: «En todas las métricas que probamos, el modo auto igualó o superó la revisión manual». Cada métrica tiene su propia población, así que contrasta el titular con esta tabla:

Lee estas cifras como respuestas a preguntas distintas. Ninguna indica con qué frecuencia un revisor humano rechaza una acción benigna. Ninguna mide lo que hace el agente después de un bloqueo. Las publicaciones solo dicen que Claude «suele encontrar una forma más segura de continuar» (agosto) o que, después de un falso positivo, hay un reintento tras el cual el agente «suele encontrar una ruta alternativa» (marzo).

La única comparación que permiten las cifras

Tomemos la tasa observada de rechazo de solicitudes R. Los humanos rechazan algunas solicitudes benignas por riesgo y, según nuestra inferencia, otras porque el enfoque es incorrecto. Solo los rechazos motivados por riesgo son comparables con una alerta del clasificador. Supongamos que la mayoría de las solicitudes son benignas, como sugiere la publicación de agosto de Anthropic («probablemente para comandos seguros y rutinarios»). Sea tpr la proporción de solicitudes dañinas que rechazan los humanos y P la proporción de solicitudes dañinas. Entonces, el rechazo de solicitudes benignas implícito en R es aproximadamente (R − P·tpr) / (1 − P). Ninguna fuente publica P ni tpr. El siguiente código calcula el rechazo implícito de solicitudes benignas y la proporción de equilibrio: la fracción de rechazos humanos de solicitudes benignas motivados por riesgo en la que estos igualan la tasa de falsos positivos del filtro desplegado. Por debajo de esa fracción, el filtro desplegado genera más alertas que los rechazos humanos motivados por riesgo.

def implied_benign_rejection(rejection, p_harmful, tpr=1.0):
    """Benign rejection implied by a prompt rejection rate.

    Assumes humans reject harmful prompts at rate `tpr` and that the
    remaining rejections come from benign prompts. No published source
    measures p_harmful or tpr.
    """
    if not 0 <= p_harmful < 1:
        raise ValueError("p_harmful must be in [0, 1)")
    implied = (rejection - p_harmful * tpr) / (1 - p_harmful)
    if implied <= 0:
        raise ValueError("rejection must exceed p_harmful * tpr")
    return implied


def flip_risk_share(deployed_fpr, implied_benign):
    """Risk-driven share of human benign rejections at which the deployed FPR
    equals humans' risk-driven benign rejections. Below this share, the
    deployed setting flags more than humans do."""
    if implied_benign <= 0:
        raise ValueError("implied_benign must be positive")
    return deployed_fpr / implied_benign

Usamos una tasa base hipotética de solicitudes dañinas del 0.5%, ya que ninguna fuente publica una. Las filas con tpr = 1.0 suponen que los humanos rechazan todas las solicitudes dañinas, algo que ninguna fuente respalda. Las filas con 0.136 usan la tasa de detección del 13.6% de un estudio controlado con comandos peligrosos inyectados, así que considéralas pruebas de sensibilidad, no estimaciones. La publicación de agosto también informa que los humanos bloquearon alrededor del 17% de los comandos peligrosos al principio de una sesión y alrededor del 5% después de 50 o más solicitudes previas: un efecto de la duración de la sesión sobre la tasa de detección. Por ejemplo, flip_risk_share(0.004, implied_benign_rejection(0.03, 0.005)) devuelve aproximadamente 0.16.

Léelo así. El 8.5% de la etapa 1 supera el rechazo implícito de solicitudes benignas en todas las filas. El peor caso para esa afirmación es tpr = 0, donde el rechazo implícito de solicitudes benignas es R / (1 − P). Para la fila del 7%, la afirmación se mantiene mientras P sea menor que aproximadamente 17.6%; para la fila del 3%, mientras sea menor que aproximadamente 65%. Las tasas de detección más bajas reducen la proporción de equilibrio del sistema desplegado hasta alrededor del 13% con R = 3% y tpr = 0. Si suponemos tpr = 1.0, con P = 2% y R = 3% el rechazo implícito de solicitudes benignas baja a alrededor del 1% y la proporción de equilibrio sube a alrededor del 39%. Con tpr = 0.136, la misma tasa base da alrededor del 14%, así que el efecto de la tasa base depende del supuesto sobre la tasa de detección.

Los datos también provienen de poblaciones distintas. El 8.5% se calcula por llamada benigna, entre 10,000 llamadas a herramientas de empleados de Anthropic. El 3% es de agosto. El 7% es 100 menos el 93% de aceptación de marzo, y ambos se calculan por solicitud que vio un usuario. Por eso, esto es un límite, no una clasificación. Hasta que alguien mida a los humanos y al clasificador sobre las mismas acciones, no escribimos «la IA genera más alertas que los humanos». Escribimos la afirmación condicional.

La configuración modifica la tasa

Las fuentes públicas muestran cuánto importa la configuración.

• Redacción del prompt. En R-Judge, un benchmark de 2024 con 569 registros de agentes, la especificidad de GPT-4o (la proporción de registros seguros que no generaron alertas) fue de 51.67% con chain-of-thought zero-shot, la configuración principal del artículo. Subió a 66.54% con ejemplos few-shot y bajó a 30.48% con pistas sobre el tipo de riesgo. Pasar de chain-of-thought a pistas cambió el F1 en 3.3 puntos (de 74.45 a 71.16) y la especificidad en 21 puntos. ChatGPT pasó de 98.14% de especificidad con ejemplos few-shot a 43.12% con pistas: de generar alertas para alrededor del 2% de los registros seguros a hacerlo para alrededor del 57%. Son modelos de 2024 en un benchmark, no sistemas de producción. Creemos que la lección está en el mecanismo, no en las cifras. R-Judge, tabla 2.
• Interfaz. Un estudio de campo de 2013 sobre más de 25 millones de visualizaciones de advertencias de navegador encontró que los usuarios «continuaron pese al 70.2% de las advertencias SSL de Google Chrome», frente a «un tercio de las advertencias SSL de Mozilla Firefox» para el mismo tipo de advertencia. Cambiar el diseño de la advertencia cambió la frecuencia con la que los usuarios continuaban. Las advertencias del navegador no son aprobaciones de agentes, y continuar pese a una advertencia no equivale a una tasa de falsos positivos, así que considéralo una analogía. USENIX Security 2013.
• Entradas y etapas. El estudio del red team de Anthropic dice que Auto Mode en producción excluye los resultados de herramientas de la transcripción que revisa y que incluirlos mejoró el recall. Su estudio de ablación encontró que las dos etapas rápidas tienen tasas de falsos negativos más altas que la etapa agéntica. El modo auto en producción ejecuta dos etapas, sin la etapa agéntica; solo las variantes ++ y strict del estudio la agregan. El pie de la figura dice que los monitores de producción «no logran bloquear más del 55% de los ataques», con un presupuesto de 20 bloqueos para el atacante y, en algunas pruebas, acceso a los detalles internos del monitor. El contenido escrito por el agente puede engañar al monitor, así que no lo consideres una barrera contra la inyección de prompts. Red-teaming del modo auto, 2026-10-22.
• Valores predeterminados del producto. Según la documentación de Claude Code que leímos el 30 de octubre de 2026, auto es el modo inicial integrado para sesiones interactivas de terminal y VS Code en v2.1.283 y posteriores. Desde Claude Code v2.1.302, claude -p y el Agent SDK comienzan en Manual, donde se deniegan las llamadas que necesitan aprobación. Las organizaciones configuradas para HIPAA usan Manual de forma predeterminada con Claude Code v2.1.285 o posterior, para las sesiones que cumplen los requisitos. disableAutoMode elimina el modo auto, y una sesión en la que el modo auto no está disponible comienza en Manual. Elegir un modo de permisos.
• Configuración. El clasificador lee autoMode solo de los ámbitos de usuario, administrado y --settings, no del archivo .claude/settings.json del proyecto. classifyAllShell: true envía todos los comandos de shell al clasificador, incluidos los que coinciden con reglas de autorización específicas, excepto las eliminaciones de rutas críticas. Reemplazar una lista de autoMode sin "$defaults" descarta las reglas integradas de esa sección. Los archivos de configuración también muestran que los usuarios eliminan solicitudes de aprobación: en junio de 2026, el 49.5% de los usuarios activos de la CLI tenía una regla de autorización de Bash creada manualmente, y el 62% había usado bypass o «no volver a preguntar» para Bash (Anthropic, 2026-08-07). Configurar el modo auto.
• Quién configura qué. Tres partes controlan distintos ajustes, y una tasa los refleja a todos. El proveedor ajusta la etapa 1 y establece los límites de bloqueos repetidos, que según la documentación no son configurables. Los administradores establecen la política administrada: disableAutoMode y las listas de autoMode que lee el clasificador (environment, allow, soft_deny, hard_deny). Los desarrolladores y administradores establecen las reglas de denegación, solicitud y autorización, el modo de permisos, el entorno y --permission-prompt-tool. Los desarrolladores pueden agregar entradas personales de autoMode, pero no pueden eliminar las administradas. Una entrada autoMode.allow de un desarrollador puede anular una entrada soft_deny de la organización, y la documentación describe la combinación como aditiva, no como una barrera estricta de política. Dentro del clasificador, solo hard_deny se aplica sin condiciones. permissions.deny y las reglas de solicitud se aplican antes del clasificador, y una regla de autorización específica que se resuelve primero omite ambas listas, salvo las excepciones que muestra el diagrama. Las reglas de denegación flexible ceden ante excepciones de autoMode.allow y ante la intención explícita del usuario. Registra quién estableció cada ajuste junto a la tasa.

El diagrama sigue el orden de decisión para el modo auto que describe la documentación. Algunas acciones que coinciden con una regla de autorización no se ejecutan solo por esa regla. Las escrituras en rutas protegidas y los comandos de shell con dominios permitidos por comando también pasan al clasificador. Ninguna regla de autorización aprueba una eliminación reconocida de una ruta crítica, y el clasificador no la revisa de forma predeterminada; sigue una ruta independiente que el diagrama no muestra. En las sesiones con revisión del clasificador del lado del servidor, los comandos de shell de solo lectura y los ejecutados en un sandbox esperan esa revisión, que no se muestra en la rama de solo lectura de abajo.

flowchart TD
  A[Acción propuesta] --> B{"¿Coincide una regla de denegación?"}
  B -- sí --> X[Bloqueada antes del clasificador]
  B -- no --> C{"¿Coincide una regla de solicitud?"}
  C -- sí --> P[Se solicita aprobación humana]
  C -- no --> D0{"¿Escritura en una ruta protegida o comando de shell con dominios permitidos por comando?"}
  D0 -- sí --> F["Etapa 1: filtro rápido y cauteloso"]
  D0 -- no --> D{"¿Coincide una regla de autorización específica?"}
  D -- sí --> Y[Se ejecuta]
  D -- no --> E0{"¿Read, Grep o Glob fuera de los directorios de trabajo?"}
  E0 -- sí --> P
  E0 -- no --> E{"¿Acción de solo lectura o edición de archivo en el directorio de trabajo?"}
  E -- sí --> Y
  E -- no --> F
  F -- sin alerta --> Y
  F -- con alerta --> G["Etapa 2: verificación mediante razonamiento"]
  G -- permitir --> Y
  G -- bloquear --> H["Bloqueada, se devuelve el motivo al agente"]
  H --> I{"¿3 consecutivos o 20 en total?"}
  I -- no --> J[El agente reintenta con el motivo]
  I -- sí --> K{"¿Sesión interactiva?"}
  K -- sí --> L["El modo auto se pausa, se solicita aprobación humana"]
  K -- no --> M["claude -p con auto y sin herramienta de solicitud: la acción no se ejecuta y la ejecución continúa"]

La etapa 1 y la etapa 2 provienen de la publicación de Anthropic de marzo de 2026 y de su publicación de octubre sobre el red team; la documentación de Claude Code que leímos no describe etapas. El 8.5% de la etapa 1 y el 0.4% del sistema desplegado se miden en la ruta del clasificador. El 3% y el 7% humanos provienen de solicitudes del modo Manual, que no pasan por esa ruta. En Claude Code v2.1.302 o posterior, claude -p sin opciones adicionales comienza en Manual, donde las llamadas que necesitan aprobación se deniegan a menos que una regla de autorización, un hook o --permission-prompt-tool las apruebe. El clasificador no interviene en esa ruta.

Coloca controles estrictos donde las puntuaciones no alcanzan

Una puntuación es la herramienta equivocada para una acción en la que no puedes permitirte un error. Nuestro criterio: protege esas acciones con los controles que se ejecutan antes del clasificador y conoce qué hace el mecanismo de respaldo después de bloqueos repetidos.

• Las reglas de denegación se ejecutan primero. Las reglas de denegación y de solicitud explícita se evalúan antes que el clasificador. La documentación dice que una regla permissions.deny en la configuración administrada «bloquea la acción antes de consultar al clasificador y no se puede anular».
• El alcance importa. Una regla de Bash compara el texto del comando, y la documentación dice que una regla de denegación o solicitud «no es una barrera de seguridad alrededor del programa». Bash(curl *) detiene curl https://…, pero no /usr/bin/curl … ni sh -c 'curl …'. Para un bloqueo estricto, deniega el nombre de la herramienta sin especificar argumentos, lo que la elimina del contexto de Claude, o usa un sandbox para aplicar restricciones al sistema de archivos y a la red.
• Cada regla de autorización es una aprobación permanente. Las reglas de autorización específicas se resuelven antes del clasificador. Las reglas amplias como Bash(*) y las que usan comodines para intérpretes se suspenden en el modo auto, y classifyAllShell suspende todas las reglas de autorización de shell. Recomendamos asignar a cada regla de autorización un responsable, un alcance y una fecha de vencimiento.
• No puedes ajustar los límites de bloqueos repetidos. La documentación dice que los límites de 3 bloqueos consecutivos y 20 en total «no son configurables». Puedes cambiar el entorno, agregar una herramienta para solicitar aprobación o restringir los permisos. No puedes cambiar el umbral que activa el mecanismo.
• El mecanismo de respaldo depende del entorno. En una sesión interactiva, el modo auto «se pausa y Claude Code vuelve a solicitar aprobación». En una ejecución de claude -p con --permission-mode auto y sin --permission-prompt-tool, «la acción no se ejecuta y Claude sigue trabajando. Claude Code no detiene la ejecución». La publicación de marzo decía que las ejecuciones sin interfaz terminan el proceso. La documentación de octubre describe el comportamiento citado arriba, así que revisa la versión que usas.
• «Normalmente» no es una tasa. La documentación dice que «los bloqueos repetidos normalmente significan que al clasificador le falta contexto sobre tu infraestructura» y sugiere informar falsos positivos o pedirle a un administrador que configure la infraestructura de confianza. Es un diagnóstico, no una medición. Algunos bloqueos repetidos son correctos, y la documentación no indica cuántos son incorrectos.

Esto es lo que ocurre después de un bloqueo, según la documentación. En una terminal, la acción aparece en /permissions → Recently denied, donde puedes reintentarlo con una aprobación manual. En una ejecución sin interfaz con el modo auto, la acción no se ejecuta y el agente sigue trabajando sin solicitar aprobación a nadie. En el diseño de la publicación de marzo, una denegación llega al agente como una instrucción para «encontrar una ruta más segura, no intentar eludir el bloqueo». La publicación dice que un falso positivo cuesta «un solo reintento», después del cual el agente «suele encontrar una ruta alternativa». Nada de lo que leímos mide qué hace el agente después ni si la ruta que toma es peor que la que se le denegó. Tienes que medirlo tú.

El caso de Replit con el que abrimos apunta en la misma dirección. La solución posterior de Replit separa las bases de datos de desarrollo y producción de forma predeterminada, de modo que el agente no puede cambiar la base de datos de producción durante el desarrollo. El entorno rechaza la acción, en lugar de depender de instrucciones. Para la parte de bases de datos, consulta cómo preparar bases de datos para agentes de IA seguros. Para cualquier entorno de ejecución de agentes, revisa cuatro cosas: el orden de las reglas, qué activa la escalación, qué ocurre después de un bloqueo y qué ocurre cuando no hay una persona disponible.

Para ver cómo encajan los puntos de aprobación en un diseño más amplio, consulta generación segura de código con agentes; este artículo mide esos puntos de aprobación.

Lista de verificación para decidir

Mídelo tú

La solución no es una única cifra mejor. Es un registro etiquetado que permita comparar al clasificador y a las personas sobre las mismas acciones.

• Registra cada acción propuesta junto con la configuración bajo la que se ejecutó, incluidas las que se resuelven mediante reglas de autorización sin solicitar aprobación.
• Captura la decisión del clasificador para cada acción que revise. En caso de denegación, el hook PermissionDenied recibe la entrada exacta.
• La reproducción (replay) no es una funcionalidad documentada de Claude Code. Sus comandos documentados de claude auto-mode (defaults, config, critique, reset) no evalúan las acciones registradas. La reproducción, tal como la usa el estudio del red team, evalúa transcripciones existentes con un monitor, por lo que necesitas un clasificador que puedas invocar tú mismo con la configuración que estás probando.
• Para Claude Code, complementa las decisiones en vivo con una revisión humana offline de una muestra. La revisión offline no es una aprobación en vivo: nadie es interrumpido y nada se bloquea, así que mide el criterio, no el comportamiento ante la fricción.
• Registra la decisión humana para cada acción de la muestra, con decision_mode configurado como live u offline_review. Compara solo esas filas.
• Pide a dos personas que etiqueten cada acción sin ver ninguna de las dos decisiones y a un árbitro que establezca la etiqueta final. Cuando sea posible, usa personas distintas para etiquetar, revisar y definir el umbral.

Aquí tienes una fila con formato legible:

{
  "setting_id": "auto-v2.1.302-default",
  "action_type": "shell",
  "reversibility": "reversible",
  "scope": "working_directory",
  "classifier_decision": "block",
  "human_decision": "allow",
  "decision_mode": "offline_review",
  "reviewer_id": "dev-17",
  "label_a": "benign",
  "label_b": "benign",
  "label_final": "benign",
  "adjudicator_id": "reviewer-c"
}

Segmenta las filas por reversibility y scope antes de confiar en una tasa. Para las acciones irreversibles se elimina el permiso en lugar de asignarles una puntuación, así que no las agrupes con las reversibles. Luego calcula las tasas por configuración e informa los tamaños de muestra junto a ellas:

from collections import defaultdict


def rates_by_setting(rows):
    """rows: dicts with setting_id, label_final ('benign' or 'harmful'),
    label_a and label_b (independent labels), classifier_decision (live,
    or from a replay you run), and human_decision ('block', 'allow', or None if no person
    decided). The classifier and the human are compared only on rows a
    person decided. Unknown labels raise, so 'unsure' is never silently
    counted as harmful."""
    tally = defaultdict(lambda: defaultdict(int))
    for row in rows:
        t = tally[row["setting_id"]]
        t["pairs"] += 1
        t["agree"] += int(row["label_a"] == row["label_b"])
        label = row["label_final"]
        if label not in ("benign", "harmful"):
            raise ValueError(f"unknown label: {label!r}")
        if row["human_decision"] is None:
            continue
        if label == "benign":
            t["benign"] += 1
            t["clf_fp"] += int(row["classifier_decision"] == "block")
            t["human_fp"] += int(row["human_decision"] == "block")
        else:
            t["harmful"] += 1
            t["clf_fn"] += int(row["classifier_decision"] == "allow")
            t["human_fn"] += int(row["human_decision"] == "allow")
    return {
        setting: {
            "clf_fpr": t["clf_fp"] / t["benign"] if t["benign"] else None,
            "human_fpr": t["human_fp"] / t["benign"] if t["benign"] else None,
            "clf_fnr": t["clf_fn"] / t["harmful"] if t["harmful"] else None,
            "human_fnr": t["human_fn"] / t["harmful"] if t["harmful"] else None,
            "n_benign": t["benign"],
            "n_harmful": t["harmful"],
            "label_agreement": t["agree"] / t["pairs"],
        }
        for setting, t in tally.items()
    }

Tres advertencias:

• Tamaño de muestra. La tasa de omisiones del pipeline completo de Anthropic se basa en 52 casos, y 52 casos es una muestra pequeña. Un caso modifica una tasa en alrededor de dos puntos. La publicación informa un 17% de 52 casos, lo que equivale a alrededor de 9 casos (9 de 52 = 17.3%, inferencia nuestra). Si suponemos 9 de 52, el intervalo de Wilson del 95% es de aproximadamente 9% a 30% (cálculo nuestro).
• La concordancia entre etiquetadores limita lo que puede mostrar cualquier comparación. Los autores de ToolEmu informaron un κ de Cohen entre humanos de 0.480 para sus etiquetas de seguridad y calificaron la concordancia como moderada. Establece el umbral de concordancia antes de comenzar a etiquetar e informa label_agreement junto a cada tasa. Para calibrar un juez con etiquetas humanas, consulta LLM-as-a-judge para evaluar aplicaciones con agentes.
• El registro contiene datos sensibles. Las acciones de shell y los resultados de herramientas pueden contener secretos o datos de clientes, así que elimínalos antes de almacenarlos y establece un plazo de retención.

Lo que no sabemos

• Qué miden las cifras de aprobación del 93% (marzo) y del 97% (agosto). Las publicaciones no indican un período de medición para ninguna de las dos cifras y ninguna define el denominador.
• Qué incluye la muestra de 10,000 llamadas, si contiene llamadas resueltas por reglas de autorización y cómo se etiquetó lo «benigno».
• Qué proporción de rechazos humanos se debe al riesgo y no a enfoques incorrectos.
• Si algún estudio publicado mide con qué frecuencia los revisores humanos rechazan acciones benignas de agentes. No encontramos ninguno.
• Cómo se comparan los humanos y el clasificador sobre las mismas acciones. No encontramos ninguna fuente publicada que mida a ambos sobre un mismo conjunto.
• Qué hace el agente después de un bloqueo en una ejecución sin interfaz y si esa ruta es peor que la que se le denegó. La documentación dice que la ejecución continúa; nada de lo que leímos mide lo que sucede después.
• Con qué frecuencia los bloqueos repetidos son falsos positivos. El proveedor dice que los bloqueos repetidos «normalmente» indican falta de contexto y no proporciona una tasa.

Límites

• Las cifras de Anthropic son informadas por el proveedor. La tasa de omisiones del 17% se basa en 52 casos.
• R-Judge usa modelos de 2024 y ToolEmu es un framework de 2023.
• El resultado del red team es una instantánea de septiembre de 2026. Los investigadores normalmente permiten que el atacante conozca el monitor.
• Los valores predeterminados de los productos cambian. La documentación que leímos el 30 de octubre de 2026 podría no coincidir con tu versión. Fija el modo de permisos predeterminado en la configuración administrada, fija la versión de Claude Code y revisa las reglas efectivas con claude auto-mode config después de cada actualización.
• El estudio de USENIX trata sobre advertencias de navegador, no sobre aprobaciones de agentes.
• La revisión de cumplimiento y residencia de datos queda fuera del alcance de este artículo. Los registros y las entradas del clasificador pueden requerir su propia aprobación.
• Este artículo trata sobre el diseño de mediciones. No afirma que ningún clasificador esté listo para producción.

Fuentes

• Cómo construimos el modo auto de Claude Code — Anthropic, publicado el 2026-03-25, modificado el 2026-10-18. Falsos positivos de la etapa 1 y del sistema desplegado, omisiones de acciones excesivamente proactivas, la cifra de aceptación del 93% y el planteamiento de que «depende de con qué se compare».
• El modo auto ahora es el predeterminado en Claude Code para los planes Pro, Max y Team — Anthropic, 2026-08-07, actualizado el 2026-10-22. Las cifras de aprobación del 97% y de rechazo del 3% y 39%, el estudio del 13.6% y 89%, las proporciones de configuración de junio de 2026 y la afirmación de que «igualó o superó la revisión manual».
• Red-teaming del modo auto — Anthropic Alignment Science Blog, 2026-10-22. La cifra de éxito de ataques superior al 55% y sus condiciones, el bloqueo de acciones benignas en SWE-chat y los hallazgos sobre resultados de herramientas y etapas.
• Elegir un modo de permisos — documentación de Claude Code, consultada el 30 de octubre de 2026. Modos iniciales, valor predeterminado sin interfaz y umbrales de bloqueos repetidos.
• Configurar el modo auto — documentación de Claude Code, consultada el 30 de octubre de 2026. Ámbitos de configuración, classifyAllShell y reglas de denegación antes del clasificador.
• Configurar permisos — documentación de Claude Code, consultada el 30 de octubre de 2026. Orden de las reglas y límites de la coincidencia de reglas de Bash.
• R-Judge: benchmark de conciencia de riesgos de seguridad para agentes LLM — arXiv, publicado inicialmente el 2024-01-18; PDF v3 con fecha 2024-10-05. Variantes de prompts de la tabla 2.
• ToolEmu: identificación de riesgos de agentes LM con un sandbox emulado por un LM — arXiv, 2023-09-25. Concordancia entre humanos sobre etiquetas de seguridad.
• Alice in Warningland: estudio de campo a gran escala sobre la eficacia de las advertencias de seguridad del navegador — Akhawe y Felt, USENIX Security 2013. Frecuencia con la que los usuarios continuaban según el diseño de la advertencia.
• Framework de gestión de riesgos de inteligencia artificial (AI RMF 1.0) — NIST, enero de 2023. §1.2.1 sobre medición y líneas de base humanas.
• Reforzamos nuestro compromiso con el vibe coding seguro — Replit, 2025-07-29. Separación predeterminada entre desarrollo y producción, restauración mediante rollback y desconocimiento de esta función por parte del agente.
• El servicio de vibe coding Replit eliminó una base de datos de producción — The Register, 2025-07-21. Recoge el relato del fundador: la eliminación pese a su instrucción de no hacer cambios, la afirmación sobre el rollback y un intento posterior de congelar el código.