Building a Privacy-First Medical Imaging AI Agent with Claude and MCP

Building a Privacy-First Medical Imaging AI Agent with Claude and MCP

The most sensitive part of medical imaging AI is handing raw data containing patient identity information to a model. A local de-identification engine called Aegis, combined with Claude's MCP (Model Context Protocol) tool-calling capabilities, offers an architectural approach worth learning from: the model handles only orchestration, while image pixels and PHI (Protected Health Information) stay within the local trust boundary.

The core promise of this approach can be summed up in one sentence — the model coordinates the workflow, and sensitive medical data does not cross the boundary. It is not just a technical demonstration, but a reusable privacy-first agent design paradigm.

Why Privacy Boundaries Matter More Than Features

A traditional multimodal assistant that needs to inspect or transform an image typically must first read the image into context. This means the image and any PHI it may contain pass through the model layer, creating an unnecessary leakage path.

Yet mature local processing pipelines already have the capability to handle these files. The value of MCP is that it allows us to expose actions (triggering de-identification, querying status, listing the review queue) and structured summaries to the model, rather than handing over raw content.

The difference is fundamental: the former is "granting access to patient data," while the latter is "granting access to a small set of approved, limited capabilities." This does reduce the exposure surface, but it does not mean the system is automatically compliant, secure, or clinically validated. Filenames, directory paths, counts, error messages, and tool return values still enter the conversation and must be treated as data.

The first step in a privacy-first architecture is minimizing what crosses the boundary; the second is verifying that the boundary actually holds.

PHI (Protected Health Information) is a core legal concept under the U.S. HIPAA Privacy Rule, referring to data that can be linked to a specific individual's health status, healthcare services, or payment information, and that can identify that individual. It includes not only diagnoses, prescriptions, and visit records, but also names, birth dates, ID numbers, device serial numbers, burned-in text in images, and even file paths and date stamps that can indirectly point to an individual. The key to determining whether data constitutes PHI lies in "identifiability" — if the same information, after removing direct identifiers, can still be re-associated with an individual through combination, it may still be considered PHI. This is precisely why the article repeatedly emphasizes treating filenames, directory paths, counts, and error messages as data: their sensitivity does not depend on the field name, but on whether they form an identification path.

What Aegis Does Locally

Aegis is the local processing engine in this approach. MCP does not improve its PHI detection accuracy, nor does it replace its review logic.

For DICOM files, Aegis cleans identifiable metadata and inspects pixels for "burned-in text" that metadata rules cannot remove. OCR detects candidate text regions, NER helps classify sensitive entities, and policy rules determine what needs to be redacted, whitelisted, or escalated for manual review.

The outputs include: transformed files, pixel detection records, tag operation records, and a manual review queue for uncertain cases.

This separation of responsibilities is critical: the de-identification engine handles medical image processing, while the agent handles workflow orchestration. During development, synthetic samples should be used rather than real patient data, and both successful and uncertain results should be examined. An agent is only truly trustworthy when its summaries can be traced back to the pipeline's own audit evidence.

DICOM (Digital Imaging and Communications in Medicine) is a universal file and communication standard in the medical imaging field. A CT or MRI image contains not only a pixel matrix but also a large number of metadata tags (patient name, study ID, device parameters, institutional information, etc.). So-called "burned-in text" refers to characters such as patient names, exam times, and position annotations that ultrasound, X-ray, or fluoroscopy equipment render directly into the pixels during imaging, rather than placing them in metadata tags. This type of text cannot be removed by deleting tags; it must rely on OCR to locate it at the pixel level, then decide whether to redact or escalate for review. Additionally, OCR (Optical Character Recognition) is responsible for transcribing candidate text in pixels into strings, and NER (Named Entity Recognition) is responsible for determining whether these strings belong to categories such as person names, dates, or device numbers — the division of labor between the two determines the direction of subsequent policy rules.

Architecture First: Who Manages What

Before writing code, the architecture must be clarified. Claude Desktop is the MCP Host, the FastMCP process is the Server, and six Python functions are Tools that Claude can discover and request.

