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

# Security

> How the connector authenticates you, what it stores, and what it deliberately refuses to do.

The Hi-Doctor MCP server is an OAuth 2.1 **resource server**. It holds no
patient database of its own — every tool call is forwarded to the Hi-Doctor API
as *you*, with your own account's permissions.

## Signing in

Connecting runs a standard OAuth 2.1 authorization-code flow with **PKCE**
(`S256`). Your AI client never sees your password: you enter it on a Hi-Doctor
page, and the client receives a short-lived authorization code that it
exchanges for a token.

The server publishes the discovery documents an MCP client expects, so no
manual configuration is needed:

| Document                                  | Standard                             |
| ----------------------------------------- | ------------------------------------ |
| `/.well-known/oauth-protected-resource`   | RFC 9728                             |
| `/.well-known/oauth-authorization-server` | RFC 8414                             |
| `POST /register`                          | RFC 7591 dynamic client registration |

Authorization codes are **single-use** and short-lived. Redeeming one twice
fails — a replayed code is rejected, not honoured.

## Where a token can be sent back

Every registered client is issued a signed `client_id` that **binds the exact
redirect URI** it registered with. At authorization time the requested
`redirect_uri` must match that binding exactly.

<Note>
  This is the defence against authorization-code interception: an attacker who
  knows your `client_id` still cannot ask for the code to be delivered to their
  own server, because the URI is sealed into the identifier and verified before
  the sign-in form is ever shown.
</Note>

Loopback redirects follow RFC 8252 §7.3 — the port may vary, as desktop clients
require, but the rest of the URI must match.

## Tokens

Access tokens are **AES-256-GCM encrypted envelopes**, not bare backend
credentials. An envelope is bound to its audience and is rejected if it is
tampered with, replayed against the wrong resource, or presented after the
backend token it wraps has expired. A refresh envelope cannot be used where an
access envelope is required.

Your Hi-Doctor password is exchanged for a token at sign-in and is never
stored by the connector, never written to a log, and never passed to the
connecting application.

## Permissions

Tools are grouped, and each group requires its own scope — profile,
consultations, messages, questionnaires, progress, payment. A tool whose scope
you did not grant is not merely refused, it is **not offered**: it never appears
in the client's tool list.

Roles do not stack. An account gets exactly one tool catalogue, so a patient
token can never reach a clinician or back-office tool. See
[Permissions](/mcp/permissions) for the full grant list.

## What the server refuses to leak

* **Backend `5xx` bodies are discarded entirely.** An upstream error returns a
  stable, generic failure rather than an internal trace.
* **`4xx` responses are filtered to an allowlist** of structured fields, so an
  error can be actionable without echoing patient data back through the tool
  result.
* Path arguments cannot escape the configured API host or its version prefix.
* Rate limiting is keyed on the token, not on a header that a caller could
  reshape to get a fresh bucket.

## Payment

The connector never handles card details. `hidoctor_checkout_create` returns a
link to Stripe's own hosted checkout, and card, plan and billing-address
changes happen in the Stripe billing portal. There is no tool that accepts a
card number, and any assistant asking you for one is not talking to Hi-Doctor.

## Clinical limits

No token, of any kind, can approve a consultation, issue or alter a
prescription, or change a dose. Those actions are not exposed by the MCP
server at all — not gated behind a scope, simply absent.

Medical eligibility is enforced by the Hi-Doctor backend when a questionnaire
is submitted. An assistant cannot pre-approve a patient, and re-submitting with
different answers does not bypass the check.

## Reporting a problem

Email [hello@hi-doctor.ai](mailto:hello@hi-doctor.ai) with the details. If you
believe patient data is exposed, say so in the subject line so it is triaged
first.