1. Greenhouse Support
  2. All Recruiting topics
  3. AI

Greenhouse MCP security FAQ

This FAQ provides technical and security information about the Greenhouse MCP server to support your evaluation of the feature.

It describes current Model Context Protocol (MCP) functionality, which may change over time.

Note: This article is not intended to be legal advice and does not override or contradict the advice of your legal counsel.

In this article

Authentication and authorization

How does Greenhouse MCP authenticate AI tools? Does it use my existing Greenhouse credentials or separate API keys?

Greenhouse MCP uses the OAuth 2.0 Authorization Code flow with Proof Key for Code Exchange (PKCE). You authenticate directly with Greenhouse; the AI tool only holds an OAuth token.

At a high level, the flow works like this:

Client registration: The AI tool registers using OAuth 2.0 Dynamic Client Registration and receives a client_id. There is no client secret because the tool is treated as a public client. PKCE is used to prove that each authorization request is legitimate.

User authentication: When you connect the tool, it redirects you to auth.greenhouse.io, where you sign in with your usual Greenhouse credentials. Your credentials go to Greenhouse only, never to the tool.

Consent: After signing in, you see a consent screen listing the data categories the tool is requesting, limited by what your organization has enabled. No access is granted until you approve.

Token issuance: Once you consent, Greenhouse issues the tool a short-lived access token and a rotating refresh token.

For background on these standards, see the OAuth 2.0 PKCE specification and Dynamic Client Registration.

Does the MCP server support IP allowlisting, geo-restrictions, or device-based conditional access controls, or are these expected to be enforced only through our identity provider (IdP) and surrounding infrastructure?

Greenhouse MCP does not currently provide its own native IP allowlisting, geo-restriction, or device-based conditional access controls at the MCP layer.

Access control at the MCP layer relies on:

  • Your existing Greenhouse permissions
  • The OAuth scopes that Site Admins configure for MCP

Device and conditional access are expected to be enforced by your identity provider and security stack.

We recommend configuring those controls in your IdP and network environment for users and AI tools that connect to MCP.

Token lifetime and revocation

How long does an MCP access token last, and how do I revoke access?

Token lifetime:

  • Access tokens expire after one hour. In most cases they refresh automatically, though the exact behavior depends on your AI client or proxy implementation.
  • Refresh tokens remain valid until there have been 14 consecutive days of inactivity. After that, the user must re-authorize the AI tool.

Revoking access:

  • Individual user: In your Greenhouse profile, go to Connections and click Disconnect. The tool’s token stops working immediately.
  • Site Admin: In Greenhouse Recruiting, go to Dev Center > MCP Access. Changing the configured scopes there immediately invalidates every active MCP token in your organization. Users will need to re-authorize under the new configuration.
  • User deactivation: When a user is deactivated in Greenhouse, all of their MCP OAuth 2.0 tokens are also invalidated.

A few things to know:

  • Changing your Greenhouse password does not invalidate existing MCP tokens.
  • Signing out of your single sign-on (SSO) provider does not invalidate existing MCP tokens.
  • There is currently no admin UI for revoking a single user’s MCP token without affecting everyone. The user must disconnect the AI tool themselves, or Greenhouse Technical Support can help.

When MCP access is disabled or scopes are changed, how quickly do changes propagate across tokens and systems?

Changes take effect almost immediately.

  • When a Site Admin changes MCP scopes in Dev Center > MCP Access, everyone currently using MCP is logged out and must re-authorize before making further MCP calls under the new settings.
  • If a user’s Greenhouse account is disabled, all of their OAuth tokens are invalidated.
  • Each token is checked against an encrypted database reference on every request, so revocation applies on the very next call made with that token.

The Greenhouse MCP server does not store or persist your data, so there is no MCP-side copy to clear or roll back.

Any data an AI client has already retrieved follows that client’s own retention and caching rules, which you manage directly with the AI provider.

To reverse an access reduction, re-enable the desired scopes in Dev Center > MCP Access and have affected users re-authorize. They will receive new tokens with the restored access.

Permissions and data access

How does Greenhouse MCP enforce my user permissions?

MCP enforces your existing Greenhouse roles and permissions in three levels:

Level 1: Organization scope – Greenhouse Site Admins decide which Harvest API data categories MCP tools can access at all, in Dev Center > MCP Access. These scopes set an organization-wide ceiling. No user can grant an AI tool more access than the Site Admin has enabled.

