PHI-aware access, with the trail to prove it.
Let clinical and back-office staff use assistants against your product without widening who can see what.
What your customers are asking for
Your customers want the administrative time back (scheduling, prior authorisation, records lookup), and assistants are the obvious lever.
Their privacy officer's question comes immediately after: minimum necessary access, and a record of every disclosure.
Why a shared API key fails
A single key held by an assistant cannot express minimum necessary access. It grants whatever the service account has, to whoever is typing.
And because the log cannot attribute the access to a person, a disclosure review has nothing to work from.
One request, followed all the way through
- 01A scheduler asks: "What appointments does Dr. Okafor have free this week?"
- 02The assistant calls the scheduling tool carrying the scheduler's session.
- 03LockMCP verifies it, resolves the person, and checks their role against the tool.
- 04Provider and location parameters are narrowed to the ones that scheduler covers.
- 05The call runs with credentials injected server-side; fields outside the minimum necessary are redacted.
- 06The access is recorded against the scheduler, with what was asked and what came back.
What your customer gets
Minimum necessary by construction
Parameters are narrowed to the user's scope before the model sees the tool.
Disclosure records
Every access is attributed and retained, including refusals.
No new identity system
Staff sign in exactly as they do today.
Redacted responses
Sensitive fields are stripped before they reach the assistant.
What you get
A defensible story
Access control and audit are properties of the platform, not of each integration.
Minimum necessary enforced
Access is bounded by role and narrowed by parameter, not by policy documents.
One deployment, many customers
Tenant isolation is enforced in the database.
Spec-driven
Your OpenAPI spec is the source; endpoints are untouched.