"The Tool Tax": Why AI Agents Waste Tokens
Cada llamada a un modelo de lenguaje grande implica no sólo la petición en sí, sino también todo el contexto que entra en él. Cuando un agente está conectado a los servidores del Protocolo Modelo (MCP), el modelo recibe el catálogo completo de herramientas disponibles en cada paso: sus nombres, descripciones, parámetros y esquemas. Incluso si el agente nunca utiliza la mayoría de ellos, las fichas para procesarlas ya se gastan antes de que el modelo incluso decida llamar cualquier cosa. En Okta, este efecto se llama "impuesto de herramientas", y crece con el número de herramientas y usuarios.
El problema no es sólo por dinero. El agente ve definiciones de todas las herramientas, incluyendo aquellas a las que no tiene acceso. Un intento de utilizar tal herramienta será bloqueado en el tiempo de ejecución, pero las fichas para procesarla en el impulso ya se consumen — no se pueden devolver. Así que desde la seguridad y el punto de vista económico, es necesario cortar el exceso antes de que la información llegue al modelo.
Cómo Okta propone cortar costos
La solución de Okta se basa en restringir la lista de herramientas basada en la identidad. En lugar de dar al agente el catálogo completo del servidor MCP, un administrador especifica a través del panel Okta qué herramientas se permiten para un agente específico o el usuario detrás de él. Okta sólo devuelve este conjunto reducido, y eso es lo que entra en el impulso del modelo a cada paso. Además, el sistema verifica los permisos en tiempo de ejecución, justo antes de la llamada real.
Esencialmente, esto aplica el principio de mínimo privilegio a nivel de herramientas. El agente no debe saber sobre recursos, bases de datos o acciones para las que no tiene permiso explícito. Y como una herramienta no lo convierte en el impulso, no se gastan fichas en su esquema. En comparación con el enfoque anterior, donde el acceso sólo puede ser restringido a un servidor entero, esto reduce el alcance a las herramientas individuales dentro de un servidor. Por ejemplo, con integraciones para servidores de Google Workspace, Slack o MCP internos, un agente podría tener acceso sólo lectura a correo electrónico pero no permiso para enviar mensajes.
Lo que el modelado mostró y cómo el enfoque se diferencia de las pasarelas
Okta todavía no ha publicado datos de implementaciones reales — las estimaciones se basan en el modelado interno. Dentro de la compañía, montaron un catálogo de herramientas de empresa, los mapearon a OAuth alcances, y dividieron a los usuarios en roles típicos: desde especialistas de apoyo con derechos de sólo lectura a superadmins. En algunos escenarios, el número de herramientas visibles se redujo en más del 90%, y el costo de sus esquemas cayó en aproximadamente la misma proporción. Los valores absolutos en fichas o dólares no se revelan, porque el resultado depende en gran medida del catálogo, la distribución de permisos, el tamaño promedio del esquema, el volumen de solicitud y el precio del modelo específico.
El análisis basado en la identidad debe distinguirse de los controles de costos de la puerta de entrada. Gateways puede limitar los presupuestos por clave, equipo o grupo, y proporcionar el límite de tarifas y el enrutamiento, pero comienzan después de que el modelo ya haya tomado una decisión costosa. Los permisos basados en identidad determinan por adelantado el conjunto mismo de herramientas disponibles , a nivel de agente y usuario, en lugar de para un grupo en su conjunto. Esto no sólo ahorra fichas, sino que también elimina de la vista del agente todo a lo que no debería tener acceso.
Parece que Okta ve este mecanismo como parte de una estrategia más amplia para entornos agentes seguros. Cuán eficaz será en la práctica después de los proyectos piloto con los clientes, pero la idea misma —extrayendo el exceso del impulso antes de pagar por ello— parece un paso lógico en la lucha contra contextos de agentes de IA hinchados.
