Quando un agente AI porta con sé le proprie credenziali e comunica direttamente con servizi esterni, si comporta meno come un software aziendale e più come un consulente con una carta di credito aziendale e senza un supervisore. Non puoi vedere cosa ha toccato, chi ha approvato l'accesso o perché una conversazione è costata dieci volte più di un'altra. I log si frammentano tra una dozzina di servizi. Le domande si moltiplicano.

Quale strumento ha effettivamente invocato l'agente? Chi gli ha concesso il permesso di toccare quel database? Perché l'esecuzione di martedì ha consumato quarantamila token mentre quella di lunedì ne ha usati solo cinque? Quanto abbiamo speso realmente?

Senza uno strato di controllo centrale situato tra utenti, modelli e servizi, queste domande rimangono senza risposta. Hai bisogno di un unico piano che registri ogni connessione una sola volta, esponga solo l'insieme ristretto di funzioni di cui un agente ha realmente bisogno e registri ogni esecuzione per intero. Questo articolo illustra un laboratorio avanzato che utilizza deco Studio come piano di controllo locale. Lo configurerai, collegherai un server Model Context Protocol sicuro, esporrai esattamente una funzione consentita e osserverai cosa succede quando un agente tenta di andare oltre i suoi confini.

Il problema delle credenziali sparse

Immagina una tipica configurazione di un team. Uno sviluppatore collega un agente a un'API di ricerca utilizzando una chiave personale. Un altro collega lo stesso agente a un database di produzione perché la demo sembrava innocua. Un terzo aggiunge uno strumento di consultazione della fatturazione in modo che l'agente possa "aiutare con le fatture". Ogni connessione è invisibile alle altre. L'agente ha ora l'accesso diretto alla ricerca, ai dati di produzione e ai record finanziari, ma il team non ha un elenco unificato di ciò che è attivo.

Quando le credenziali risiedono all'interno dell'agente, la governance si interrompe. Non è possibile revocare l'accesso centralmente perché la chiave si trova nella memoria dell'agente o nel suo file di ambiente locale. Non è possibile auditare l'utilizzo perché il servizio esterno vede solo una chiamata API da un client automatizzato anonimo. Le sorprese sui costi compaiono giorni dopo in una fattura cloud e, a quel punto, nessuno ricorda quale prompt abbia innescato il picco.

Costruire il proprio piano di controllo in deco Studio

deco Studio risolve questo problema agendo come un hub locale. Lo esegui sulla tua macchina e diventa l'unico posto in cui risiedono le configurazioni. Invece di disperdere chiavi API e definizioni di strumenti tra vari agenti, registri una connessione una sola volta all'interno di Studio. Poi decidi esattamente quali funzioni ogni agente può vedere.

Immaginalo come l'installazione di un centralino. Tutti i cavi convergono in un'unica stanza. Scegli quali linee collegano quali reparti e tieni traccia di ogni chiamata.

Inizia eseguendo deco Studio localmente. Una volta avviato, centralizzi la configurazione. Ogni agente che desidera utilizzare uno strumento deve ora rivolgersi al piano di controllo, e non direttamente al servizio esterno. Questo crea immediatamente un punto di controllo dove puoi osservare, filtrare e registrare i log.

Collegare un server MCP sicuro

In questo laboratorio, collegherai un server Model Context Protocol. MCP è uno standard aperto che consente ai modelli di interagire con strumenti esterni, ma gli standard non garantiscono la sicurezza. Il passaggio critico qui è la selettività. Non esponi ciecamente ogni endpoint offerto dal server. Registri il server in deco Studio, quindi esponi solo una funzione consentita al tuo agente di test.

Ad esempio, il tuo server MCP potrebbe offrire dieci funzioni: lettura file, scrittura file, query al database, recupero di rete e altre. Scegli un'operazione innocua, magari una calcolatrice in sandbox o una consultazione in sola lettura su dati sintetici, ed esponi solo quella. Le altre nove diventano invisibili all'agente. Se l'agente le richiede, il piano di controllo restituisce un rifiuto netto.

Questo è il principio del minimo privilegio reso meccanico. L'agente riceve la capacità non tramite un'istruzione cortese, ma attraverso un confine software.

Testare il confine

Crea un agente di test e indirizzalo verso il tuo piano di controllo deco Studio. Assegnagli un compito che richieda l'unica funzione consentita. Osserva il suo successo. I log all'interno di Studio mostreranno la richiesta del modello, l'instradamento della chiamata allo strumento attraverso il piano di controllo, l'esecuzione della funzione e il risultato che torna al modello. Puoi leggere l'intero percorso in un'unica traccia continua.

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

Community di apprendimento opzionale: GyaanSetu AI su Telegram