Wenn ein KI-Agent seine eigenen Zugangsdaten mit sich führt und direkt an externe Dienste „nach Hause telefoniert“, verhält er sich weniger wie eine Mitarbeiter-Software und mehr wie ein externer Dienstleister mit einer Firmenkreditkarte und ohne Vorgesetzten. Man kann nicht sehen, worauf er zugegriffen hat, wer den Zugriff genehmigt hat oder warum ein Gespräch zehnmal mehr gekostet hat als ein anderes. Die Logs sind über ein Dutzend Dienste fragmentiert. Die Fragen häufen sich.

Welches Tool hat der Agent tatsächlich aufgerufen? Wer hat ihm die Erlaubnis erteilt, auf diese Datenbank zuzugreifen? Warum hat der Durchlauf am Dienstag vierzigtausend Token verbraucht, während am Montag nur fünf genutzt wurden? Wie viel haben wir wirklich ausgegeben?

Ohne eine zentrale Steuerungsebene zwischen Nutzern, Modellen und Diensten bleiben diese Fragen unbeantwortet. Sie benötigen eine einzige Ebene, die jede Verbindung einmal registriert, nur den engen Satz an Funktionen freigibt, den ein Agent wirklich benötigt, und jede Ausführung vollständig aufzeichnet. Dieser Artikel führt durch ein fortgeschrittenes Lab, in dem deco Studio als diese lokale Steuerungsebene dient. Sie werden es einrichten, einen sicheren Model Context Protocol-Server verbinden, genau eine erlaubte Funktion freigeben und beobachten, was passiert, wenn ein Agent versucht, über seine Grenzen hinauszugehen.

Das Problem mit verstreuten Zugangsdaten

Stellen Sie sich ein typisches Team-Setup vor. Ein Entwickler verbindet einen Agenten über einen persönlichen Schlüssel mit einer Such-API. Ein anderer schaltet denselben Agenten an eine Produktionsdatenbank an, weil die Demo harmlos aussah. Ein Dritter fügt ein Tool zur Rechnungsabfrage hinzu, damit der Agent bei „Rechnungen helfen“ kann. Jede Verbindung ist für die anderen unsichtbar. Der Agent hat nun direkten Zugriff auf die Suche, auf Produktionsdaten und auf Finanzunterlagen, aber das Team hat keine einheitliche Liste darüber, was tatsächlich aktiv ist.

Wenn Zugangsdaten innerhalb des Agenten liegen, bricht die Governance zusammen. Sie können den Zugriff nicht zentral entziehen, da der Schlüssel im Speicher des Agenten oder in dessen lokaler Umgebungsvariable liegt. Sie können die Nutzung nicht prüfen, da der externe Dienst nur einen API-Aufruf von einem anonymen, automatisierten Client sieht. Die Kostenüberraschungen tauchen erst Tage später auf einer Cloud-Rechnung auf, und bis dahin erinnert sich niemand mehr daran, welcher Prompt den Anstieg ausgelöst hat.

Aufbau Ihrer Steuerungsebene in deco Studio

deco Studio löst dieses Problem, indem es als lokaler Hub fungiert. Sie führen es auf Ihrem eigenen Rechner aus, und es wird zum zentralen Ort, an dem die Konfigurationen liegen. Anstatt API-Schlüssel und Tool-Definitionen über verschiedene Agenten zu verstreuen, registrieren Sie eine Verbindung einmal innerhalb von Studio. Dann entscheiden Sie genau, welche Funktionen jeder Agent sehen kann.

Stellen Sie es sich wie die Installation einer Telefonzentrale vor. Alle Leitungen laufen in einem Raum zusammen. Sie wählen aus, welche Leitungen mit welchen Abteilungen verbunden sind, und führen Protokoll über jeden Anruf.

Beginnen Sie damit, deco Studio lokal auszuführen. Sobald es läuft, zentralisieren Sie die Konfiguration. Jeder Agent, der ein Tool nutzen möchte, muss nun die Steuerungsebene fragen und nicht mehr direkt den externen Dienst. Dies schafft sofort einen Engpass, an dem Sie beobachten, filtern und protokollieren können.

Verbindung eines sicheren MCP-Servers

In diesem Lab verbinden Sie einen Model Context Protocol-Server. MCP ist ein offener Standard, der es Modellen ermöglicht, mit externen Tools zu interagieren, aber Standards garantieren keine Sicherheit. Der entscheidende Schritt hier ist die Selektivität. Sie legen nicht blind jeden Endpunkt offen, den der Server anbietet. Sie registrieren den Server in deco Studio und geben dann nur eine einzige erlaubte Funktion für Ihren Test-Agenten frei.

Beispielsweise könnte Ihr MCP-Server zehn Funktionen anbieten: Datei lesen, Datei schreiben, Datenbankabfrage, Netzwerkabruf und andere. Sie wählen eine harmlose Operation aus, vielleicht einen sandboxed Rechner oder eine schreibgeschützte Abfrage von synthetischen Daten, und geben nur diese frei. Die anderen neun werden für den Agenten unsichtbar. Wenn der Agent danach fragt, antwortet die Steuerungsebene mit einer strikten Ablehnung.

Dies ist das Prinzip der geringsten Berechtigung (Principle of Least Privilege), das mechanisch umgesetzt wird. Der Agent erhält Fähigkeiten nicht durch eine höfliche Anweisung, sondern durch eine Software-Grenze.

Die Grenze testen

Erstellen Sie einen Test-Agenten und richten Sie ihn auf Ihre deco Studio Steuerungsebene aus. Geben Sie ihm eine Aufgabe, die die einzige erlaubte Funktion erfordert. Beobachten Sie den Erfolg. Die Logs in Studio zeigen die Modellanfrage, das Routing des Tool-Aufrufs über die Steuerungsebene, die Funktionsausführung und das Ergebnis, das zum Modell zurückfließt. Sie können den gesamten Pfad in einem einzigen, durchgehenden Trace lesen.

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

Optionale Lerngemeinschaft: GyaanSetu AI auf Telegram