Read-only is a claim. Scope is the proof.
In a health-data agent setup there are two credentials people both call "the token", and they fail in different ways.
The pairing secret gates the server. Turn on Agent pairing in the app and set PAIRING_SECRET in the server config. Without a match, every data tool answers "Locked" rather than returning an empty result. That distinction is deliberate: an empty result reads as "no data today", while "Locked" tells you the credential is the problem.
The delivery token authenticates the export. Point the app at a webhook you run and the request carries your ingest token and, when you set one, an HMAC-SHA256 signature over the request id, timestamp and raw body. Each destination keeps a send history, so you can see what actually left the phone.
The part almost everyone gets wrong: pairing protects the server, not the files. Anyone who can open your export folder reads the JSON directly, with no token and no server. If that folder syncs to a shared drive, your token is decoration.
A read-only Apple Health token should reach one destination, one data folder, and a set of tools that can only read. It should return daily summaries, not individual raw samples, and be revocable in one step. It should never reach the write path back into Apple Health, workout GPS routes, medication records, a network, or anyone else's data.
The full scope test, including what to check and what to revoke, is here: https://www.healthexport.dev/blog/mcp-token-scoping-read-only-apple-health?utm_source=devto&utm_medium=social&utm_campaign=hea448-token-scoping
Top comments (0)