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.

Теперь дайте агенту вторую задачу, требующую функцию, которую вы намеренно исключили. Агент может попытаться обойти ограничение с помощью рассуждений или же галлюцинировать, что инструмент существует. В любом случае, вызов поступит на уровень управления (control plane), белый список отклонит его, и выполнение завершится ошибкой. Этот сбой и станет доказательством того, что граница соблюдается программно, а не теоретически.

Сначала делайте это на синтетических задачах. Создайте фейковую базу данных, наполненную сгенерированными профилями пользователей. Позвольте агенту запрашивать её. Проверьте работу белых списков и отклонения запросов. Только когда вы будете уверены в надежности границы, можно будет задуматься о подключении агента к рабочим системам. Попытка поспешить с реальными данными до проверки «стены» — это прямой путь к утечке секретов.

Чтение полного пути выполнения

deco Studio позволяет исследовать каждый уровень выполнения. Вы видите исходный запрос модели: промпт, контекстное окно, форматирование. Вы видите вызов инструмента, который решила сделать модель. Вы видите, как уровень управления маршрутизирует этот вызов, как выполняется функция и возвращается полезная нагрузка. Наконец, вы видите, как модель использует этот результат для формирования своего ответа.

Такая прозрачность отвечает на базовые вопросы аудита. Вы знаете, какой инструмент сработал, потому что это зафиксировал уровень управления. Вы знаете, кто предоставил доступ, потому что записи конфигурации хранятся в едином локальном реестре. Вы знаете, почему выполнение оказалось дорогим, потому что можете подсчитать токены.

Подсчет того, что важно

Для каждого запуска отслеживайте четыре конкретные метрики. Во-первых, входные и выходные токены. Именно они составляют основную часть затрат на модель, и вам нужны точные значения, а не грубые оценки. Во-вторых, разделяйте задержку модели и задержку инструментов. Время между вашим промптом и ответом модели отличается от времени, которое требуется внешнему сервису для ответа на вызов инструмента. Смешивание этих двух понятий ведет к неверной диагностике замедлений. В-третьих, рассчитывайте стоимость на основе проверенных тарифов провайдеров. Не гадайте. Сверьтесь с прайс-листом вашего провайдера и сопоставьте его с измеренным количеством токенов. В-четвертых, сравнивайте успешные вызовы с отклоненными неавторизованными вызовами. Высокое количество отклонений означает, что ваш агент прощупывает границы или ваш белый список не соответствует законным потребностям.

Эти цифры превращают работу агента из подписки по принципу «черного ящика» в наблюдаемую систему. Вы сможете планировать бюджет, оптимизировать процессы и давать объяснения.

Разница между локальным управлением и локальным выполнением

Вот урок, на котором спотыкаются даже осторожные разработчики. Запуск deco Studio на вашей машине дает вам локальный контроль над конфигурацией, но не гарантирует локального выполнения самой модели. Если вы настроите агента на вызов внешнего провайдера, такого как OpenAI, Anthropic или любого другого хостинг-API, ваши промпты покинут вашу машину. Studio управляет шлюзом, но данные все равно передаются по сети.

Всегда отслеживайте эти границы. Знайте, какие части конвейера остаются на localhost, а какие части отправляются на чужой сервер. Если ваши данные конфиденциальны, локального контроля уровня инструментов недостаточно. Вам также нужно знать, где происходит инференс модели. Не путайте удобство локальной панели управления с реальностью удаленной модели.

Инструкции — это не авторизация

Один из опасных путей — попытка обезопасить агента с помощью промптов. Утверждение модели «Никогда не вызывай функцию удаления» — это не средство контроля безопасности. Это лишь рекомендация. Модели могут неверно интерпретировать инструкции, поддаваться джейлбрейку или просто совершать логические ошибки. Настоящая безопасность обеспечивается на программной границе.

Используйте белые списки внутри deco Studio, чтобы точно определить, какие функции можно вызывать. Применяйте эти ограничения с помощью проверок на стороне сервера внутри уровня управления. Агент должен обнаруживать свои возможности так же, как пользователь обнаруживает права доступа к файлам: натыкаясь на жесткое ограничение, а не читая дружелюбную заметку. Безопасность должна быть частью архитектуры, а не естественного языка.

Начинайте с малого и сохраняйте скептицизм

Стройте свой уровень управления шаг за шагом. Один MCP-сервер. Одна открытая функция. Одна синтетическая задача. Убедитесь, что агент преуспевает там, где должен, и терпит неудачу там, где обязан. Изучите трассировку. Подтвердите количество токенов. Затем добавьте следующий инструмент.

Контроль — это не переключатель, который можно просто щелкнуть. Это привычка проверять границы, прежде чем им доверять. deco Studio предоставляет вам локальную среду для отработки этой привычки. Используйте её, чтобы превратить рой автономных агентов в управляемую, наблюдаемую и ограниченную систему.

Источник: Controlling AI Agents in deco Studio: Tools, Permissions, and Cost

Дополнительное обучающее сообщество: GyaanSetu AI в Telegram