Level 2: User consent – When you authorize an AI tool, the consent screen lists the data categories available to that tool for your user, based on both your organization’s configuration and your own permissions. You can deselect categories you’d rather not grant. For example, you might allow read access to Jobs and Applications while withholding Candidates and Attachments.

Level 3: Individual permissions – Within those scopes, the AI tool acts using your own OAuth token, so the Harvest API applies your existing role and permissions exactly as it would for any other API call. If a recruiter cannot view a particular candidate or job, the tool receives the same denial. The token issued contains only the scopes you explicitly selected at authorization time.

Users can also re-authorize at any time to adjust which scopes a given AI tool holds. This gives individual users direct, granular control over each tool’s access independently of both the org-wide ceiling and their Greenhouse role.

What Greenhouse data can an AI tool access?

The Greenhouse MCP server exposes a subset of the Harvest v3 API as tools.

Access is always limited by both of the following:

  • The data categories your Site Admin has enabled in Dev Center > MCP Access
  • Your own Greenhouse permissions and role

The MCP Access page is the best source of truth for the API scopes that are available to the MCP server.

You can also reference the Harvest v3 documentation to understand what data is available via the Harvest API. Not all API endpoints may be exposed to the MCP server.

How will customers be notified or see a changelog when new MCP tools or capabilities are added?

Greenhouse does not currently expose a separate, public MCP tool-by-tool changelog.

As we expand MCP capabilities, we will communicate significant changes through our standard product documentation and release channels. Your Greenhouse account team can also help ensure you are aware of new tools that may be relevant to your environment.

Attachments and documents

Can AI tools access uploaded documents, resumes, or attachments from candidate profiles?

Partially. The MCP server exposes attachment metadata, including:

  • Filename
  • Attachment type (such as resume, cover letter, or offer packet)
  • A time-limited download link that expires after seven days

The MCP server itself never fetches or returns the actual file content.

Whether an AI tool reads the underlying document depends on the AI client:

  • If the client can fetch external links and parse documents, it can use the download link to retrieve and process the file.
  • If your security policy requires that AI tools do not reach raw document content, you can either enforce this in the AI client’s configuration or restrict the Attachments scope in Dev Center > MCP Access.

Can I limit MCP access to only a subset of my data (for example, one division or department)?

Not directly through MCP-specific controls.

The org-level settings in Dev Center > MCP Access work at the level of API endpoint categories:

  • You can turn access on or off for data types like candidates, applications, or scorecards.
  • You cannot use MCP settings alone to restrict access to a specific department, division, or region within those data types.

Your existing Greenhouse user permissions do provide scoping at the individual level.

If a recruiter’s role is limited to certain departments or jobs, MCP only returns data within those boundaries.

For stricter data partitioning, make sure Greenhouse user permissions are set up correctly and granularly before you enable MCP access.

Write actions and controls

What guardrails does Greenhouse provide for write or destructive actions?

AI tools can create notes, move applications, update candidate records, submit scorecards, and take other actions that change data, always within the user’s Greenhouse permissions and your organization’s configured scopes.

Org-level controls:

  • In Dev Center > MCP Access, Site Admins choose which Harvest API endpoint categories are available to MCP tools, and whether each one is read, write, or both.
  • To make MCP read-only, enable only the read scopes.
  • Any time scopes are removed, all active MCP tokens are invalidated immediately, and users have to re-authorize under the new configuration.

Hard limits that cannot be overridden:

Two safeguards are built into the MCP server itself and cannot be changed through scope settings:

  • Every DELETE endpoint is permanently blocked for MCP tools.
  • Five high-stakes actions require explicit human confirmation before they run:
    • Rejecting an applicant
    • Hiring an applicant
    • Merging candidates
    • Anonymizing a candidate
    • Bulk-revoking user permissions

For those five actions, the MCP server returns a plain-language summary of what is about to happen and stops. The AI client can show that summary to the user and send back a confirmation before the action goes through.

Approved AI tools and third-party security

What AI tools does Greenhouse support, and how does Greenhouse vet them?

Greenhouse currently supports Claude (Anthropic), ChatGPT (OpenAI), Microsoft Copilot Studio, Glean, Amazon Q, and Grok.

The list is not fixed. Any tool that implements the OAuth 2.0 Authorization Code flow with PKCE and Dynamic Client Registration can request to be added. If there is an AI tool you would like to use, contact your Greenhouse account team.

