Managed AgentsManaged Agents self-hosted

Dati e accesso in Claude Managed Agents self-hosted

Copy page



Cosa invia all’esterno della tua rete Claude Managed Agents self-hosted, dove finiscono il suo log, le tracce e le metriche, per quanto tempo vengono conservati i dati, chi può raggiungere il server e come mantenere separati i tenant.

Con Claude Managed Agents self-hosted, sei tu a gestire il server, il suo database e le sandbox in cui i worker eseguono gli strumenti di shell e di file dell’agente. Questa pagina risponde alle domande di una revisione di sicurezza. Il provider di inferenza del server è il servizio che risponde alle sue chiamate al modello. Il server si connette ad Anthropic solo quando tale provider è la Claude API. Anthropic non ha accesso remoto al server né al suo log.

Cosa esce dalla tua rete

Ogni connessione stabilita dal server

Il server si connette solo a queste destinazioni:

• Il tuo provider di inferenza
• Il database del server
• I servizi che emettono la credenziale del server per le chiamate al modello, se ottiene tale credenziale da un servizio
• Il servizio di un provider cloud per l’elenco dei modelli, se il tuo provider di inferenza elenca i propri modelli su un servizio separato
• I server MCP che consenti
• Gli host Git che consenti, per i repository usati dalle sessioni
• Un collector OpenTelemetry, se ne configuri uno
• I provider di identità che elenchi per il single sign-on, se ne configuri
• Un gestore di segreti o un servizio di gestione delle chiavi, se ne configuri uno
• I servizi che emettono la credenziale del server per tale gestore di segreti o servizio di gestione delle chiavi
• Qualsiasi altro servizio che configuri affinché il server lo chiami

Il provider di inferenza predefinito è la Claude API. Se configuri un altro provider di inferenza, le chiamate al modello vengono invece inviate lì. Il server si connette ad Anthropic solo quando la Claude API è il suo provider di inferenza.

Se il provider di inferenza offre gli strumenti di ricerca web e di recupero web, è il provider stesso a eseguirli. Il server non stabilisce alcuna connessione propria per essi. Gli strumenti sono disattivati finché non li attivi nelle impostazioni del server.

Per verificare il traffico del server, confronta il log del tuo proxy di uscita o del tuo firewall con questo elenco. Le richieste del server alla Claude API contengono un header User-Agent. Vedi Campi che indicano il software del server.

Cosa possono raggiungere i worker

L’elenco delle destinazioni riguarda solo il server. L’egress gateway, se lo esegui, si connette agli host che elenchi per esso e invia loro i valori delle credenziali che memorizzi per essi. I worker sono separati. Un worker ha l’accesso di rete che consenti al container, alla VM o a un’altra sandbox in cui viene eseguito. Ogni comando che un agente esegue tramite il worker ha lo stesso accesso di rete.

Cosa invia il server al suo provider di inferenza

Ogni chiamata al modello contiene la conversazione fino a quel momento, inclusi prompt, input degli strumenti e risultati degli strumenti.

Quando la Claude API è il provider di inferenza, ogni chiamata al modello contiene anche fino a tre header. Questi contengono ID generati dal tuo server:

Un ID non contiene alcun nome né alcun contenuto, ma codifica il momento in cui il tuo server lo ha creato. Con questi header, Anthropic può attribuire l’utilizzo a una sessione, a un agente o a un ambiente. Nessuna impostazione li disattiva. Se ANTHROPIC_BASE_URL indica un proxy o un gateway, gli header vengono inviati lì. Con qualsiasi altro provider di inferenza, il server non li invia mai.

Quando la Claude API è il provider di inferenza, il server verifica inoltre con la Claude API che la sua credenziale per le chiamate al modello sia valida. Esegue la verifica all’avvio e poi ogni 60 secondi, a meno che tu non modifichi health.check_interval. Queste verifiche non eseguono alcuna inferenza e non contengono nessuno dei tre header.

Campi che indicano il software del server

