Sicurezza e protezione dei dati

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: 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. 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.

​

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 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.