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

# Segurança

> Como o conector o autentica, o que guarda, e aquilo que se recusa deliberadamente a fazer.

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:

| Documento                                 | Norma                                  |
| ----------------------------------------- | -------------------------------------- |
| `/.well-known/oauth-protected-resource`   | RFC 9728                               |
| `/.well-known/oauth-authorization-server` | RFC 8414                               |
| `POST /register`                          | RFC 7591, registo dinâmico de clientes |

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.

<Note>
  Esta é a defesa contra a interceção do código de autorização: um atacante que
  conheça o seu `client_id` continua a não poder pedir que o código seja entregue
  no seu próprio servidor, porque o URI está selado no identificador e é
  verificado antes de o formulário de início de sessão sequer ser apresentado.
</Note>

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](/pt/mcp/permissions) 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](mailto: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.