Benchling AI Connectors to Public Databases

This document describes Benchling's PubMed and UniProt AI Connectors: what they're for, how a query travels from a Benchling AI agent to the public database and back, and what data (if any) Benchling retains along the way. It is intended to supplement the Benchling AI Security Whitepaper with details specific to these two integrations.

Purpose of these AI Connectors

Benchling's AI agents (eg Chat) can optionally consult public scientific reference databases while answering a question, so that responses can be grounded in current, citable, external data rather than relying only on the AI model's own training data.

Benchling hosts two AI Connectors to public databases today:

• PubMed: lets an AI agent search and retrieve biomedical literature, article metadata, and open-access full text from the National Center for Biotechnology Information (NCBI).

• UniProt: lets an AI agent search and retrieve protein sequence and functional annotation data from the UniProt Knowledgebase.

Both are built and hosted by Benchling as read-only integrations with each database's own public API. This makes them different from AI Connectors such as SharePoint, where Benchling connects to a customer-configured, vendor-hosted server using credentials the customer supplies (e.g., OAuth). PubMed and UniProt require no such customer configuration or credential, because NCBI's and UniProt's public search APIs are free and require no authentication.

How These AI Connectors Work

At a high level, a query follows this path:

1. A user asks a Benchling AI agent a question, with the PubMed and/or UniProt AI Connector available for that conversation.

2. The agent determines that a public literature or protein-database lookup would help answer the question, and generates a targeted query (a keyword, gene/protein name, accession number, or article ID) based on the conversation.

3. Benchling's platform sends that query to the AI Connector over an internal, authenticated connection. This internal authentication only proves the request came from Benchling's own systems, for security auditing purposes — it is separate from, and never shared with, NCBI or UniProt.

4. The AI Connector forwards the query — reformatted as needed to match the target API, but not otherwise modified — directly to NCBI's or UniProt's public REST API over an encrypted (HTTPS/TLS) connection. Only the search terms generated in step 2 are sent; Benchling does not attach any tenant data, account credentials, or user-identifying information to that outbound request.

5. NCBI or UniProt returns its response — the same public data available to any user of their public API — which the Public MCP server passes back largely as received, with no caching, storage, or additional processing along the way.

6. The AI agent uses that result to compose its answer, typically citing the source article, accession, or database entry.

Because Benchling builds and hosts both integrations, there is no third-party MCP vendor or intermediary anywhere in this flow, only Benchling's own systems and the public database's API.

Data Retention Policies

On Benchling's side: The AI Connector that relays these requests does not store, log, or cache the content of any request or response:

• No database record, file, or cache entry is created containing the search terms sent or the data returned.

• The only operational data captured is aggregate, content-free telemetry, such as response time and error/success counts, used to monitor the health of the integration. This telemetry never includes query text, returned data, or any tenant- or user-identifying information.

• For security auditing, Benchling logs which internal system authenticated to the AI Connector; this is separate internal record-keeping and is never forwarded to NCBI or UniProt.

• Once a request completes, the AI Connector retains no record that it occurred, there is nothing to expire or delete.

The one exception is the conversation itself: like any other AI agent response, the chat message where the agent used a PubMed or UniProt lookup (and the result it returned) is saved as part of that chat session, under Benchling's standard retention for AI chat sessions (the same policy that applies to all Chat conversations, as described in the Benchling AI Security Whitepaper). There is nothing additional for customers to manage because a PubMed or UniProt lookup occurred; the usual chat/session data controls apply.

On the third-party side: Because NCBI/PubMed and UniProt are free, public, unauthenticated APIs, Benchling does not send any tenant- or user-identifying information to them, only the search terms described above. Benchling does not control, and cannot make representations about, what these organizations may log on their own infrastructure (for example, standard web server access logs). For that detail, customers should refer to each organization's own published policies:

• NCBI / National Library of Medicine (PubMed): NCBI Policies and Disclaimers and the NLM Privacy and Security Policy. NCBI states that it does not collect personally identifiable information from visitors to its public sites and APIs.

• UniProt: UniProt Privacy Policy.

This is a materially different model from connectors like SharePoint, where a customer's own vendor tenant and credentials are involved. For SharePoint, the vendor's (Microsoft's) retention policy applies to each query sent to its MCP server, and customers should refer to Microsoft's own privacy documentation for that detail. No equivalent customer-specific vendor relationship exists for PubMed or UniProt — there is no customer account, tenant, or credential on the NCBI or UniProt side at all.

Tools in Each MCP Server

PubMed

UniProt

All requests use the same public, unauthenticated endpoints available to any user of NCBI's or UniProt's own website or API. Benchling's AI agents do not have access to any private, restricted, or account-specific data on either platform as no such thing exists for these free, public resources.