The Host launches the Server as a local subprocess and exchanges JSON-RPC messages via standard input/output. The Server calls Aegis on the same machine; image files, models, output directories, and the review queue all remain local. Only PHI-minimized results — task status, counts, filenames, paths, decision categories — are returned through MCP.

The user sits at the control point, approves tool calls, and compares the assistant's reports against audit files. This local human-in-the-loop model requires directory restrictions and clean logging to be viable.

This architecture is useful because each component bears only one responsibility, and the sensitive data boundary is visually testable.

MCP (Model Context Protocol) is an open protocol that enables model hosts to communicate with external tool services. It uses a client-server structure: the Host (such as Claude Desktop) initiates conversations and manages user authorization, while the Server exposes discoverable Tools; the two interact via JSON-RPC messages. When the Server runs as a local subprocess, it typically uses stdio transport — standard input/output becomes the protocol channel. This also explains why logs must go to standard error (stderr) rather than standard output (stdout): any extra print statement will pollute the JSON-RPC data stream. FastMCP is a Python implementation framework based on MCP, used to quickly register ordinary Python functions as model-callable tools, automatically generating tool descriptions and parameter schemas.

Drawing the Trust Boundary: What Crosses, What Doesn't

The safest design starts with a checklist — what is allowed to flow from Aegis to Claude, and what must stay local.

Allowed outputs: aggregate counts, task IDs, sanitized filenames, status transitions, review flags.

Prohibited outputs: image bytes, pixel crops, OCR text, DICOM tag values, raw exception payloads, re-identification keys.

Even the allowed fields require careful scrutiny — patient names embedded in filenames or directory paths remain sensitive. Therefore, the schema returned by a tool is itself a security control, not merely a convenient response format.

A "negative test" is recommended: directly ask the agent to provide a detected patient name and confirm that no tool can satisfy this request. The boundary truly exists only when both normal returns and failure paths refuse to disclose prohibited content.

Designing Six Narrow Tool Surfaces

The Server exposes six tools: warm-up (preload models), deidentify_file (single-file de-identification), start_batch_job (batch job launch), get_job_status (job status), summarize_run (run summary), list_review_queue (review queue).

Each tool answers only one user intent and returns constrained results that are easy to inspect and test. Long-running work is split into start and status tools; audit-type queries read existing records rather than reopening images.

Warm-up controls model loading latency before real de-identification requests; the review queue tool returns only filenames and counts, helping allocate work without disclosing file contents.

A small tool surface is easier to authorize, document, test, and monitor than a single generic "do anything" function. Design tools around security-oriented user decisions, not around every internal function in the Python package.

Replacing Sensitive Details with Structured Summaries

The single-file tool accepts a local input path and an optional output directory, delegating the transformation to Aegis. It returns success status, source filename, output location, detection counts, decision counts, cleaned tag counts, and review status.

It deliberately excludes: image data, OCR-extracted strings, pixel crops, raw DICOM values.

Flags requiring manual review turn uncertain detections into explicit next actions. Exceptions must also be sanitized before returning, because library errors may inadvertently carry paths or sensitive values.

Validate tools with synthetic images and compare reported counts against generated audit rows. A tool is only "secure by design" when useful summaries are sufficient and sensitive details are structurally inaccessible.

Protecting the JSON-RPC Channel and Logs

A local stdio MCP Server reserves standard output for JSON-RPC messages. A single casual print statement can disrupt the protocol stream, making a healthy Server appear disconnected or malformed.

Application logs should go to standard error via Python logging, remaining visible without becoming protocol data. Logs also require PHI minimization — switching streams does not make sensitive content safe.

Log event names, task IDs, sanitized filenames, counts, durations, and error categories — not raw medical values. Test the Server under failure scenarios to confirm that both responses and logs hold the line.

Batch Processing in the Background, the Model in the Conversation

A directory may contain hundreds or thousands of images; a single blocking MCP call is the wrong interaction pattern.

start_batch_job creates a short task ID, initializes a progress record, launches a worker, and returns immediately. The Host can continue the conversation while the local process updates processed, total, and error counts. get_job_status reads this record without touching source images or waiting for the batch to complete.

