Skip to main content

MedScout MCP: Security

M
Written by MedScout Support

1. Authentication & Access Control

  • Connector installation is admin-only. A Claude Owner or Primary Owner adds MedScout as a custom connector via Organization Settings → Connectors, pointing to https://mcp.medscout.io/mcp.

    • Individual users will not need to install the MCP connection once its enabled by their admin, but they will need to authenticate their connection.

  • Each user authenticates individually with their own MedScout credentials, no shared or service-account login.

  • Tool-level permissions. Each tool can be set to Always Allow, Needs Approval, or Blocked by the org admin.

  • Is the MCP token scoped separately from other MedScout API access?

    • The authorization token is scoped specifically to MCP access, and permission scoped to a specific user. It is not used for any other authorization scoping.

  • Domain/client allowlisting.

    • None at the MCP layer. Dynamic Client Registration is enabled per the MCP spec — any client may register, and there is no allowlist of client IDs or redirect-URI domains (redirect URIs are validated against what the client registered, but registration itself is open). All third-party clients share one Auth0 application and are deliberately not distinguishable from each other

  • Are newly exposed tools disabled by default?

    • New tools will require permission from the user the first time they are run by the MCP.

  • Can individual users revoke their own authorization, independent of the admin?

    • Yes. A user can disconnect the connector from their MCP client (Claude's connector settings)

  • SSO interaction. Does the MCP connector honor the customer's existing SSO setup automatically, or is it a separate credential?

    • It is the same credential they use for logging into the MedScout app, but they need to re-authorize the MCP connector flow specifically.

  • Session/token expiration and revocation mechanics.

    • Tokens follow standard OAUTH credential flow for re-authorizations. Revocation occurs via user directly disconnecting the MCP connector from their Claude instance.


2. Data Scope & Handling

  • Access inherits existing permissions. The MCP only ever surfaces data the authenticated user already has permission to see in MedScout. It does not expand access.

  • Read vs. write, precisely. The customer-facing server can create and save objects within a user's own workspace (lists, routes, code sets, filter sets), MCP server has limited access to update configuration information, like code sets.

  • Are prompts or queries logged, and for how long?

    • Prompts from Claude via the MCP connector are not logged by MedScout. Prompts to Scout AI inside the MedScout app are logged for 15 days.

  • Is customer data used to train models, either MedScout's own or Anthropic's underlying model?

    • No MedScout does not create or train models based on MCP usage, nor does it forward data to Anthropic to be used for their own training.

  • Data classification - is claims/provider data treated as PHI, de-identified data, or something else? All data is de-identified in MedScout, and will remain that way through the MCP connection.


3. Prompt Injection & Agent-Specific Risk

  • Are tool descriptions and tool results sanitized before reaching the model?

    • Tool results do not carry PII or sensitive information that is not already visible in the MedScout app.

  • Is there schema validation on tool inputs, so a malformed or adversarial input can't trigger unintended behavior?

    • Yes all inputs are validated on the API as well as additional safeguards in the MCP server.

  • Documented guidance for customers on what to do if MedScout's MCP returns something that looks like it's trying to instruct the AI rather than inform it.


4. Infrastructure

  • Public HTTPS with valid TLS. MedScout's connector endpoint (https://mcp.medscout.io/mcp) already satisfies this.

  • Hosting location/region(s).

    • AWS US-East1

  • Is the MCP server a thin layer over existing MedScout APIs, or separate infrastructure with its own attack surface?

    • MCP server calls into existing MedScout APIs with appropriate firewalls and permissioning

  • Subprocessors. Anthropic is inherently part of the data flow as the model provider whenever a user interacts through Claude.

    • Correct


5. Audit & Monitoring

  • Per-tool-call audit logging

    • Yes every tool call is audit logged.

  • Admin-level visibility into usage — can an org admin see which tools their team is using and how often, separate from any individual's own activity?

    • Not currently visible to customers, logging is internal to MedScout administrators only.


6. Vulnerability Management

  • Penetration testing cadence, and whether the MCP endpoint specifically is in scope (distinct from the core platform).

    • MedScout is pursuing SOC II Type 2 compliance and will penetration test yearly.

  • Responsible disclosure process / bug bounty.

  • Patch and update cadence.

    • Patches for critical and high severity issues will be issued within 1 week of remediation.


7. Incident Response

  • Breach notification timelines and process.

  • Escalation contacts (already documented in the admin setup guide, reusable here):

If the issue is...

Contact

Domain, identity provider, or SSO setup

Customer's IT administrator

Claude account access, connector visibility, or permissions

Claude Owner, then Anthropic Support

MedScout data, tool behavior, or connector setup

MedScout CSM


8. Compliance & Certifications

Any certifications should be listed here.

Pursuing SOC II, Type 2 this year

Did this answer your question?