Ogni richiesta alla Claude API ha un header User-Agent che indica il software del server e la sua versione. L’header di per sé non identifica il tuo deployment. Come in ogni richiesta alla Claude API, è la chiave API a identificare la tua organizzazione. Anthropic può usare tale header per conteggiare l’utilizzo di Managed Agents self-hosted.

Le chiamate al modello possono anche riportare l’etichetta cma-server, nel corpo della richiesta come metadata.user_id. L’etichetta è la stessa su ogni server, quindi l’etichetta in sé non identifica il tuo deployment, i tuoi utenti né le tue sessioni. Quando una chiamata raggiunge Anthropic, Anthropic può usare l’etichetta per conteggiare l’utilizzo di Managed Agents self-hosted, anche se un proxy ha rimosso l’header User-Agent.

Che una chiamata riporti o meno l’etichetta dipende dalla sua destinazione:

• Il server invia l’etichetta in queste chiamate: chiamate verso la Claude API, verso Microsoft Foundry e verso un model gateway che accetta le stesse richieste della Claude API.
• Il server non invia mai metadata.user_id in queste chiamate: chiamate verso Amazon Bedrock, verso Claude Models on Google Cloud (Google managed) e verso un model gateway che accetta un altro formato di richiesta.

Se un model gateway o un proxy inoltra una chiamata a un altro provider, metadata.user_id può accompagnarla. Nelle chiamate che riportano metadata.user_id, un tuo proxy o gateway deve accettarlo nel corpo della richiesta. Se rifiuta il campo, ogni chiamata al modello non va a buon fine.

Dove finiscono il log, le tracce e le metriche

Il server scrive il proprio log sullo standard error. Quando esegui il server con Docker, Kubernetes o un gestore di servizi, quel sistema raccoglie il log dallo standard error.

Il server non registra tracce o metriche finché non le attivi con le variabili d’ambiente standard di OpenTelemetry. Le invia solo alla destinazione indicata da tali variabili. Anche un endpoint Prometheus può esporre metriche. Vedi Dove è in ascolto il server.

Per quanto tempo vengono conservati i dati

La tua pipeline di log, il tuo collector e il tuo backend di tracciamento decidono per quanto tempo vengono conservati i log, le tracce e le metriche. Il server non conserva file di log e non archivia tracce né metriche.

Il server memorizza tutto il resto, come agenti, sessioni e cronologia delle sessioni, nel tuo database. Se non configuri alcun database, che è l’impostazione predefinita, il server mantiene quei dati in memoria e un riavvio li cancella. Se configuri un gestore di segreti, il server conserva lì, invece che nel database, il segreto di ogni nuova credenziale del vault. I segreti che ha memorizzato in precedenza restano nel database.

Le sessioni e la loro cronologia restano nel tuo database finché non le elimini. Il server non elimina una sessione a causa della sua età, che sia archiviata o meno. L’eliminazione di una sessione tramite l’API rimuove la sessione e la sua cronologia dal tuo database, anche se il server conserva l’ID della sessione. Il server può rifiutare l’eliminazione mentre una sessione è in esecuzione. L’eliminazione non raggiunge le copie presenti altrove, come i backup del database, i log e le tracce esportati, o ciò che l’agente ha scritto in un memory store. Su Kubernetes, l’eliminazione lascia inoltre al suo posto il volume /workspace della sessione, come descritto in Liberare il volume di una sessione.

Ciò che il server invia al modello, e ciò che il modello restituisce, rientra nell’accordo della tua organizzazione con il provider che fornisce il modello. Si applicano i termini di conservazione dei dati dell’accordo. Quando il modello è fornito tramite la Claude API, si applicano l’accordo e le impostazioni di conservazione dei dati che la tua organizzazione ha con Anthropic. Se la tua organizzazione ha una modalità conservazione zero dei dati (ZDR), questa copre queste chiamate al modello allo stesso modo delle altre chiamate alla Messages API.

La pagina API e conservazione dei dati elenca Claude Managed Agents come non coperto dalla ZDR. Questo perché, quando è Anthropic a eseguire il servizio, memorizza le trascrizioni delle sessioni finché non le elimini. Chi memorizza le trascrizioni dipende da chi esegue il servizio:

• Lo esegue Anthropic: è Anthropic a memorizzarle. Con le sandbox self-hosted, ospiti solo le sandbox, mentre è Anthropic a eseguire il resto.
• Lo esegui tu, con Managed Agents self-hosted: sei tu a memorizzarle.

Chi può raggiungere il server

Anthropic non ha accesso remoto al server né al suo log. Le tue applicazioni e i tuoi worker si connettono al server. Il server non si connette mai a un worker.

Credenziali accettate dal server

Anthropic non emette nessuna delle credenziali accettate dal server e non ne detiene nessuna. Ogni credenziale accettata dal server è una delle seguenti:

• Una che hai impostato o creato tu
• Una emessa dal tuo provider di identità
• Una generata dal server stesso, come il token che consegna a un worker con ogni unità di lavoro

Dove è in ascolto il server

Il server accetta richieste API su un unico indirizzo e porta. Il server apre altri due listener, ciascuno solo se lo attivi.

Ulteriori dettagli sugli ultimi due listener:

• L’endpoint delle metriche Prometheus: non richiede alcuna credenziale, quindi chi può raggiungerlo dipende da dove è in ascolto. Se imposti OTEL_METRICS_EXPORTER su prometheus e non imposti alcun indirizzo, è in ascolto sull’indirizzo predefinito. Se lo attivi tramite il chart Helm del server, è in ascolto sulla porta 9464 di ogni pod del server. Qualsiasi cosa con un percorso verso l’indirizzo di un pod può quindi raggiungerlo, a meno che una NetworkPolicy non blocchi quel traffico.
• Il listener per l’egress gateway: l’egress gateway è un proxy opzionale tra le tue sandbox e internet. Il server è in ascolto per il gateway su una porta separata. Questo listener usa HTTP semplice e le sue risposte contengono i valori delle credenziali memorizzate. Lo stack Compose e il chart Helm del server consentono solo al gateway di raggiungerlo. Se esegui il server in qualsiasi altro modo, fai lo stesso.

Lo stack Docker Compose pubblica la porta 8400 sull’indirizzo di loopback dell’host Docker, 127.0.0.1. Esegui Docker Engine 28.3.3 o successivo. Con alcune release precedenti, le macchine sulla rete locale dell’host possono raggiungere una porta pubblicata sul loopback. Per pubblicare la porta su un altro indirizzo, imposta CMA_PUBLISH_ADDRESS in .env.

Multitenancy

Ogni deployment serve un solo “tenant” (locatario) a un unico livello di attendibilità. Gli ambienti all’interno di un unico deployment non mantengono separati i livelli di attendibilità. La chiave API del server raggiunge ogni ambiente. Ogni chiamante con un ruolo può eseguire sessioni in ogni ambiente, con qualsiasi rete e file che i worker di quell’ambiente possono raggiungere.

Gestori di segreti, single sign-on e model gateway

Se i tuoi deployment usano uno di questi servizi, mantienili separati anche lì:

• Gestore di segreti: mantieni separati i segreti dei deployment, come indicato nei limiti del gestore di segreti.
• Single sign-on: assegna a ogni deployment voci audiences che nessun altro deployment elenca, in modo che rifiuti i token degli altri deployment. Nel deployment di ciascun livello di attendibilità, assegna un ruolo solo ai chiamanti consentiti a quel livello e non impostare alcun default_role.
• Model gateway: per distinguere i deployment, assegna a ciascuno un proprio valore per un header come x-tenant-id in inference.headers.

Cosa non limitano i ruoli

I ruoli limitano solo le richieste che un chiamante effettua con il proprio token. Il codice eseguito da un agente può chiamare il server con qualsiasi credenziale contenuta nella sua sandbox. Una chiave di ambiente può leggere gli eventi e pubblicare i risultati degli strumenti in ogni sessione nel suo ambiente. Quindi esegui ogni sessione in una sandbox propria e tieni la chiave di ambiente fuori da quella sandbox. Gli stack in Iniziare con Claude Managed Agents self-hosted e Eseguire il deployment su Kubernetes fanno questo.