The Pulse

Entire offre agli agenti di IA account di servizio per accedere ai repository

Entire ha introdotto account di servizio che consentono agli agenti di IA e ai processi automatizzati di accedere a repository selezionati senza un login umano. Ogni organizzazione o account può avere fino a cinque account di servizio tra i propri progetti.

AI.info Team · · verificato · su 3 fonti ↓ · Pubblicato 13 nov 2026

Gli agenti di IA e i processi automatizzati possono ora accedere a repository selezionati di Entire tramite account di servizio anziché con un login umano, ha dichiarato l’azienda in un post del 13 novembre. Gli account appartengono a singoli progetti e possono ricevere accesso in lettura, scrittura o amministrazione.

Ogni organizzazione o account può avere fino a cinque account di servizio tra i propri progetti. La funzionalità è disponibile nei progetti ospitati su Entire, ma non nei progetti mirror di GitHub.

Accesso all’interno di un progetto

A un account di servizio si può concedere l’accesso a un singolo repository o a tutti i repository del suo progetto, ma non può accedere ai repository di altri progetti. I ruoli disponibili sono gli stessi utilizzati per le persone e Entire consiglia di assegnare il ruolo più limitato che consenta all’account di svolgere il proprio compito.

I comandi che elencano i repository di un progetto richiedono un’autorizzazione che copra l’intero progetto. L’interfaccia web concede l’accesso ai singoli repository; l’accesso a tutti i repository di un progetto può essere concesso tramite l’interfaccia a riga di comando, o CLI.

Per creare un account sul sito web, una persona autorizzata a gestire il progetto apre le impostazioni del progetto, seleziona gli account di servizio e assegna un nome al nuovo account. La finestra di creazione fornisce un ID dell’account e un URL di autenticazione che i processi utilizzano per accedere; è quindi possibile selezionare l’accesso ai repository e un ruolo per quell’account.

Accesso con token della piattaforma

Per le piattaforme che emettono token OpenID Connect, o OIDC, un account di servizio può essere associato alla piattaforma una sola volta. Ogni processo o agente accede quindi con il proprio token di breve durata, senza bisogno di conservare un segreto dell’account di servizio.

GitHub Actions e Cursor sono tra le piattaforme che emettono questi token. Un’associazione contiene valori, chiamati pin, che il token di un processo deve soddisfare, come il nome di un repository; condizioni aggiuntive possono limitarla a un branch. Per un’associazione di GitHub Actions creata sul sito web, l’interfaccia fornisce un passaggio del workflow da aggiungere.

La documentazione elenca altre piattaforme, tra cui Amp, Buildkite, Devin, Google Cloud e Vercel. Un account di servizio può avere un’associazione per piattaforma. Secondo la documentazione, i token già emessi continuano a funzionare fino a 45 minuti dopo la rimozione di un’associazione.

Segreti per altre piattaforme

Per le piattaforme senza OIDC, un account di servizio può invece accedere con un segreto conservato nel luogo in cui viene eseguito il codice. Per impostazione predefinita, i segreti durano 90 giorni, con la possibilità di impostare una scadenza compresa tra 1 e 365 giorni. Ogni account può avere due segreti non scaduti, consentendo di crearne uno sostitutivo prima di rimuovere quello precedente.

Il segreto viene mostrato una sola volta quando viene creato tramite la CLI. È prevista la possibilità di creare segreti tramite il sito web, ma la funzione non è ancora disponibile.

Entire CLI, Git remote e Go SDK scambiano il segreto con un token dell’account di servizio e rinnovano il token quando necessario. Gli altri client HTTP effettuano lo scambio autonomamente. Un token ottenuto da un segreto dura al massimo 10 minuti e non può mai rimanere valido oltre la scadenza del segreto.