An in-memory registry works across turns while the Server process is alive, but active task IDs disappear after a restart. Processed files and audit reports remain on disk, and a persistent implementation can rebuild state from durable task records.

When work takes longer than one comfortable interaction, separate start from status.

Warming Up Heavy Models

OCR and NER model loading times can be long enough to make the first real tool call appear to time out. A lazy pipeline factory builds the model stack only when needed and caches it for subsequent calls.

The warm_up tool makes this cost explicit, observable, and easy to approve. After warming up, it returns only a simple ready status — not model weights, sample text, or internal data. The same Server process must serve subsequent requests for the cache to be meaningful.

Measure cold start and warm start separately so users understand whether they are waiting for initialization or file processing. Warm-up turns an unpredictable first-call latency into a controllable step in the workflow.

Read Audit Records, Not Images

summarize_run reads the pixel detection and tag operation CSVs that Aegis has already generated, aggregating into decision categories such as "redacted," "whitelisted," and "low confidence" without returning the detected strings.

list_review_queue identifies files requiring manual attention without opening or displaying their contents. These tools let Claude answer operational questions after processing is complete while keeping raw images outside the context.

Limit response sizes and sanitize filenames to prevent a large or poorly named queue from becoming a new leak channel. Treat audit files as the single source of truth; conversation summaries are merely views derived from them.

A privacy-first agent reasons about evidence concerning the workflow, not about sensitive media itself.

Test with MCP Inspector First

Before any language model is involved, connect to the local Server directly with MCP Inspector and walk through each tool one by one.

Launch Inspector with the aegis-mcp executable, connect to the stdio server, and confirm that all six tools are discoverable. Run warmup, then call deidentify_file on a synthetic test image and inspect the structured JSON result. Use the messages view to see requests and responses, and check stderr logs in the terminal.

Inspector testing isolates Server bugs from the model's tool-selection behavior and Claude Desktop configuration errors. Do not connect an AI host until manual tool calls, error cases, and privacy negative tests perform exactly as expected.

Securely Connecting Claude Desktop

Claude Desktop requires an MCP server entry pointing to the aegis-mcp executable in the virtual environment. Use absolute paths and pass arguments specifying the output directory and review directory, because the Host may launch from an unexpected working directory.

Choose the device deliberately: mps for supported Apple Silicon, cuda for compatible NVIDIA, cpu as a portable fallback. Output and review locations should stay within approved project directories rather than granting arbitrary filesystem access.

After saving valid JSON, fully quit and restart Claude Desktop to launch the new local subprocess. Confirm that all six tools appear before approving any calls. A successful connection only proves that discovery and transport work — not that privacy controls or de-identification quality are sufficient.

Talking to the Agent as a Workflow

First ask Claude to warm up the Server, approve the tool call, and confirm the ready response. Request de-identification for a single synthetic file and inspect the returned counts, output location, and review flags.

For a folder, start a batch job and keep the returned task ID rather than waiting through a long interaction. Follow-up questions like "how is that job progressing" should trigger get_job_status with the same identifier. When complete, request the run summary and review queue, then draft a meeting-ready report based on these structured results.

The assistant can narrate and organize evidence, but it should never claim to have visually inspected images. Good agent behavior is a chain of transparent, approved tool calls, observable results, and bounded claims.

Verify Every Claim the Agent Makes

Compare the assistant's totals against the pixel detection CSV, tag operation CSV, and task summary JSON generated by the pipeline. Processed file counts, decision categories, errors, and the review queue should be consistent between tool responses and disk records.

If there is a discrepancy, stop downstream use and create an investigation item rather than "explaining it away" in natural language. Record tool versions, configurations, model versions, timestamps, and reviewer decisions to support reproducibility.

Files and audit records are the source of truth; the agent's answers are convenient and verifiable interpretations.

What Claude Can Still See

Tools can prevent pixels, OCR text, and DICOM values from being returned, but conversation metadata still reaches the model. Patient names may cross the boundary through filenames, folder names, prompts, exceptions, or logs, even if the images themselves do not.

