> For the complete documentation index, see [llms.txt](https://docs.aisuru.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aisuru.com/condivisione/security-access-and-visibility.md).

# Sicurezza, accesso e visibilità

Condividere un Agente e renderlo individuabile pubblicamente sono due decisioni diverse.

AIsuru ti consente di controllare **chi può accedere a un Agente** e, separatamente, se l'Agente deve essere **visibile dalla homepage della piattaforma**. Mantenere separati questi concetti ti aiuta a evitare di considerare accidentalmente la visibilità come un meccanismo di sicurezza.

### Modelli di accesso

Un Agente può utilizzare uno dei tre modelli di accesso:

| Modello di accesso | Chi può accedervi                                                                                | Protezione                                        |
| ------------------ | ------------------------------------------------------------------------------------------------ | ------------------------------------------------- |
| `PUBLIC`           | Chiunque                                                                                         | Non è richiesta alcuna password                   |
| `PRIVATE`          | Solo gli utenti o le integrazioni che forniscono il token segreto richiesto generato dal sistema | Protetto da un token segreto generato dal sistema |

#### PUBBLICO

Un Agente `PUBLIC` non ha password e può essere accessibile a chiunque riesca a raggiungerlo.

Utilizza questo modello quando l'Agente è destinato a un pubblico ampio e i suoi contenuti e il suo comportamento sono adatti all'accesso pubblico.

#### PRIVATO

Un Agente `PRIVATE` è protetto da un token segreto generato dal sistema.

L'Agente non è liberamente accessibile: il token richiesto deve essere fornito prima di poter aprire una sessione.

Questo modello è particolarmente rilevante per le integrazioni controllate, in cui le credenziali di accesso sono gestite dall'applicazione anziché inserite manualmente da un utente finale.

### L'accesso e la visibilità nella homepage sono separati

Il modello di accesso dell'Agente determina **se qualcuno è autorizzato ad aprirlo e utilizzarlo**.

La visibilità nella homepage determina **se le persone possono scoprire l'Agente dalla homepage di AIsuru**.

Queste impostazioni non devono essere confuse.

Ad esempio, nascondere un Agente `PUBLIC` dalla homepage non rende privato l'Agente. Se qualcuno possiede già un link valido a un Agente pubblico, l'assenza dell'Agente dalla homepage non costituisce una limitazione dell'accesso.

Allo stesso modo, rendere visibile un Agente in una sezione di individuazione non rimuove i requisiti di accesso di un Agente protetto.

### Scegli la combinazione giusta

| Obiettivo                                                      | Accesso   | Visibilità nella homepage                                      |
| -------------------------------------------------------------- | --------- | -------------------------------------------------------------- |
| Rendi l'Agente individuabile pubblicamente                     | `PUBLIC`  | Visibile                                                       |
| Condividi un Agente aperto solo tramite canali selezionati     | `PUBLIC`  | Non visibile                                                   |
| Limita l'accesso tramite credenziali gestite dall'applicazione | `PRIVATE` | Configura la visibilità in base allo scenario di pubblicazione |
| Richiedi una password prima dell'accesso                       | `SECRET`  | Configura la visibilità in base allo scenario di pubblicazione |

> **Importante:** La visibilità nella homepage è un'impostazione per la rilevabilità, non una barriera di sicurezza. Usa il modello di accesso dell'Agente quando l'accesso deve essere effettivamente limitato.

### Condivisione di un Agente protetto

Un link identifica dove gli utenti possono accedere a un Agente, ma non prevale sul modello di accesso dell'Agente.

Se l'Agente è protetto, le informazioni di autenticazione richieste devono comunque essere fornite prima di poter aprire una sessione.

### Autenticazione nelle integrazioni personalizzate

Le integrazioni per sviluppatori possono trasmettere le informazioni di autenticazione a livello di codice.

Il riferimento attuale del componente Frontend include, tra gli altri parametri di sessione e autenticazione:

* `authToken`, per un utente autenticato;
* `secretToken`, per il segreto/password richiesto da un Agente protetto;
* `sessionID`, per identificare una sessione di conversazione.

Si tratta di controlli a livello di sviluppatore. Non aggiungere manualmente token o credenziali a un'integrazione se non sai quale valore si aspetta il componente attuale.

### Prima di pubblicare un Agente

Prima di distribuire un Agente tramite un link, un sito web, WordPress, un dispositivo fisico o un altro canale, verifica che:

1. il modello di accesso selezionato corrisponda al pubblico previsto;
2. gli Agenti protetti richiedano la credenziale prevista prima dell'accesso;
3. la visibilità nella homepage corrisponda ai tuoi requisiti di rilevabilità;
4. un Agente pubblico nascosto dalla homepage non venga considerato privato;
5. qualsiasi integrazione con sito web o applicazione gestisca l'autenticazione in base alla documentazione Frontend attuale.