Security and legal FAQ

A guide for customer legal, security, and privacy teams Version 1.1 · August 2026 This document answers the questions legal, security, and privacy teams most often ask when evaluating the SeekOut MCP server. It is intended to be shared with your internal review teams. Additional supporting materials, including our SOC 2 Type II report, penetration test attestation, and security policies, are available under NDA from your SeekOut account team or trust.seekout.com.

​

At a glance

​

Frequently asked questions

​

1. What is the SeekOut MCP server, and how does it work?

The Model Context Protocol (MCP) is an open standard introduced by Anthropic and adopted across the industry, including by OpenAI, Microsoft, and Google that lets AI assistants connect to business applications in a controlled, auditable way. The SeekOut MCP server is a remote MCP server hosted and operated entirely by SeekOut inside our SOC 2–audited production environment. There is no software for you to install, host, or patch, and no third party operates the server on our behalf. When one of your users connects an approved AI assistant (for example Claude, ChatGPT, Microsoft Copilot, or Gemini) to SeekOut, the assistant sends requests to the SeekOut MCP server over an encrypted HTTPS connection. The server executes each request against the SeekOut platform on that user’s behalf — running searches, retrieving candidate profiles, analyzing talent markets, or exporting to a connected ATS — and returns the results to the user’s assistant. Functionally, it is equivalent to the same user performing the same actions in the SeekOut web application: the same APIs, the same permission checks, and the same data.

​

2. How are users authenticated? Can MCP expand what a user can see or do?

MCP adds a new interface to SeekOut, but does not add any new privileges. Users authenticate by signing in to their existing SeekOut account through an OAuth authorization flow, including single sign-on where your organization has configured SSO (SeekOut supports any SAML 2.0–compliant identity provider, with MFA available through SSO). Every MCP tool call executes under the authenticated user’s identity and is subject to exactly the same controls as the SeekOut application itself:

• Role-based access control — users see only what their SeekOut role allows.
• License entitlements — features such as contact retrieval consume the same credits and respect the same limits as in the app.
• Organization boundaries — users can only operate within your organization’s SeekOut tenant; cross-organization access is never available unless your organization has explicitly configured it.

Access is revoked the same way it is granted: disconnecting the MCP connector in the AI assistant ends its access, and deactivating the user in SeekOut (or deprovisioning via your IdP) revokes all access, including through MCP.

​

3. What data flows through the MCP server, and where does it go?

The data flow has three parties: your user’s AI assistant, the SeekOut MCP server, and the SeekOut platform. A request originates with your user, is processed inside SeekOut’s production environment in the United States, and the results are returned to that user’s AI assistant. The MCP server introduces no new data stores and no new data flows. It exposes the same data your users already access in SeekOut: SeekOut’s candidate database, your organization’s saved searches and workspaces, and your ATS data where you have connected an ATS. Once results are returned to the AI assistant, their handling is governed by your agreement with that AI vendor (for example, your Anthropic, Microsoft, or OpenAI enterprise terms) — just as it would be if a user pasted the same information into that tool manually. For this reason, we recommend connecting SeekOut MCP only to AI assistants your organization has approved under enterprise terms. See question 9 for governance recommendations.

​

4. Is our data used to train AI models?

No. Customer data is never used to train SeekOut’s AI models. This applies to all use of the SeekOut platform, including through the MCP server. SeekOut’s own AI capabilities use off-the-shelf foundation models accessed through Azure AI Services; customer data is not used to train, fine-tune, or improve those models, and no identifying customer information is required by them. On the client side, whether your prompts and results are used to train the AI assistant’s models is controlled by your agreement with that AI vendor. The enterprise offerings of major AI vendors (including Anthropic and OpenAI) do not train on customer data by default — another reason we recommend enterprise-tier AI clients.

​

5. How is data secured in transit and at rest?

The MCP server runs inside the same production environment as the SeekOut platform and inherits its full security program:

• Encryption — all traffic is encrypted in transit with TLS 1.2+; all data is encrypted at rest with AES-256, with keys managed in Azure Key Vault.
• Hosting — Microsoft Azure, exclusively in the United States (US West 2, replicated to US West Central). Backups are encrypted and stored in a separate US location managed by Azure.
• Tenant segregation — customer data is logically segregated with strong access controls; production data is never used in test or development environments.
• Internal access — SeekOut staff access to customer data is granted on a need-to-know, least-privilege basis, requires MFA, and is logged.
• Monitoring — full security logging monitored by our SIEM (Microsoft Sentinel), with Azure Web Application Firewall protection at the network edge.

​

6. What independent security assurance does SeekOut maintain?

