

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Strategia di governance MCP
<a name="mcp-governance-strategy"></a>

L'altra funzionalità fondamentale che MCP offre alle organizzazioni è il supporto per la governance centralizzata. La vostra strategia di governance MCP dovrebbe riguardare l'autenticazione e l'autorizzazione sia per i server MCP che per le risorse a cui accedono. Dovrebbe inoltre riguardare la limitazione della velocità per proteggere le risorse a valle, le metriche operative per il monitoraggio dell'utilizzo e delle prestazioni degli strumenti e la gestione delle implementazioni e della distribuzione dei server MCP.

## Autenticazione e autorizzazione
<a name="mcp-governance-strategy-auth"></a>

Una delle parti più importanti della strategia di autenticazione e autorizzazione è la gestione dell'accesso alle risorse a valle dai server MCP. Quando un utente chiama un agente, vengono eseguite l'autenticazione e l'autorizzazione per garantire che l'utente disponga delle autorizzazioni per chiamare l'agente. Quindi, l'agente orchestra la chiamata di strumenti specifici nei server MCP. È necessario decidere come autorizzare l'accesso in base allo strumento.

Un'opzione è l'*machine-to-machine autorizzazione*, in cui non è richiesto il consenso o l'interazione dell'utente. Ad esempio, una chiamata di un agente basata sul tempo utilizza un server MCP per raccogliere i log da un'applicazione e analizzarli. In questo scenario, l'agente è preautorizzato ad accedere ai dati specificati. La seconda opzione è l'*accesso delegato dall'utente*, in cui un utente fornisce il proprio consenso all'accesso a dati e risorse specifici dell'utente.

La tabella seguente mostra i modelli di autenticazione e autorizzazione.


| 
| 
| **Fattore** | **Accesso delegato dall'utente** | **Machine-to-machine** | 
| --- |--- |--- |
| Proprietà dei dati | Autorizzazione specifica dell'utente ai dati | Dati a livello di sistema o organizzazione | 
| Interazione con l'utente | L'utente è presente e può acconsentire | Nessuna interazione con l'utente | 
| Tempistica delle operazioni | Interattivo o in tempo reale | In background, pianificato o in batch | 
| Ambito dell'autorizzazione | Le autorizzazioni variano in base all'utente | Autorizzazioni coerenti a livello di agente | 

L'accesso delegato dall'utente richiede un'implementazione attenta e deve essere sviluppato con il team di sicurezza. Gli agenti devono essere in grado di valutare quali strumenti ha selezionato un LLM e se richiedono un'autorizzazione aggiuntiva. Gli strumenti MCP devono includere descrizioni per indicare i requisiti di autenticazione e autorizzazione e dove recuperare i token di accesso. Le applicazioni client devono supportare richieste di autenticazione intermedie e il client MCP deve fornire le credenziali recuperate all'agente per ogni chiamata allo strumento.

È necessario assicurarsi che gli strumenti MCP dispongano sempre dei propri token per accedere alle funzionalità esterne e che l'accesso sia registrato e verificato. Le credenziali utente non devono essere propagate attraverso il sistema agentic. Ad esempio, i server MCP non devono utilizzare lo stesso token per accedere ai dati utilizzati per richiamare l'agente. Le chiamate downstream devono utilizzare token con ambito esplicito e generati appositamente. Questo aiuta a fornire barriere aggiuntive per impedire l'accesso involontario ai dati per conto di azioni. Può anche aiutare a prevenire che le allucinazioni producano risultati indesiderati. Immaginate che un utente con autorizzazioni amministrative complete chieda a un agente di clonare un database di produzione da utilizzare in fase di pre-produzione. A tal fine, l'utente necessita solo delle autorizzazioni e dei permessi necessari`READ`. `CREATE` Supponiamo che l'LLM abbia allucinazioni e creda di dover ripulire il vecchio database come parte di questa richiesta. Se riutilizza le credenziali dell'utente, probabilmente avrà successo perché le credenziali originali dell'utente dispongono delle autorizzazioni. `DELETE` Invece, se il server MCP utilizza un token intenzionalmente ridotto per la richiesta con solo `READ` e `CREATE` autorizzazioni, il tentativo di eliminare il database di produzione fallirebbe.

Puoi utilizzare [Amazon Bedrock AgentCore Identity](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/common-use-cases.html) per contribuire all'implementazione di questi modelli. Assicurati di scegliere intenzionalmente se le autorizzazioni per elencare e richiamare gli strumenti ospitati da un server MCP implichino l'autorizzazione alle funzionalità esterne esposte dal server MCP. Questo flusso di identità dal server MCP alla risorsa e viceversa all'utente dipende dal tipo di servizio di autenticazione e autorizzazione utilizzato. È necessario decidere come gestirlo su larga scala per i server MCP.

Durante la progettazione dei modelli di autenticazione e autorizzazione, implementate meccanismi di isolamento dei token che recuperino token di accesso diversi per ogni strumento a cui si accede. Non riutilizzate i token tra strumenti e server. AgentCore L'identità fornisce questa funzionalità di isolamento dei token. Gestisce automaticamente sia i token del carico di lavoro (per machine-to-machine l'autenticazione) che i token utente (per l'accesso delegato dall'utente) per garantire una separazione adeguata e prevenire l'aumento delle autorizzazioni. Ciò è particolarmente importante quando si incorporano server MCP remoti o gateway MCP.

