Segurança

O servidor MCP da Hi-Doctor é um servidor de recursos OAuth 2.1. Não tem base de dados de pacientes própria — cada chamada de ferramenta é reencaminhada para a API da Hi-Doctor em seu nome, com as permissões da sua conta.

​

Início de sessão

A ligação executa um fluxo padrão OAuth 2.1 de código de autorização com PKCE (S256). O seu cliente de IA nunca vê a sua palavra-passe: esta é introduzida numa página da Hi-Doctor, e o cliente recebe um código de autorização de curta duração que troca por um token. O servidor publica os documentos de descoberta que um cliente MCP espera encontrar, pelo que não é necessária qualquer configuração manual: Os códigos de autorização são de utilização única e de curta duração. Resgatar o mesmo código duas vezes falha — um código repetido é rejeitado, não aceite.

​

Para onde um token pode ser devolvido

A cada cliente registado é emitido um client_id assinado que vincula o URI de redirecionamento exato com que se registou. No momento da autorização, o redirect_uri pedido tem de corresponder exatamente a esse vínculo. Os redirecionamentos de loopback seguem a RFC 8252 §7.3 — a porta pode variar, como exigem as aplicações de ambiente de trabalho, mas o resto do URI tem de corresponder.

​

Tokens

Os tokens de acesso são envelopes cifrados com AES-256-GCM, e não credenciais de backend em bruto. Um envelope está vinculado à sua audiência e é rejeitado se for adulterado, reutilizado contra o recurso errado, ou apresentado depois de expirar o token de backend que encapsula. Um envelope de renovação não pode ser usado onde é exigido um envelope de acesso. A sua palavra-passe da Hi-Doctor é trocada por um token no início de sessão e nunca é guardada pelo conector, nunca é escrita num registo, e nunca é transmitida à aplicação que se liga.

​

Permissões

As ferramentas estão agrupadas, e cada grupo exige o seu próprio âmbito (scope) — perfil, consultas, mensagens, questionários, progresso, pagamento. Uma ferramenta cujo âmbito não tenha concedido não é apenas recusada: não é sequer oferecida, nunca chega a aparecer na lista de ferramentas do cliente. Os perfis não se acumulam. Cada conta tem exatamente um catálogo de ferramentas, pelo que um token de paciente nunca consegue alcançar uma ferramenta de clínico ou de back-office. Consulte Permissões para a lista completa de concessões.

​

O que o servidor se recusa a divulgar

• Os corpos das respostas 5xx do backend são inteiramente descartados. Um erro a montante devolve uma falha genérica e estável, em vez de um rastreio interno.
• As respostas 4xx são filtradas por uma lista restrita de campos estruturados, para que um erro possa ser acionável sem devolver dados do paciente através do resultado da ferramenta.
• Os argumentos de caminho não conseguem sair do host de API configurado nem do respetivo prefixo de versão.
• A limitação de pedidos é indexada ao token, e não a um cabeçalho que quem chama pudesse manipular para obter um contador novo.

​

Pagamento

O conector nunca lida com dados de cartões. hidoctor_checkout_create devolve um link para o checkout alojado pela própria Stripe, e as alterações ao cartão, ao plano e à morada de faturação acontecem no portal de faturação da Stripe. Não existe nenhuma ferramenta que aceite um número de cartão, e qualquer assistente que lho peça não está a comunicar com a Hi-Doctor.

​

Limites clínicos

Nenhum token, de espécie alguma, pode aprovar uma consulta, emitir ou alterar uma receita médica, ou alterar uma dose. Essas ações não são de todo disponibilizadas pelo servidor MCP — não estão protegidas por um âmbito, simplesmente não existem. A elegibilidade clínica é imposta pelo backend da Hi-Doctor quando um questionário é submetido. Um assistente não pode pré-aprovar um paciente, e voltar a submeter com respostas diferentes não contorna a verificação.

​

Comunicar um problema

Escreva para hello@hi-doctor.ai com os detalhes. Se acredita que existem dados de pacientes expostos, indique-o no assunto para que seja tratado com prioridade.