SeekOut maintains a SOC 2 Type II attestation covering all five Trust Services Criteria — Security, Availability, Confidentiality, Processing Integrity, and Privacy — renewed through an annual independent audit. The MCP server is operated within this audited environment. Ongoing independent testing includes:

• An annual penetration test performed by an independent third party, with findings remediated through our vulnerability management program.
• Monthly vulnerability scans performed by a third party, with critical findings fixed within the same sprint cycle.
• An active bug bounty program on HackerOne covering all customer-licensed software.

Our AI governance practices align with ISO/IEC 42001:2023 (AI management systems) and ISO/IEC 23894:2023 (AI risk management), with oversight from a cross-functional AI Governance Committee spanning legal, engineering, and product. The SOC 2 report and penetration test attestation are available under NDA.

​

7. How does MCP fit our existing agreement and DPA? Do we need new terms?

The MCP server is a feature of the SeekOut services and is governed by your existing agreement with SeekOut, including our Data Processing Agreement (available at seekout.com/terms/data-processing-agreement). No separate agreement is typically required. The established roles are unchanged: SeekOut acts as a processor (service provider under CCPA/CPRA) of your customer data, processing it only on your instructions, and as a controller of the SeekOut candidate database. SeekOut does not sell customer data and claims no rights to use customer-derived data for its own purposes. Using MCP adds no new subprocessors. SeekOut’s subprocessor list is unchanged (Microsoft Azure for hosting; Atlassian and Intercom for customer support infrastructure). Your AI assistant vendor is your own vendor under your own terms — it is not a SeekOut subprocessor.

​

8. How does SeekOut handle privacy compliance and data subject rights?

SeekOut maintains GDPR and CCPA compliance programs led by an appointed Data Protection Officer. International transfers are governed by Standard Contractual Clauses and the UK IDTA, incorporated into our DPA. Individuals — including candidates in the SeekOut database — can exercise access, deletion, and other rights through our Privacy Choices portal at seekout.com/privacy/choices; requests are processed within 30 days. Full details are in our Privacy Policy at seekout.com/privacy. Retention is unchanged by MCP: customer data is retained for the duration of your contract and deleted within 60 days of termination, and your administrators can delete data at any time. SeekOut has not been subject to any regulatory enforcement action or litigation relating to data privacy, and has had no data breaches to date.

​

9. What AI-specific risks exist, and how does SeekOut mitigate them?

Connecting any application to an AI assistant introduces risks that are inherent to the technology, including prompt injection (malicious instructions hidden in content the AI reads), excessive agency (an AI taking broader action than the user intended), and hallucination. SeekOut’s mitigations include:

• Least-privilege tool design — MCP tools mirror discrete user actions in the SeekOut app. There are no bulk-delete or destructive administrative operations exposed through MCP.
• User-scoped execution — because every call runs with a single user’s permissions and credit limits, the blast radius of any misuse is bounded to what that user could already do (see question 2).
• Input analysis and platform guardrails — SeekOut applies prompt analysis to detect malicious input, alongside the built-in protections of Azure AI Services.
• Logging and monitoring — MCP activity is logged and monitored the same way as all platform activity, via our SIEM.

No MCP server can control the behavior of the AI client itself, which is why we also recommend the customer-side controls in question 10 — the same posture taken by other enterprise MCP providers.

​

10. What should our security team do to govern MCP usage?

We recommend a short list of practical controls, consistent with how security teams govern other MCP integrations:

• Approve AI clients deliberately. Allow SeekOut MCP only with AI assistants your organization has vetted, under enterprise agreements with no-training commitments.
• Enforce SSO and MFA for SeekOut so that identity, session, and deprovisioning controls apply to MCP access automatically.
• Apply least privilege in SeekOut. Review user roles, license entitlements, and contact-credit allocations — these bound what MCP can do for each user.
• Keep humans in the loop. Train users to review AI-drafted actions — especially exports and candidate outreach — before confirming them, and to verify AI summaries against source profiles.
• Ask us. Questions, security reviews, and vulnerability reports can be directed to [email protected].

​

11. Is the integration read-only, or can it take actions?

Both, and the split is deliberate. Most tools are read-only — searching, counting, retrieving profiles, and analyzing talent markets. The write actions all stay inside the user’s own SeekOut account: creating and updating candidate workspaces, exporting profiles to Excel or Google Sheets, sending selected candidates to an ATS your administrator has already connected, and retrieving contact details (which consumes the same credits as in the app). The Tool reference labels the behavior of every tool.

​

12. What is exposed on the network, and how is the endpoint protected?

