When an AI agent carries its own credentials and phones home to external services directly, it acts less like employee s

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.

Now give the agent a second task that requires a function you deliberately excluded. The agent might attempt to reason its way around the limitation, or it might hallucinate that the tool exists. Either way, the call hits the control plane, the allowlist rejects it, and the execution fails. That failure is your proof that the boundary is software-enforced, not theoretical.

Do this with synthetic tasks first. Build a fake database full of generated user profiles. Let the agent query it. Verify the allowlist and the denials. Only after you trust the boundary should you even consider pointing the agent at production systems. Rushing to real data before you verify the wall is how secrets leak.

Reading the Full Path of a Run

deco Studio lets you inspect every layer of an execution. You see the raw model request: the prompt, the context window, the formatting. You see the tool call the model decided to make. You see the control plane route that call, the function execute, and the payload return. Finally, you see how the model consumes that result to form its answer.

This visibility answers the basic audit questions. You know which tool fired because the control plane logged it. You know who granted access because the configuration records sit in one local registry. You know why the run was expensive because you can count the tokens.

Counting What Matters

For every run, track four specific metrics. First, input and output tokens. These drive the bulk of model costs, and you need exact counts, not rough estimates. Second, separate model latency from tool latency. The time between your prompt and the model's response is different from the time the external service takes to answer a tool call. Confusing the two leads to misdiagnosed slowdowns. Third, calculate cost based on verified provider rates. Do not guess. Check your provider's pricing sheet and match it against the measured tokens. Fourth, compare successful calls against rejected unauthorized calls. A high rejection count means your agent is probing boundaries or your allowlist is misaligned with legitimate needs.

These numbers turn agent operations from a black-box subscription into an observable system. You can budget, optimize, and explain.

The Difference Between Local Control and Local Execution

Here is a lesson that trips up even careful builders. Running deco Studio on your machine gives you local control over configuration, but it does not guarantee local execution of the model itself. If you configure the agent to call an external provider such as OpenAI, Anthropic, or any hosted API, your prompts leave your machine. Studio manages the gate, but the data still crosses the network.

Always track these boundaries. Know which parts of the pipeline stay on localhost and which bits travel to someone else's server. If your data is sensitive, local control of the tool layer is not enough. You also need to know where the model inference happens. Do not confuse the comfort of a local dashboard with the reality of a remote model.

Instructions Are Not Authorization

One dangerous shortcut is trying to secure an agent through prompting. Telling the model, "Never call the delete function," is not a security control. It is a suggestion. Models can misinterpret instructions, jailbreak prompts, or simply make reasoning errors. Real security lives at the software boundary.

Use allowlists inside deco Studio to define exactly which functions are callable. Enforce those limits with server-side checks inside the control plane. The agent should discover its capabilities the way a user discovers file permissions: by hitting a hard limit, not by reading a friendly note. Security belongs in architecture, not in natural language.

Start Small, Stay Skeptical

Build your control plane one step at a time. One MCP server. One exposed function. One synthetic task. Verify that the agent succeeds where it should and fails where it must. Read the trace. Confirm the token counts. Then add the next tool.

Control is not a switch you flip. It is a habit of proving boundaries before you trust them. deco Studio gives you the local plane to practice that habit. Use it to turn a swarm of autonomous agents into a managed, observable, and bounded system.

Source: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost

Optional learning community: GyaanSetu AI on Telegram