MCP is useful, but what it does is connect—and connecting means more paths along which information moves.
In an ordinary business system that is simply convenience. Where medical information is involved, permissions, records, and exits need redesigning. See What Is MCP? and Using MCP with an EMR for the groundwork.
Disclaimer: General information, not legal advice. Guidelines are revised. Base operational decisions on the current text and expert review.
Why MCP Becomes a Security Question
Treating MCP as a technical-department matter leaves gaps, for a simple reason: MCP defines the boundary of what AI can do.
Historically, "who may see what" lived in system user permissions. Now a new actor joins. AI acts on staff instruction, but AI is what touches the data. Under whose permissions?
An architecture that cannot answer that clearly has a broken permission model.
Mapping to the Three-Ministry Guidelines
| Guideline concern | What MCP newly raises |
|---|---|
| Access control | Whose permissions does the AI act under? Can it exceed staff rights? |
| Access logs and audit | Are AI references and actions recorded? Distinguishable from human actions? |
| Outsourcing / third-party disclosure | Is the off-site AI service a subcontractor? What data leaves? How is training use handled? |
| Integrity | Can AI-written content be distinguished from human-written content? |
| Availability | Does care continue if the integration stops? |
| Division of responsibility | In an incident, who bears what? |
Integrity is easily overlooked. For a given chart entry, can you later tell whether it was an AI draft a human reviewed, or written by a human from the start? That bears on the evidentiary standing of the record.
See Security Design and Shared Responsibility in an AI EMR and Implementing the Three-Ministry Guidelines.
Three Principles of Permission Design
① AI never exceeds a human's rights.
The most important one. AI acting on a receptionist's instruction must not read clinical content that receptionist cannot see on screen—that is privilege escalation via AI. "Let the AI see everything, it's more useful" is abdication of access control.
② Split counters finely; open only what is needed.
Under MCP, least privilege shows up at tool granularity. "Get recent labs" and "get allergies" beat one coarse "fetch chart data." See What Is an MCP Server?.
③ Separate reads from writes.
Read-only, the worst case is a wrong display. With writes, it becomes a wrong record. Different blast radius means different settings. Where writes are allowed, stop at drafts and let humans commit—see Where to Draw the Line on Delegating Work to AI.
Failure Patterns to Avoid
① Running AI under a shared account. One "AI admin" account used by all staff. Instructions become untraceable and permissions go wide open. The worst pattern.
② Opening all charts and promising to narrow it later. Narrowing later rarely happens. Opening is easy; closing is hard.
③ Allowing writes without confirmation. Noticing an error after it is in the record is not recoverable in a medical chart.
④ Deferring audit logs. Features first, logs later. Without logs, an incident is unknowable forever. Logs are needed from day one.
⑤ Connecting to external AI without mapping the exits. If you cannot draw which data goes where by what route, do not go live.
A Healthcare-Specific Risk—"Indirect Instructions"
When AI reads external data, strings inside that data can be interpreted as instructions to the AI—prompt injection.
In a clinical setting the path might be:
- An externally received document (a referral PDF, a patient's free-text questionnaire entry) contains instruction-like text
- The AI treats it as something to obey rather than data to read
- It calls an unintended counter or emits inappropriate output
The defense is straightforward:
- Keep the set of callable counters narrow. What cannot be called cannot be abused
- Require human confirmation for high-impact actions
- Confirm with the vendor that externally sourced data is handled as data, not instructions
The first defense does the most work. Permission design is itself the strongest mitigation for this class of risk.
See also Digitizing the Web Questionnaire and What Is an AI Questionnaire?.
What Belongs in the Audit Log
| Item | Why |
|---|---|
| Timestamp | Reconstructing the sequence |
| Instructing staff member (per person) | Identifying whose permissions applied |
| Counter invoked (tool name) | Identifying what was attempted |
| Target data (patient ID, scope) | Identifying what was touched |
| Read or write | Judging blast radius |
| Outcome (success / failure / denied) | Confirming denials actually fired |
| Human approval present? | Locating responsibility for committed actions |
"AI was used" is not enough. Only "under whose permissions, through which counter, against which data" makes an incident analyzable.
Triage When Something Goes Wrong
"The AI displayed wrong information." → Logs of which counter and which data. Separates bad data from bad interpretation.
"Information appeared that should not have." → The permissions the AI ran under, and per-counter access settings. Tests whether Principle ① held.
"Wrong content was recorded in the chart." → Approval records: was there an approval step, when, by whom?
"Information may have left the premises." → The external connection map and transmission logs. Without a map drawn in peacetime, you cannot check in an incident.
Vendor Checklist
Permissions
- Can the AI ever exceed the logged-in user's rights? (Confirm it cannot)
- Can we change the AI's referenceable data scope ourselves?
- Is read-only operation possible?
Writes 4. Can AI writes be limited to drafts? 5. Can human approval be mandatory before commit? 6. Are AI-generated and human-entered contents distinguishable in the record?
Logs 7. Do audit logs carry timestamp, staff member, counter, target data, and outcome? 8. What is the retention period and export method?
Exits 9. What items leave the premises, by what route? 10. Is our input contractually excluded from training? 11. Who provides the AI service, including any downstream subcontractors?
Availability and responsibility 12. If the integration stops, does clinical work on the EMR continue? 13. How is the division of responsibility framed for the Three-Ministry Guidelines?
Bolted-On vs. Unified Changes the Difficulty
Bolting external AI onto an existing EMR means managing permissions twice—on the EMR and on the AI. Keeping them consistent is ongoing operational load, and every divergence is a gap.
AI and EMR on one foundation means one permission scheme, audit logs in one place, and minimal outbound paths. See What Is an AI-Native EMR?.
Neither is categorically right; what differs is how many items you must verify, and how much ongoing effort it takes to keep them true.
Conclusion
- MCP adds paths along which information moves; treating it as purely technical leaves permission gaps
- Against the Three-Ministry Guidelines it newly raises permissions, logs, outsourcing, integrity, availability, and responsibility
- Three principles: ① AI never exceeds human rights ② split counters finely ③ separate reads from writes
- Avoid shared accounts, wide-open scope, unconfirmed writes, deferred logs, and unmapped exits
- The strongest mitigation for externally sourced data being read as instructions is keeping callable counters narrow
- Audit logs need whose permissions, which counter, which data—not just "AI was used"
- Bolt-on architectures manage permissions twice; unified ones need only one scheme
To discuss security design for AI Karte, please contact us.