Use synthetic identifiers during development and rename inputs according to approved policies before agent interaction. Return error codes and sanitized categories rather than raw stack traces or library exceptions. Minimize paths, truncate lists, and prefer opaque task IDs when users do not need full filesystem details.

Test a request that directly asks for a patient name and verify that available tools cannot answer it. "The model never saw the image" is correct but incomplete — privacy review must cover every field that reaches the local process.

Hardening the Local Tool Boundary

Resolve paths and enforce that every request's inputs and outputs stay within explicitly whitelisted root directories. Reject path traversal, symlink escapes, unsupported extensions, oversized batches, and unexpected output locations before the model begins processing.

Keep approval prompts for mutating tools, apply least privilege to the Server process, and separate input, output, and review directories. Pin package and model versions, verify downloads, and record configuration hashes so results are reproducible. Limit tool responses, sanitize errors, send logs to stderr, and never place secrets or PHI in environment variable values.

Add unit tests for each guardrail and use synthetic DICOM and image fixtures for integration tests. Security comes from layering: narrow tools, restricted paths, clean outputs, explicit approvals, auditable evidence, and human review.

De-identification Is a Regulated Claim

This project demonstrates an agent interface for a de-identification pipeline; it does not prove that a dataset has been lawfully de-identified under the HIPAA Privacy Rule.

HHS describes two formal paths: Safe Harbor and Expert Determination. Technical cleaners must be evaluated against applicable identifiers, residual re-identification risk, organizational policy, and intended data use. Medical images may contain identifiers in metadata, burned-in annotations, filenames, surrounding records, and correlatable contextual information.

Uncertain cases must go to qualified human review, and real deployments require security, privacy, legal, clinical, and data governance approval. Even after correct de-identification, data may retain a small but non-zero re-identification risk.

The accurate statement is: this tutorial builds controls and evidence for de-identification work, not a compliance guarantee.

The HIPAA Privacy Rule provides two formal paths for "de-identification." Safe Harbor requires the removal of 18 categories of specified identifiers, including names, dates (except year), geographic subdivisions, phone numbers, device identifiers, facial photographs, and any unique identifying codes — operationally mechanical but the coverage must be complete. Expert Determination allows evaluation by experts with statistical and scientific qualifications, requiring proof that the risk of identifying an individual is "very small," typically through quantitative analysis of residual re-identification risk. The applicability of the two paths depends on the data type, purpose, and recipient. Note that even after de-identification, data is still considered to carry non-zero re-identification risk, so medical AI deployments often layer on additional measures such as data governance, access control, and human review.

Where Else This Pattern Applies

The same MCP boundary can wrap controlled local pipelines such as legal document redaction, financial record masking, and confidential log processing. For scheduled overnight processing, a CLI remains simpler; MCP is most valuable in interactive human-in-the-loop and review scenarios.

The next engineering directions are persistent task storage, stricter directory policies, automated privacy negative tests, and independent verification. A fully local model host can reduce external conversation exposure but cannot eliminate the need for access control, auditing, and verification.

The larger the system, the more the core rule must remain unchanged: expose actions and evidence, not sensitive payloads. This is the reusable privacy-first agent paradigm — local processing, narrow tools, explicit review, verifiable claims.

One-line Summary

A privacy-first agent architecture using Aegis as the local engine with narrow MCP tools, letting the model orchestrate workflow without touching PHI.

Paragraph Summary

The article starts from the privacy risks of medical imaging AI and proposes a reusable privacy-first agent architecture: Aegis serves as a local de-identification engine handling DICOM metadata and burned-in text, while Claude calls only six narrow tools through MCP (warm-up, single-file de-identification, batch launch, status query, run summary, review queue), keeping image pixels and PHI within the local trust boundary. The approach emphasizes that the tool return schema itself is a security control, must exclude image bytes, OCR text, DICOM tag values, and exception payloads, and adopts start/status separation for batch processing and warm-up for heavy models. It also stresses boundary testability — offline verification with MCP Inspector, negative tests requesting patient names, comparing audit CSVs with conversation summaries — and reminds that de-identification is a regulated claim, not a compliance guarantee.