### Le migliori pratiche per l'autenticazione e l'autorizzazione MCP
<a name="mcp-governance-strategy-auth-best-practices"></a>
+ **Separazione dei token**: non trasferite i token portatori dai chiamanti ai servizi a valle. Convalida che il campo aud (audience) corrisponda al server che riceve il token. L'indicazione audience specifica a quale servizio è destinato il token, impedendo il riutilizzo non autorizzato del token su diversi server MCP.
+ **Seleziona un approccio di accesso**: scegli tra machine-to-machine l'accesso delegato dall'utente per ogni strumento fornito dai server MCP. Prendi in considerazione la possibilità di raggruppare gli strumenti nello stesso server MCP che utilizzano lo stesso modello di autenticazione.

## Controllo del carico
<a name="controlling-load"></a>

Come con qualsiasi sistema distribuito, è necessario considerare come controllare il carico nel parco server MCP. Innanzitutto, valutate se implementare la limitazione della velocità nei server MCP e dove implementarla. Se scegliete di non implementare la limitazione della velocità, trasferite qualsiasi limitazione di velocità eseguita dalle risorse a valle. Molti sistemi scelgono di limitare la velocità in base agli attributi della richiesta, come l'ID utente o l'account. Verifica che le richieste inviate ai servizi downstream contengano gli stessi attributi in modo che più utenti non siano influenzati dal carico generato da un altro utente.

Se scegli di implementare la limitazione della velocità, l'approccio consigliato consiste nell'implementare la limitazione della velocità principale a livello del server MCP, con servizi di backend che forniscono una protezione secondaria e agenti che adattano il loro comportamento in base al feedback sul limite di velocità. Valuta se i limiti di velocità sono per server MCP o per strumento. I limiti di velocità per server MCP aiutano a proteggere la flotta e i servizi di server MCP in un ambiente multi-tenant. Tuttavia, ciò può essere molto complicato. I limiti di velocità per utensile sono stati progettati per evitare che le risorse a valle vengano sovraccaricate, che potrebbero non essere sufficientemente limitate. Se uno strumento effettua chiamate multiple APIs, è necessario impostare il limite di velocità in modo che corrisponda alla tariffa più bassa consentita da tali strumenti. APIs

L'inserimento delle informazioni sui limiti di velocità nelle intestazioni HTTP può inoltre essere una metrica utile per gli utenti e i sistemi automatizzati per gestire la propria strategia relativa alla frequenza di richieste e ai tentativi. Ad esempio, è possibile inviare queste intestazioni all'agente dal server MCP, come illustrato nell'esempio seguente:

```
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 45
X-RateLimit-Reset: 1640995200
```

Inoltre, prendete in considerazione la riduzione del carico per proteggere l'intero servizio quando nessun cliente supera un limite di velocità, ma il carico influisce sulle prestazioni del sistema.

### Le migliori pratiche per il controllo del carico
<a name="mcp-governance-strategy-load-best-practices"></a>
+ **Scegliete un approccio basato sulla limitazione della velocità**: pianificate di limitare la velocità dei singoli utenti in base all'uso delle risorse downstream o all'uso del server e degli strumenti MCP.
+ **Prendi in considerazione la riduzione del carico: proteggi** la tua flotta di server MCP da un sovraccarico generale che non sia causato da un singolo o da una manciata di clienti.

## Parametri operativi
<a name="mcp-governance-strategy-metrics"></a>

Le metriche chiave da acquisire per le implementazioni MCP devono concentrarsi sull'esperienza del cliente che offrono. Queste metriche includono in genere l'utilizzo dei token, l'accuratezza della selezione degli strumenti, il numero di strumenti registrati con l'agente e la latenza degli strumenti. Ad esempio, il monitoraggio dei token di output restituiti da ogni strumento consente di impostare allarmi quando gli strumenti superano una soglia per l'utilizzo della finestra contestuale. Quando uno strumento supera tale soglia, potresti voler esaminare il comportamento dello strumento. Ciò si collega anche alla strategia di progettazione degli strumenti MCP. Le metriche di precisione nella selezione degli strumenti indicano in che misura gli agenti scelgono gli strumenti appropriati per determinate attività, mentre la velocità di esecuzione e le percentuali di successo evidenziano problemi di prestazioni e affidabilità.

Ad esempio, per valutare le metriche di selezione e precisione relative all'uso degli strumenti, i team hanno creato set di dati pregiati per i test di regressione. AWS I set di dati sono stati generati sinteticamente utilizzando i log di invocazione delle API storici sulle query degli utenti. LLMs Utilizzando le metriche predefinite di selezione e utilizzo degli strumenti (come la precisione della selezione degli strumenti, l'accuratezza dei parametri degli strumenti e l'accuratezza delle chiamate alle funzioni multigiro), i AWS team potevano valutare oggettivamente la capacità dell'agente AI di identificare correttamente gli strumenti appropriati, compilare i propri parametri con valori accurati e mantenere sequenze di invocazione degli strumenti coerenti durante i turni di conversazione.

La misurazione delle metriche relative al numero di strumenti registrati con un agente può aiutarti a identificare potenziali problemi di gestione delle finestre di contesto, nonché le modifiche agli strumenti disponibili presentati dai server MCP. È necessario rivedere regolarmente le metriche operative che indicano l'esperienza utente con il server e gli strumenti MCP.