When an AI agent carries its own credentials and phones home to external services directly, it acts less like employee software and more like a contractor with a corporate card and no supervisor. You cannot see what it touched, who approved the access, or why one conversation cost ten times more than another. The logs fragment across a dozen services. The questions multiply.
Which tool did the agent actually invoke? Who granted it permission to touch that database? Why did Tuesday's run burn through forty thousand tokens while Monday's used five? How much did we really spend?
Without a central control layer sitting between users, models, and services, these questions stay unanswered. You need a single plane that registers every connection once, exposes only the narrow set of functions an agent truly needs, and records every execution in full. This article walks through an advanced lab using deco Studio as that local control plane. You will set it up, connect a safe Model Context Protocol server, expose exactly one permitted function, and watch what happens when an agent tries to reach beyond its boundary.
The Problem with Scattered Credentials
Imagine a typical team setup. One developer connects an agent to a search API using a personal key. Another wires the same agent into a production database because the demo looked harmless. A third adds a billing lookup tool so the agent can "help with invoices." Each connection is invisible to the others. The agent now has direct access to search, production data, and financial records, but the team has no unified list of what is live.
When credentials live inside the agent, governance breaks. You cannot revoke access centrally because the key sits in the agent's memory or its local environment file. You cannot audit usage because the external service sees only an API call from an anonymous automated client. The cost surprises show up days later on a cloud bill, and by then nobody remembers which prompt triggered the spike.
Building Your Control Plane in deco Studio
deco Studio fixes this by acting as a local hub. You run it on your own machine, and it becomes the single place where configurations live. Instead of scattering API keys and tool definitions across agents, you register a connection once inside Studio. Then you decide exactly which functions each agent can see.
Think of it as installing a switchboard. The wires all run into one room. You choose which lines connect to which departments, and you keep a record of every call.
Start by running deco Studio locally. Once it is up, you centralize the configuration. Every agent that wants to use a tool must now ask the control plane, not the outside service directly. This immediately creates a chokepoint where you can observe, filter, and log.
Connecting a Safe MCP Server
In this lab, you connect a Model Context Protocol server. MCP is an open standard for letting models interact with external tools, but standards do not guarantee safety. The critical step here is selectivity. You do not blindly expose every endpoint the server offers. You register the server in deco Studio, then expose only one permitted function to your test agent.
For example, your MCP server might offer ten functions: file read, file write, database query, network fetch, and others. You choose one harmless operation, perhaps a sandboxed calculator or a read-only lookup against synthetic data, and you expose that alone. The other nine become invisible to the agent. If the agent asks for them, the control plane returns a hard refusal.
This is the principle of least privilege made mechanical. The agent receives capability not through a polite instruction, but through a software boundary.
Testing the Boundary
Create a test agent and point it at your deco Studio control plane. Give it a task that requires the single allowed function. Watch it succeed. The logs inside Studio will show the model request, the tool call routing through the control plane, the function execution, and the result flowing back to the model. You can read the entire path in one continuous trace.
Ahora dale al agente una segunda tarea que requiera una función que hayas excluido deliberadamente. El agente podría intentar razonar para sortear la limitación, o podría alucinar que la herramienta existe. De cualquier manera, la llamada llega al plano de control, la lista de permitidos la rechaza y la ejecución falla. Ese fallo es tu prueba de que el límite está impuesto por software, no es algo teórico.
Haz esto primero con tareas sintéticas. Construye una base de datos falsa llena de perfiles de usuario generados. Deja que el agente la consulte. Verifica la lista de permitidos y las denegaciones. Solo después de que confíes en el límite deberías siquiera considerar apuntar al agente hacia sistemas de producción. Apresurarse hacia datos reales antes de verificar el muro es como se filtran los secretos.
Lectura de la ruta completa de una ejecución
deco Studio te permite inspeccionar cada capa de una ejecución. Ves la solicitud bruta del modelo: el prompt, la ventana de contexto, el formato. Ves la llamada a la herramienta que el modelo decidió realizar. Ves cómo el plano de control enruta esa llamada, ejecuta la función y devuelve la carga útil. Finalmente, ves cómo el modelo consume ese resultado para formar su respuesta.
Esta visibilidad responde a las preguntas básicas de auditoría. Sabes qué herramienta se activó porque el plano de control la registró. Sabes quién concedió el acceso porque los registros de configuración residen en un registro local. Sabes por qué la ejecución fue costosa porque puedes contar los tokens.
Contar lo que importa
Para cada ejecución, realiza un seguimiento de cuatro métricas específicas. Primero, los tokens de entrada y salida. Estos impulsan la mayor parte de los costos del modelo, y necesitas conteos exactos, no estimaciones aproximadas. Segundo, separa la latencia del modelo de la latencia de la herramienta. El tiempo entre tu prompt y la respuesta del modelo es diferente del tiempo que tarda el servicio externo en responder a una llamada de herramienta. Confundir ambos lleva a diagnósticos erróneos de lentitud. Tercero, calcula el costo basándote en las tarifas verificadas del proveedor. No adivines. Consulta la hoja de precios de tu proveedor y compárala con los tokens medidos. Cuarto, compara las llamadas exitosas con las llamadas no autorizadas rechazadas. Un alto recuento de rechazos significa que tu agente está sondeando límites o que tu lista de permitidos no está alineada con las necesidades legítimas.
Estos números transforman las operaciones de los agentes de una suscripción de caja negra en un sistema observable. Puedes presupuestar, optimizar y explicar.
La diferencia entre el control local y la ejecución local
Aquí hay una lección que confunde incluso a los constructores más cuidadosos. Ejecutar deco Studio en tu máquina te da control local sobre la configuración, pero no garantiza la ejecución local del modelo en sí. Si configuras el agente para llamar a un proveedor externo como OpenAI, Anthropic o cualquier API alojada, tus prompts salen de tu máquina. Studio gestiona la puerta, pero los datos siguen cruzando la red.
Realiza siempre un seguimiento de estos límites. Sabe qué partes del pipeline permanecen en localhost y qué fragmentos viajan al servidor de otra persona. Si tus datos son sensibles, el control local de la capa de herramientas no es suficiente. También necesitas saber dónde ocurre la inferencia del modelo. No confundas la comodidad de un panel de control local con la realidad de un modelo remoto.
Las instrucciones no son autorización
Un atajo peligroso es intentar asegurar un agente mediante el prompting. Decirle al modelo: "Nunca llames a la función de eliminar", no es un control de seguridad. Es una sugerencia. Los modelos pueden malinterpretar las instrucciones, sufrir jailbreaks en los prompts o simplemente cometer errores de razonamiento. La seguridad real reside en el límite del software.
Utiliza listas de permitidos dentro de deco Studio para definir exactamente qué funciones son invocables. Aplica esos límites con comprobaciones en el lado del servidor dentro del plano de control. El agente debería descubrir sus capacidades de la misma manera que un usuario descubre los permisos de archivos: chocando con un límite estricto, no leyendo una nota amistosa. La seguridad pertenece a la arquitectura, no al lenguaje natural.
Empieza poco a poco, mantente escéptico
Construye tu plano de control paso a paso. Un servidor MCP. Una función expuesta. Una tarea sintética. Verifica que el agente tenga éxito donde debe y falle donde debe hacerlo. Lee la traza. Confirma los conteos de tokens. Luego añade la siguiente herramienta.
El control no es un interruptor que se acciona. Es el hábito de probar los límites antes de confiar en ellos. deco Studio te ofrece el plano local para practicar ese hábito. Úsalo para convertir un enjambre de agentes autónomos en un sistema gestionado, observable y limitado.
Fuente: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost
Comunidad de aprendizaje opcional: GyaanSetu AI en Telegram