Model Context Protocol Security
A practical guide to trust boundaries, tool poisoning, and runtime controls for MCP-connected agents in enterprise and healthcare environments.
Model Context Protocol security centers on the trust boundaries between hosts, clients, models, and MCP servers that expose tools, resources, and prompts. Material risk comes from tool poisoning, hostile tool results, over-privileged servers, and weak identity or approval controls at invocation time. In healthcare, those same paths can expose PHI, alter clinical side effects, or subvert regulated workflows unless least-privilege tools, runtime policy enforcement, isolation, and audit logging are applied before production use.
MCP security focus areas
Four concerns dominate secure MCP design for production agents.
- ArchitectureHost–client–server trust domains and server-supplied metadata
- Tool poisoningHostile descriptions, schemas, and results steering agent behavior
- Runtime controlsIdentity, scoped permissions, policy checks, and human approval
- Healthcare impactPHI exposure, workflow disruption, and unsafe clinical side effects
Why MCP security matters for enterprise agents
The Model Context Protocol connects language-model agents to external tools and context through a host–client–server architecture. Dual-purpose hosts run clients that attach to MCP servers, which expose tools, resources, and prompts the model can use. Security exposure is driven less by transport alone and more by semantic trust: models reason over natural-language tool descriptions, arguments, and returned content, then act.
For security engineers, the critical surfaces are server-supplied metadata, runtime tool invocation, and context that enters the model. Specification guidance treats tool invocation and data access as sensitive operations that should require explicit user consent and clear limits on what a server can see and do. When healthcare agents bind tools to EHR, scheduling, messaging, or clinical decision systems, over-broad or unmonitored access expands impact to PHI disclosure, improper workflow changes, and unsafe side effects. HIPAA Security Rule expectations for access control, audit controls, integrity, and transmission security apply wherever electronic PHI is reachable through the agent and its tool layer.
MCP tool poisoning and related runtime abuse
Tool poisoning is the pattern in which malicious or untrusted tool descriptions and metadata steer model reasoning so the agent calls tools or crafts arguments in ways the user did not intend. Security analyses of MCP deployments show that tool schemas, annotations, and returned tool content can function as indirect prompt-injection channels that influence later steps in an agent loop.
Related conditions widen the attack path:
- Untrusted tool output that re-enters model context without filtering, approval gates, or provenance checks can alter subsequent behavior even when the original description was benign.
- Over-privileged servers increase the value of any successful influence on invocation.
- Unauthorized or chained tool use compounds impact when one poisoned step unlocks broader data access or side effects.
Defenses therefore cannot rely only on model-layer guardrails; they must treat metadata and results as untrusted content and constrain what execution path remains available after influence occurs.
Healthcare-specific implications and control design
Healthcare MCP deployments raise severity because tools may read or write clinical systems, patient communications, or billing and identity data linked to PHI. Architectural choices should separate MCP hosts and clients from high-privilege clinical systems and place servers behind API gateways. Prefer purpose-specific clinical tools over administrative interfaces that can exfiltrate or alter large PHI sets.
Operationally, inventory every MCP server, tool, resource, and prompt with the data classes touched and side-effect potential. Map connected data flows to HIPAA pathways: access control, minimum necessary, audit controls, and business associate obligations for third-party servers. Establish change control for tool schemas and server versions, because schema changes are security-relevant instructions visible to the model. Define who may enable servers in production, and require internal or vendor attestations covering isolation, logging, vulnerability management, and PHI handling before tools attach to care workflows.
Trussed AI focuses on runtime governance for enterprise AI agents, including policy enforcement, agent identity and permissions, tool approval workflows, monitoring, and audit logging that support these control patterns without replacing clinical system IAM or HIPAA program ownership.
Architectural trust boundaries and exposure
Secure MCP design starts by treating each hop as a distinct trust domain with explicit limits on what can cross it.
-
User to host and client
Human intent, consent, and session context must not be silently broadened by connected servers or automatic tool discovery.
-
Host and client to model
Tool schemas, annotations, prompts, and prior results become model-visible instructions that shape planned actions.
-
Client to MCP server
Each server is a distinct trust domain. Servers often inherit runtime privileges, so compromise can enable local data access, credential use, or unintended side effects.
-
Server to enterprise systems
Downstream APIs, clinical stores, and identity services determine blast radius if tools are broad, long-lived credentials are shared, or isolation is weak.
-
Cross-server brokering
Unmediated chaining across servers multiplies injection and over-privilege paths; mediate or minimize cross-server tool use.
Evaluation checklist for production MCP agents
Use this checklist before exposing MCP tools to clinical or other regulated workflows.
- Production servers and tools are inventoried with PHI reach and clinical side-effect potential documented
- Tool descriptions and results are sanitized or gated so they cannot act as unrestricted injection channels
- Caller and server identity, scoped permissions, and human approval run before high-risk invocations
- Server runtimes are isolated, updated, and monitored for abuse or configuration drift
- HIPAA-relevant audit trails of tool calls exist with redaction and retention aligned to policy
- Schema and server changes follow security change control before clinical workflow exposure
Runtime governance controls that reduce abuse paths
These controls constrain what an influenced or compromised agent path can still accomplish at invocation time.
Least-privilege tools and credentials
Design narrow, purpose-specific tools. Issue scoped tokens per server or tool and avoid long-lived shared secrets whenever short-lived credentials are feasible.
Pre-execution policy checks
Mediate calls with an authorization layer that can allow, deny, or require human approval based on tool risk, caller identity, and data classification.
Consent and high-risk approval gates
Require interactive approval for risky operations such as outbound messaging, record mutation, export, or identity merge before the tool runs.
Metadata and result integrity
Inventory schemas; strip or sanitize embedded instructions; normalize descriptions before they enter model context; treat tool results as untrusted input.
Server runtime isolation
Run servers in containers or sandboxes with dedicated identities behind gateways that enforce identity, scope, and rate limits so compromise is not full EHR or enterprise breakout.
Comprehensive tool-call audit
Log tool name, redacted arguments, identity, policy decision, and result status for SIEM and healthcare retention requirements.
Strengthen runtime controls for MCP-connected agents
Review identity, permissioning, approval, and audit patterns against your healthcare tool inventory before expanding agent access to clinical systems.
Explore Runtime Governance