Currently, we vet against two requirements for our global list of supported tools, and neither is negotiable:

  1. Per-user authorization: The tool must obtain a separate OAuth token for each individual user. Shared credentials are rejected, so every action stays traceable to the specific person who authorized it.
  2. Redirect URI security: The tool’s callback URL must be registered and checked against Greenhouse’s allowlist every time a user authorizes, not just once at registration. This check is designed to reduce the risk of authorization codes being intercepted.

Organization-specific management of redirect URLs is planned for a future release, which would allow organization-specific governance for approved AI tools that can interact with the Greenhouse MCP server.

Training and safe usage

What user training do you recommend before enabling MCP, particularly around data handling, safe usage patterns, and prohibited workflows for AI tools connected via MCP?

We recommend treating MCP-connected AI tools as part of your existing AI and data-protection program, not as a separate thing to manage.

In practice, that often means:

  • Updating your internal training so users understand what they can expose to AI tools, which workflows are appropriate, and which ones your policies rule out
  • Being explicit that MCP enforces Greenhouse permissions, but does not replace your own responsibilities for configuring AI tools, data loss prevention tools, and data retention to meet your regulatory and contractual obligations

We also encourage you to involve your Legal team early.

AI use in hiring is governed by a fast-moving and often region-specific set of regulations, and Legal can help confirm that the way your organization uses these tools aligns with the requirements that apply to you.

Proxies and enterprise AI platforms

Does per-user permission enforcement hold when accessing Greenhouse MCP through a proxy, LLM gateway, or enterprise AI platform (for example, LiteLLM, Azure AI Foundry)?

Yes, as long as each user’s OAuth token is forwarded correctly.

The Greenhouse MCP server identifies who a user is, and applies their permissions, entirely from the authentication token in the HTTP Authorization header.

No other signal affects attribution: not another header, not an IP address, not proxy metadata.

  • A request carrying User A’s token is scoped to User A’s permissions, regardless of what infrastructure sits between the AI client and the MCP server.
  • If your gateway pools several users behind a single shared token, every request is attributed to whoever owns that token, so the permissions applied are that person’s, not the actual requester’s.

Make sure your enterprise AI platform is configured to obtain and forward a separate OAuth token for each user.

Custom or internal MCP clients

Can my organization use a custom-built or internally hosted MCP client?

Yes. Any AI tool or custom application that implements the OAuth 2.0 Authorization Code flow with PKCE and Dynamic Client Registration can connect to the Greenhouse MCP server.

Custom clients go through the same registration and authorization flow and are held to the same per-user permission enforcement. To add one, contact Greenhouse to have its redirect URI added to the allowlist. This is a manual step today.

A few security points to keep in mind:

  • Audit attribution: Greenhouse logs the OAuth client_id with every MCP action, so register your client with its own distinct client_id. Do not reuse one across multiple users or contexts.
  • Per-user token isolation: Your client needs to obtain a separate token for each user. If tokens are shared, every action shows up under a single user’s identity and skips per-user permission scoping entirely.
  • Token storage: Your client is responsible for storing access tokens (which last about an hour) and rotating refresh tokens (which last up to 14 days of inactivity) securely.

If you build your own MCP server that proxies to Greenhouse rather than connecting to Greenhouse’s server directly, you give up Greenhouse’s built-in MCP audit logging and permission governance for that proxied traffic. Those controls operate at the Greenhouse MCP server layer and do not automatically transfer to a separate proxy.

Data loss prevention

Does the MCP data path bypass or integrate with our existing Data Loss Prevention controls, and what guidance do you provide to ensure MCP traffic is covered by those protections?

MCP does not bypass your DLP controls, but it also cannot enforce them for you.

You are responsible for:

  • Ensuring you have controls in place to prevent users from accessing AI tools and Greenhouse from unmanaged devices
  • Enforcing your own data loss prevention controls such as device monitoring and network inspection

Because the MCP server uses standard HTTPS over known endpoints, your existing DLP tools can cover MCP traffic, provided they are configured to monitor and enforce policy on outbound HTTPS connections to those domains.

MCP does not open separate side channels or route around your network stack.

It sits behind your existing controls, so configure those controls to match your security policies and MCP traffic will be governed like any other outbound HTTPS traffic to Greenhouse.

Audit logging and visibility

What audit logging is available for MCP access?

The Greenhouse Audit Log captures detailed records of every API call made through an AI tool.

