Greenhouse adds MCP connector to give hiring teams permissioned model access

Hiring software is turning into AI infrastructure. That sounds abstract, but the practical issue is simple — once a model can read candidate records, draft notes, or trigger workflow actions, the real product is no longer just the model. It is the connection layer. Greenhouse pushed on that layer on May 7, launching an MCP integration meant to let hiring teams use approved AI tools without punching a hole through the hiring system they already rely on. ### What did Greenhouse actually ship? Greenhouse shipped what it calls a Model Context Protocol integration — basically a standardized way for AI tools and agents to connect to Greenhouse with permissions attached. The pitch is not “more AI” in the vague sense. The pitch is that teams can use AI tools they already like, but keeping visibility, and keeping the ATS as the system of record. ### What is MCP in plain English? MCP is an open standard Anthropic introduced in late 2024 so AI assistants can talk to outside systems in a consistent way. Instead of every vendor building a custom connector for every model and every app, MCP gives them a shared protocol for exposing tools and data. That is why it has spread so fast through developer tools — and why enterprise software companies now want it too. ### Why does hiring need a special connection layer? Hiring data is unusually sensitive. Recruiters handle resumes, interview feedback, compensation details, and internal assessments. So the problem is not just whether an AI assistant is useful. The problem is who can see what, which actions are allowed, and whether those actions stay visible inside the workflow. Greenhouse has already been positioning its AI products around that broader line. ### Why is “permission-aware” the key phrase? Because the scary version of MCP is a model with broad tool access and fuzzy boundaries. The MCP ecosystem itself has been moving toward stronger authorization guidance, including OAuth-based controls for sensitive resources and administrative actions. Greenhouse is basically taking that design idea and applying it to recruiting software — approved tools, scoped access, and actions that happen in a floating agent sandbox. ### So is that enough to make MCP safe? No — and this is the important catch. Permissioning controls who gets access, but they do not make tool outputs trustworthy. Supabase’s MCP documentation says the model should treat tool results as untrusted, recommends human review before taking further actions, and notes that wrapping SQL results with extra instructions is only a partial defense against prompt injection hidden inside data. ### Why does tool-output trust matter so much? Because an MCP-connected model does not just read instructions from users. It also reads whatever comes back from tools — database rows, notes, documents, fields, comments. If malicious or simply messy text lands there, the model can misread it as something to obey. That is not a theoretical edge case anymore. Security researchers recently showed a Supabase MCP attack path that does not mean every MCP deployment is broken, but it does show where production failures can happen. ### What changed with this launch? The big change is where MCP is showing up. It started as a developer-tooling standard. Now it is moving into line-of-business software where the stakes are workflow governance, data access, and auditability. Greenhouse is one of the clearer signs that enterprise apps want MCP not just as a convenience layer, but as a policy layer. ### Bottom line? Greenhouse is betting that companies want AI inside hiring systems, not beside them. That is probably right. But the connector story has two halves — permissions on the way in, and distrust of model-readable outputs on the way back. Enterprise MCP is growing up, and both halves now matter.