🔒 MCP Connector Security Questionnaire for IT
🔒 What this article covers
This article helps IT and security teams review the Search Atlas MCP connector before it is enabled in a company Claude
workspace. It explains what can be confirmed from product documentation and what must be answered in a current written
security response. Compliance letters, token settings, and subprocessors change over time, so this article does not
replace an official questionnaire reply.
The connector endpoint to allowlist is https://mcp.searchatlas.com/mcp/. Do not enable any other host or path unless
Search Atlas has confirmed it in writing for your account.
📋 Connector status and legacy endpoints
The supported connector is the URL above. Treat any older MCP host, alternate path, or undocumented callback as legacy
until Search Atlas confirms it is still in service. Legacy endpoints should not be added to allowlists, SSO apps, or
firewall rules.
- Allow outbound HTTPS only to the documented connector host.
- Do not cache or hard-code tool schemas; the live connector advertises the current tool list.
- If a previously used URL no longer resolves, retire it. Do not keep it as a fallback.
- Ask for written confirmation of connector status and any retired hosts when you submit your questionnaire.
🛡️ Attestations and security reviews
Requests for SOC 2, ISO, or similar attestation must be answered from the current report or letter, not from a
knowledge-base summary. Search Atlas does not publish report dates, auditor names, or control mappings in this article
because those details expire.
When you open a questionnaire, list the frameworks you need, whether you need a bridge letter, and the deadline. The
team will share the materials your agreement allows. Do not assume a certification is in place until you receive that
written confirmation.
🔑 Access, OAuth scopes, and token lifetime
The connector acts for the signed-in Search Atlas user. It does not grant your Claude workspace a separate admin
identity. Available actions follow that user's role and project permissions.
- Read-only: You can limit use to viewing tools by giving the connecting user a role that cannot create, edit,
publish, or spend credits, and by approving only read-style tools in Claude. A fully read-only tenant setting, if
offered for your plan, is confirmed per account.
- Scopes: OAuth or token scopes are those shown on the consent screen and in your current security packet. Do not
infer scopes from tool names.
- Token lifetime: Access and refresh lifetimes are set by Search Atlas and may differ by plan or client. Request the
current values in your questionnaire rather than using a guessed expiry.
- Revocation: Removing the user, changing their role, or disconnecting the connector stops new tool calls. Existing
vendor sessions should be treated as revoked only after you receive confirmation or the token expiry you were given.
📣 How tool changes are communicated
Tools can be added, renamed, or removed as the product changes. The connector's live tool list is the source of truth
for what Claude can call. Material security-relevant changes, such as new data access or new billable actions, are
covered in release notes and, when required by your agreement, direct customer notice.
IT should periodically export or review the enabled tool list in the Claude workspace and compare it with the Search
Atlas permissions of the connecting user. Disable tools your policy does not allow instead of relying on a static
questionnaire.
📜 Audit logging
Tool activity should be traceable to the Search Atlas user who authorized the connector. Logs are intended to support
security review and typically include the acting user, time, tool name, and success or failure. They are not a full copy
of every page or keyword dataset the tool returned.
Retention, export format, and whether logs can be sent to your SIEM are account-specific. Include those requirements in
the questionnaire so the reply matches your workspace.
🗄️ Data handling, DPA, and subprocessors
Prompts and tool arguments sent through the connector are processed to perform the requested Search Atlas action and to
secure and debug the service, as described in your subscription terms and data processing agreement. Customer content
remains subject to that DPA, not to this article.
- Ask for the current DPA, subprocessor list, region notes, and retention summary if your review requires them.
- Do not paste secrets, customer lists, or unpublished financials into a tool call unless your policy allows that
processing.
- Search Atlas employees access customer data only as permitted by the agreement and internal access controls. This
article cannot grant audit rights or list subprocessors.
💳 Which tools consume credits
Read and status tools generally display work already in your account. Tools that generate, crawl, rebuild, or otherwise
run billable SEO work can consume credits or plan quota. The exact list changes, so use the in-product tool descriptions
and your billing page as the live reference.
- Before rollout, connect with a test user and review each enabled tool's description for credit or quota language.
- Restrict high-cost tools in Claude if your finance or IT policy requires approval first.
- Credit balances and invoices remain in Search Atlas. The connector does not move billing to Anthropic.
✅ What to send your security team
A complete internal review packet should include: the allowlisted URL, the connecting user's role, a screenshot of
enabled tools, whether that role is read-only, your DPA status, and the open questions on attestations, scopes, token
lifetime, log export, and subprocessors. Submit that list in one request so the reply can serve as written confirmation.
If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate
to be instantly connected with a member of our team.