In the raw audit log:

  • MCP-initiated events are tagged with event.type = mcp_access, which sets them apart from direct Harvest API calls (harvest_access) and from UI actions.

In the Change Log you see in the Greenhouse UI:

  • Write actions taken through MCP currently appear under the user’s name, without a separate indicator showing that the action came through an AI tool.

Each MCP event records:

  • The Greenhouse user acting through the AI tool (user ID and email)
  • The OAuth client identifier of the AI tool (the registered client_id)
  • The HTTP method, endpoint path, and request parameters
  • The resource type being accessed
  • The timestamp

A few limitations to know about:

  • The event records the AI tool’s OAuth client_id (a UUID), not a friendly name like “Claude” or “ChatGPT”. To map it to a tool name, you will need to compare it to your registered client applications.
  • Whether you can query mcp_access events directly depends on your Greenhouse plan. Customers with the Audit Log add-on can pull these events through the Audit Log API.

For more information, see the Audit log overview. 

Compliance and data privacy

What GDPR and candidate data privacy regulations should we consider with the Greenhouse MCP server?

MCP access operates under the same legal basis as standard Greenhouse access.

  • Candidate data moves only in response to actions an authorized Greenhouse user takes.
  • There is no background processing and no proactive data export.
  • MCP operates under your existing Data Processing Agreement (DPA) with Greenhouse and, in Greenhouse’s assessment, does not introduce a new processing purpose.

Whether any change to your DPA is required is a determination you should make in coordination with your legal counsel.

In particular, the MCP feature:

  • Does not add any new data processing purposes.
  • Does not change the controller and processor relationship between you and Greenhouse (Greenhouse acts as data processor and you remain the data controller).
  • Does not, by itself, change your candidate notice or consent obligations.

As with standard Greenhouse use, whether additional candidate consent is required is a determination you should make in coordination with your legal counsel.

Candidate PII accessed through MCP carries the same retention, deletion, and data subject rights obligations as direct API access.

Data retention and infrastructure

Does the MCP server enforce encryption for data in transit?

Yes. All communication with the Greenhouse MCP server is encrypted in transit using TLS 1.2 or higher.

How does Greenhouse mitigate prompt injection risks with the MCP server?

Greenhouse’s threat model for MCP treats prompt injection as a real risk, and the Greenhouse MCP server is designed so that malicious content stored inside Greenhouse cannot freely cross authorization boundaries or exfiltrate data at will.

Key points:

  • Every request through MCP is permission-bound, scoped by OAuth, rate-limited, and non-persistent on the Greenhouse side, so there is a hard limit on what any single call can reach.
  • MCP never sees the user’s prompt or conversation. The server only receives structured tool calls (tool names and parameters), not free-form text.
  • Because MCP sees only structured tool calls, much of the usual prompt-injection surface is removed before it ever reaches Greenhouse.

Once data reaches the AI tool you’ve chosen, its behavior and retention are governed by that provider’s policies and by how you configure it.

Does Greenhouse retain or store content from AI conversations?

No. Greenhouse does not receive, process, or store the content of AI conversations.

  • The prompts you send to an AI tool and the responses it generates never touch Greenhouse servers.
  • What Greenhouse logs for MCP calls is structured API metadata for each request, such as which user, which organization, which action, which endpoint, and when. This is the same type of structured data Greenhouse records for any API call. It does not include the conversation itself.

Your AI vendor (for example, Anthropic or OpenAI) handles conversation storage and retention under its own policies. We recommend reviewing your vendor’s retention commitments for the tier you’re on.

Because you select and contract directly with your chosen AI tool, Greenhouse does not control and cannot restrict how that tool retains your data.

Regional hosting and data transfer

Does the MCP server endpoint differ by region?

The Greenhouse MCP server is currently hosted on US infrastructure at mcp.us.greenhouse.io.

There is not a separate EU-hosted MCP endpoint at this time.

For customers outside the US, personal data accessed through MCP is processed on US infrastructure, just as with other personal data sent to Greenhouse’s US-based systems.

Greenhouse participates in the EU-U.S. Data Privacy Framework and the UK Extension to the EU-U.S. Data Privacy Framework, and secondarily relies on Standard Contractual Clauses and additional safeguards for data transfers.

MCP requests are proxied through to the Greenhouse Harvest API, which follows Greenhouse’s standard data handling practices such as disk encryption and data retention, regardless of where the request originates.

Still have questions?

For additional security questions about MCP, contact your Greenhouse account team.