Lighthouse Hiring Connector Security Guide
Version 1.0 · Last Updated: November 12, 2026 · Owners: the CEO and the CTO · Applies to: the Lighthouse Hiring connector for ChatGPT and Claude
This guide describes the security architecture and controls of the Lighthouse Hiring connector, and the configuration we recommend customers apply when using it. It is intended for security reviewers, IT administrators and account owners.
1. Scope
The connector is a Model Context Protocol (MCP) server operated by Lighthouse at https://platform.lighthousehiring.ai/mcp. It allows an authorized user's AI assistant (ChatGPT or Claude) to read and act on that user's Lighthouse data. This guide covers the connector only. The handling of conversations inside ChatGPT or Claude is governed by the user's agreement with OpenAI or Anthropic.
2. Architecture
- AI assistant (client): ChatGPT or Claude, registered with Lighthouse as an OAuth client.
- Authorization server: Lighthouse sign-in, built on Supabase Auth (OAuth 2.1).
- Connector: a stateless MCP server running inside the Lighthouse application on Google Cloud Run.
- Data store: the Lighthouse database (Supabase Postgres), with row-level security on customer data.
Each request carries the user's access token. The connector verifies it, then runs every query as that user, so the database applies the same access rules as the Lighthouse web app.
3. Authentication
- Flow: OAuth 2.1 authorization code with PKCE (S256). The user signs in with their own Lighthouse account and approves the connection.
- Registered clients only: ChatGPT and Claude are pre-registered confidential clients that authenticate with a client secret. Dynamic client registration is not offered.
- Scopes:
emailandprofileonly. - Token validation: every request's token is checked for a valid signature, the Lighthouse issuer and expiry. Unsigned or unrecognized tokens are refused.
- Connector tokens only: a token must have been issued to a registered assistant. A token from an ordinary browser sign-in is refused, so a stolen web session cannot drive the connector.
4. Authorization and tenant isolation
- The connector's database queries run as the signed-in user. The connector holds no administrative database credentials.
- Access is limited to the companies the user is a member of in Lighthouse. The company is resolved on the server from that membership, never taken from the assistant's request.
- Data separation between customers is enforced by the database's row-level security, not by the assistant.
- The user's token is never forwarded to third parties. Where a connector action uses a Lighthouse AI service, it calls Lighthouse's own API, which applies the same user's permission checks as the web app.
5. Session lifetime and revocation
| Control | Setting |
|---|---|
| Access token lifetime | 10,000 seconds (about 2 hours 47 minutes) |
| Maximum session length | 24 hours from sign-in, after which the user must reconnect |
| Inactivity limit | 24 hours without a token refresh |
| Expired or revoked session | Token refresh fails with a standard OAuth invalid_grant error, and the user must reconnect |
| Signing out of Lighthouse | Ends only that browser session; the connector is disconnected separately |
6. Permitted operations
| Category | Operations | Control |
|---|---|---|
| Read | Jobs, pipelines, candidate details and scores, scorecards, interview questions and grades, screening answers, templates, reports | Limited to the user's companies |
| Confirmed changes | Publish, pause or archive a job; move a candidate to a stage; save a scorecard; save or archive a template; create a template from a job; remove an automation | Preview shown to the user; applied only with a valid confirmation token |
| Direct changes | Edit an unpublished draft job (details, stages, screening questions, search criteria); replace a stage's interview questions (earlier versions are archived); add a note, set tags, set a star rating | Applied as the user, under the same permissions as the web app |
| Not available | Sending email, rejecting candidates, creating or switching on automations | Not offered by the connector |
Confirmation tokens are signed by the Lighthouse server, bound to the user, assistant, company, operation and exact inputs, and expire after 5 minutes.
7. Threats and controls
| Threat | Control |
|---|---|
| Prompt injection through candidate content (for example, instructions hidden in a resume) | Candidate-supplied text is delivered to the assistant marked as untrusted data. Consequential changes require a server-issued confirmation token, which injected text cannot produce. |
| Excessive agency | Operations are limited to the list in section 6. Email sending, candidate rejection and automation activation are not exposed. |
| Token theft or replay | Short-lived access tokens, a 24-hour session limit, and confirmation tokens that expire after 5 minutes and are bound to their inputs. |
| Client impersonation | Only pre-registered clients with a client secret can obtain tokens. Browser session tokens are refused. |
| Cross-customer access | Row-level security in the database and server-side company resolution. |
| Tampered or third-party server | The connector is developed and operated by Lighthouse on its own domain; its operations ship with the Lighthouse application. |
8. Data handling
- Location: Lighthouse data is stored in the United States on Supabase and Google Cloud.
- AI processing: operations that generate content (job descriptions, scorecards, interview questions) use the same Lighthouse AI services and model providers as the web app.
- What is sent to the assistant: only the results of the operations the user requests.
- Logging: each connector request is logged with the user, company, assistant, request type and time. Request and response content is not logged.
- Conversations: Lighthouse receives only the operations the assistant requests, not the conversation itself. Lighthouse does not store assistant conversations or use them to train models.
9. Recommended customer configuration
9.1 Turn off model training on your chats. Lighthouse results returned to the assistant become part of your conversation with OpenAI or Anthropic. We recommend turning off the use of your chats for model training:
- ChatGPT: Settings → Data controls → turn off "Improve the model for everyone". See OpenAI: Data controls in ChatGPT. ChatGPT Business, Enterprise and Edu workspaces are not used for training by default.
- Claude: Settings → Privacy → turn off "Help improve Claude". See Anthropic: How do I change my model improvement privacy settings? Claude for Work (Team and Enterprise) is not used for training by default.
9.2 Use individual accounts. Each person should connect with their own Lighthouse login. Do not share a connected assistant account.
9.3 Grant only the access needed. The connector can reach every company a user belongs to in Lighthouse. Add users only to the companies they work on.
9.4 Review previews before confirming. Check the summary of each proposed change, especially when working with candidate content.
9.5 Offboard promptly. When someone leaves, remove them from the company in Lighthouse and disconnect Lighthouse in their assistant: ChatGPT (Settings → Apps) or Claude (Settings → Connectors).
9.6 Apply your retention policy to chats. Conversations that contain candidate information are held by your AI provider under your plan's terms. Delete them in line with your own data retention policy.
10. Assessments
Lighthouse's application is assessed against the OWASP Application Security Verification Standard (ASVS) every year, with the results verified by an authorized third-party lab.
11. Reporting a security issue
Report suspected vulnerabilities or incidents to security@lighthousehiring.ca. Reports reach the CEO and the CTO and are handled under the Lighthouse Incident Response Plan.