Коли ШІ-агент несе власні облікові дані та напряму звертається до зовнішніх сервісів, він діє менше як програмне забезпечення для співробітників і більше як підрядник із корпоративною карткою та без нагляду. Ви не можете бачити, до чого він торкався, хто схвалив доступ або чому одна розмова коштувала вдесятеро дорожче за іншу. Журнали розкидані по десятках сервісів. Питань стає дедалі більше.
Який інструмент насправді викликав агент? Хто надав йому дозвіл торкатися цієї бази даних? Чому під час виконання у вівторок було витрачено сорок тисяч токенів, тоді як у понеділок використано лише п'ять? Скільки ми насправді витратили?
Без центрального рівня управління, що стоїть між користувачами, моделями та сервісами, ці питання залишаються без відповіді. Вам потрібна єдина платформа, яка реєструє кожне з'єднання лише один раз, надає доступ лише до вузького набору функцій, які дійсно потрібні агенту, і повністю записує кожне виконання. У цій статті ми проведемо розширену лабораторну роботу, використовуючи deco Studio як таку локальну платформу управління. Ви налаштуєте її, підключите безпечний Model Context Protocol сервер, відкриєте рівно одну дозволену функцію та побачите, що відбувається, коли агент намагається вийти за межі своїх повноважень.
Проблема розкиданих облікових даних
Уявіть типову структуру команди. Один розробник підключає агента до пошукового API за допомогою особистого ключа. Інший підключає того ж агента до робочої бази даних, тому що демо-версія здалася безпечною. Третій додає інструмент перевірки рахунків, щоб агент міг «допомагати з інвойсами». Кожне з'єднання невидиме для інших. Тепер агент має прямий доступ до пошуку, робочих даних і фінансових записів, але команда не має єдиного списку того, що саме зараз працює.
Коли облікові дані зберігаються всередині агента, управління руйнується. Ви не можете відкликати доступ централізовано, тому що ключ знаходиться в пам'яті агента або в його локальному файлі середовища. Ви не можете провести аудит використання, тому що зовнішній сервіс бачить лише виклик API від анонімного автоматизованого клієнта. Несподівані витрати з'являються через кілька днів у рахунку за хмарні послуги, і на той час ніхто вже не пам'ятає, який саме промпт спричинив стрибок.
Створення вашої платформи управління в deco Studio
deco Studio вирішує цю проблему, виступаючи в ролі локального хаба. Ви запускаєте його на власній машині, і він стає єдиним місцем, де зберігаються конфігурації. Замість того, щоб розкидати API-ключі та визначення інструментів по різних агентах, ви реєструєте з'єднання один раз у Studio. Потім ви вирішуєте, які саме функції може бачити кожен агент.
Уявіть це як встановлення телефонної станції. Усі дроти сходяться в одній кімнаті. Ви обираєте, які лінії підключати до яких відділів, і ведете облік кожного дзвінка.
Почніть із запуску deco Studio локально. Після запуску ви централізуєте конфігурацію. Тепер кожен агент, який хоче використовувати інструмент, має звертатися до платформи управління, а не безпосередньо до зовнішнього сервісу. Це миттєво створює точку контролю, де ви можете спостерігати, фільтрувати та вести журнали.
Підключення безпечного MCP-сервера
У цій лабораторній роботі ви підключите сервер Model Context Protocol. MCP — це відкритий стандарт, який дозволяє моделям взаємодіяти із зовнішніми інструментами, але стандарти не гарантують безпеки. Критично важливим кроком тут є вибірковість. Ви не відкриваєте сліпо кожну кінцеву точку, яку пропонує сервер. Ви реєструєте сервер у deco Studio, а потім відкриваєте лише одну дозволену функцію для свого тестового агента.
Наприклад, ваш MCP-сервер може пропонувати десять функцій: читання файлу, запис файлу, запит до бази даних, мережеве отримання даних та інші. Ви обираєте одну нешкідливу операцію, можливо, пісочницю-калькулятор або запит лише для читання синтетичних даних, і відкриваєте тільки її. Інші дев'ять стають невидимими для агента. Якщо агент запитає їх, платформа управління видасть категоричну відмову.
Це принцип найменших привілеїв, перенесений у механічну площину. Агент отримує можливості не через ввічливу інструкцію, а через програмну межу.
Тестування меж
Створіть тестового агента та спрямуйте його на вашу платформу управління deco Studio. Дайте йому завдання, яке потребує єдиної дозволеної функції. Поспостерігайте за його успішним виконанням. Журнали всередині Studio покажуть запит моделі, маршрутизацію виклику інструменту через платформу управління, виконання функції та повернення результату моделі. Ви зможете прочитати весь шлях у вигляді єдиного безперервного трасування.
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
Додаткова спільнота для навчання: GyaanSetu AI у Telegram