The entire integration surface is a single HTTPS endpoint — https://seekout-search-mcp.seekout.io/tools — plus the standard OAuth discovery documents (RFC 9728 protected-resource metadata and authorization-server metadata) that MCP clients use to find the sign-in flow. Requests without a valid token fail closed with 401 and a standards-compliant challenge; bearer tokens are accepted only in the Authorization header. Access tokens are short-lived, asymmetrically signed, and audience-bound to the MCP endpoint, and the server validates the signature, issuer, audience, and expiry on every request — authorization is never carried over from earlier calls or session state. The endpoint exposes no administrative operations: there is no tenant administration, user administration, or billing surface, and no path to SeekOut’s underlying databases or infrastructure.

​

13. What does SeekOut store about MCP conversations?

SeekOut never receives or stores your chat transcript. The AI assistant sends only the individual tool calls it makes — the search criteria, and on selected tools the user’s request text so the platform can check the action against what the user asked for. What SeekOut keeps:

• Short-lived search-session state, scoped to the conversation and expiring within 12 hours: the active data source, query, filters, and the recent requests made in that conversation. It contains no candidate profile data, and search results are not cached on SeekOut’s servers.
• Operational telemetry for security, reliability, abuse prevention, and support: tool names, timestamps, outcomes, result counts, user and organization identifiers, and the payload sent to each individual tool call — for example the search criteria passed to a search. Candidate profile contents and retrieved contact details are never written to logs or telemetry.

This data is handled inside the same SOC 2–audited environment and controls described in questions 5 and 6. On the assistant side, your chat history is stored and governed by your AI platform under your agreement with that vendor — for Microsoft 365 Copilot, for example, conversations remain in your tenant subject to your Purview audit and retention policies.

​

14. Can SeekOut access our Microsoft 365, Google Workspace, or other AI-platform data?

No. The integration is strictly one-directional: your AI platform calls SeekOut, never the reverse. SeekOut holds no credentials for your tenant, requests no tenant data, and installs nothing in your environment. The only things SeekOut ever receives are the OAuth protocol exchange and the tool calls described in question 13, and the only credentials involved are SeekOut-issued tokens for SeekOut. Availability of the integration to your users remains under your platform’s own admin controls (for example, agent approval in the Microsoft 365 admin center). A related question: what can the agent itself do on the platform side? Where SeekOut publishes an agent for an AI platform — such as the SeekOut agent for Microsoft 365 Copilot — that agent runs on the platform’s own infrastructure and may declare platform-provided capabilities. Examples include a code interpreter, which supports features such as generating talent dashboards from your search results, and access to the signed-in user’s own Microsoft 365 content. Those capabilities are executed by Microsoft, inside your tenant, as the signed-in user and under that user’s existing Microsoft 365 permissions — they are not SeekOut reaching into your environment, and the content they touch is never transmitted to SeekOut. Your administrator can review an agent’s declared capabilities before approving it for your users; whatever those capabilities are, the answer above is unchanged, because none of that content reaches SeekOut’s systems.

​

15. What candidate data does the integration return?

Results contain professional profile information from SeekOut’s candidate database — the same fields the user would see in the SeekOut application, and no more. A search result includes fields such as name, current title and employer, location, a public professional profile link, a profile photo, years of experience, a short list of skills, and recent positions. When a user explicitly requests full profiles, the response also includes complete work history, education, certifications, and languages, plus source-specific professional attributes for the specialized pools (for example a provider identifier for healthcare, or repository and publication metrics for the GitHub and academic pools). Market analysis returns aggregate figures such as pool sizes and distributions, which are not personal data. Contact details follow two different rules. Email addresses and phone numbers sourced from SeekOut’s contact database are returned only when a user explicitly requests them for selected candidates, and they consume your organization’s contact credits — see Work with candidates. Contact fields your organization already holds in its own records — for example the email on one of your ATS candidate records, or a colleague’s details in your internal employee directory — appear alongside the other fields of that record for users licensed for those sources, and do not consume credits. Responses do not include internal system identifiers, internal request payloads or endpoints, debug or diagnostic fields, or authentication secrets.

​

16. What is different about building our own agent on the SeekOut connector?

Two Microsoft paths exist, and they differ in who configures the experience. The SeekOut agent for Microsoft 365 Copilot is published by SeekOut in the Microsoft 365 agent store, having passed Microsoft’s validation for Copilot agents; its tool set and its confirmation prompts for actions that write or spend credits are part of the package SeekOut ships. If instead you build your own agent on the SeekOut connector in Copilot Studio (see Connect SeekOut with the Microsoft Connector), your agent’s orchestration reflects SeekOut’s tools dynamically, and the prompting, tool selection, and action-confirmation experience are part of your agent’s configuration. The SeekOut-side controls are identical either way: every call is authenticated as the signed-in user and re-checked against that user’s permissions, entitlements, and credits, as described in question 2.

​

Resources and contacts