> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hi-doctor.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Sicurezza e protezione dei dati

> Come il connettore La autentica, che cosa conserva e che cosa si rifiuta deliberatamente di fare.

Il server MCP di Hi-Doctor è un **resource server** OAuth 2.1. Non possiede
alcun database di pazienti: ogni chiamata a uno strumento viene inoltrata
all'API di Hi-Doctor come *Lei*, con le autorizzazioni del Suo account.

## L'accesso

Il collegamento esegue un normale flusso OAuth 2.1 di tipo authorization code
con **PKCE** (`S256`). Il Suo client IA non vede mai la Sua password: la
inserisce su una pagina di Hi-Doctor e il client riceve un codice di
autorizzazione di breve durata che scambia con un token.

Il server pubblica i documenti di discovery che un client MCP si aspetta, quindi
non serve alcuna configurazione manuale:

| Documento                                 | Standard                                    |
| ----------------------------------------- | ------------------------------------------- |
| `/.well-known/oauth-protected-resource`   | RFC 9728                                    |
| `/.well-known/oauth-authorization-server` | RFC 8414                                    |
| `POST /register`                          | RFC 7591, registrazione dinamica dei client |

I codici di autorizzazione sono **monouso** e di breve durata. Riscattarne uno
due volte fallisce: un codice riutilizzato viene respinto, non accettato.

## Dove può essere restituito un token

A ogni client registrato viene rilasciato un `client_id` firmato che **vincola
l'esatto redirect URI** con cui si è registrato. Al momento dell'autorizzazione
il `redirect_uri` richiesto deve corrispondere esattamente a quel vincolo.

<Note>
  È la difesa contro l'intercettazione del codice di autorizzazione: un aggressore
  che conosca il Suo `client_id` non può comunque chiedere che il codice venga
  consegnato al proprio server, perché l'URI è sigillato nell'identificativo e
  viene verificato prima ancora che compaia il modulo di accesso.
</Note>

I redirect verso loopback seguono la RFC 8252 §7.3: la porta può variare, come
richiedono i client desktop, ma il resto dell'URI deve corrispondere.

## Token

I token di accesso sono **envelope cifrati in AES-256-GCM**, non credenziali di
backend in chiaro. Un envelope è vincolato al proprio audience e viene respinto
se è manomesso, riutilizzato verso la risorsa sbagliata o presentato dopo la
scadenza del token di backend che racchiude. Un envelope di refresh non può
essere usato dove ne è richiesto uno di accesso.

La Sua password Hi-Doctor viene scambiata con un token al momento dell'accesso e
non viene mai conservata dal connettore, mai scritta in un log e mai trasmessa
all'applicazione che si collega.

## Autorizzazioni

Gli strumenti sono raggruppati e ogni gruppo richiede il proprio scope: profilo,
consulti, messaggi, questionari, progressi, pagamento. Uno strumento il cui
scope non è stato concesso non viene semplicemente rifiutato: **non viene
offerto**, non compare mai nell'elenco degli strumenti del client.

I ruoli non si sommano. A un account corrisponde esattamente un catalogo di
strumenti, quindi un token da paziente non può mai raggiungere uno strumento
clinico o di back-office. L'elenco completo delle concessioni è in
[Autorizzazioni](/it/mcp/permissions).

## Che cosa il server si rifiuta di far trapelare

* **I corpi delle risposte `5xx` del backend vengono scartati per intero.** Un
  errore a monte restituisce un guasto generico e stabile, non una traccia
  interna.
* **Le risposte `4xx` sono filtrate su un elenco di campi strutturati
  consentiti**, così un errore può essere utile senza rimandare indietro dati
  del paziente nel risultato dello strumento.
* Gli argomenti di percorso non possono uscire dall'host API configurato né dal
  suo prefisso di versione.
* Il rate limiting è basato sul token, non su un header che il chiamante
  potrebbe modificare per ottenere un nuovo contatore.

## Pagamento

Il connettore non tratta mai i dati della carta. `hidoctor_checkout_create`
restituisce un link al checkout ospitato da Stripe, e le modifiche a carta,
piano e indirizzo di fatturazione avvengono nel portale di fatturazione Stripe.
Non esiste alcuno strumento che accetti un numero di carta: un assistente che
glielo chiede non sta parlando con Hi-Doctor.

## Limiti clinici

Nessun token, di alcun tipo, può approvare un consulto, emettere o modificare
una ricetta o cambiare un dosaggio. Quelle azioni non sono affatto esposte dal
server MCP: non sono protette da uno scope, semplicemente non ci sono.

L'idoneità medica è applicata dal backend di Hi-Doctor al momento dell'invio di
un questionario. Un assistente non può pre-approvare un paziente, e reinviare il
questionario con risposte diverse non aggira il controllo.

## Segnalare un problema

Scriva a [hello@hi-doctor.ai](mailto:hello@hi-doctor.ai) con i dettagli. Se
ritiene che dei dati di pazienti siano esposti, lo indichi nell'oggetto in modo
che la segnalazione venga trattata per prima.