Letting an assistant work the desk under your own permissions

The Model Context Protocol is an open standard for connecting an AI assistant to a system it can act on. Rather than the assistant guessing at a REST API or scraping a screen, the system publishes a set of typed tools it will accept and a set of resources it will expose, and the assistant calls them.

For recruitment software that is a meaningful shape. A recruiter's day is a long sequence of small, well-defined actions across several records - find the candidates who match this brief, check who has not replied, book the second-stage panel, tell me which submittals are stale. Each of those is a tool call against structured data rather than a prompt against a document, which is why an MCP surface fits the work better than a chat box bolted onto a page.

It also puts the assistant outside the product. You would be able to work the pipeline from whichever assistant your firm already uses, rather than from a vendor's own copilot that only knows the vendor's own screens.

The planned tools cover the loop a recruiter runs most, and no more than that. A deliberately small surface is easier to reason about, easier to permission and easier to audit than one that exposes every endpoint the product has.

Each tool would be typed, with explicit parameters and a structured response, so an assistant cannot invent a field or partially construct a record. Write operations would be separated from read operations at the permission layer, so a firm can grant a sourcer read-only assistant access without granting the ability to send anything.

Resources are the read-only context an assistant needs to make sensible tool calls. Without them the assistant guesses at your field names and stage vocabulary, which produces confident nonsense.

Three matter most. Open requisitions give the assistant the live briefs, their must-haves, salary bands and stages, so a search can be constructed against a real requirement rather than a paraphrase. The candidate schema describes the structured fields including your own custom fields and their types, so a filter is expressed in terms your database actually stores. The talent-pool schema describes the pools and saved searches a desk works, so a request to add someone to the contract Java pool resolves to a real list rather than creating a new one.

The server would act as a signed-in user. Not as a service account, not as an integration identity with broad rights, and not as an administrator that scopes itself down by convention. It authenticates as a person, and from that point it can do exactly what that person can do and nothing else.

Everything follows from that. It inherits the user's tenant, so a request cannot cross the tenant boundary any more than the user's own browser session could. It inherits the user's role, so a recruiter's assistant sees the recruiter's pipeline rather than the firm's. It inherits field-level permissions, so if compensation history is hidden from that user it is absent from the tool response rather than filtered in the assistant's reply. And it is bounded by the same rate limits and the same consent and suppression rules that govern the interface.

The failure mode this avoids is the standard one. An integration granted broad rights becomes a way around the permission model: a recruiter who cannot see a field in the product asks the assistant, and the assistant obliges. Scoping to the signed-in user closes that route at the source rather than patching it per endpoint.

Demographic data collected for equal-opportunity reporting is stored separately from the hiring record and is not visible to recruiters at all. That separation exists so the data cannot influence a decision it exists to measure, and an assistant interface is exactly where such a separation gets quietly undone.

So the rule is absolute rather than permissioned: no MCP tool returns demographic fields, no resource describes them in a schema, and no aggregate response can be constructed that reveals them for an individual. There is no administrative override that turns this on, because an override is a feature request waiting to be made and the whole value of the control is that it cannot be argued with.

An action taken through the MCP server would be written to the same append-only audit log as the equivalent human action, with the same fields: actor, timestamp, reason code and the record touched. The entry names the assistant as the mechanism and the signed-in user as the actor, because accountability belongs to the person whose credentials were used.

There would be no separate, quieter log for assistant activity. That matters for the boring reason and the serious one. The boring one is that a desk lead reviewing a week's pipeline changes should see one list. The serious one is that a disposition audit, a client dispute or an equal-opportunity review has to reconstruct the decision, and a decision partly made by an assistant whose actions live in a different table is a decision that cannot be reconstructed.

It will not run unattended campaigns. Sending outreach through the tool would remain subject to consent capture, suppression lists and the messaging rules that apply to any send, and an assistant that could bulk-message a database without those checks is a compliance incident with a friendly interface.

It will not make hiring decisions. Disposition codes are a fixed list precisely so that a rejection is a recorded human decision, and moving a candidate to a rejected state is not on the planned tool surface. It will not expose billing or entity administration. It will not read another tenant's data under any configuration, because the boundary is enforced at the data layer rather than by the tool definition.

Before any of it ships, the permission model would be tested the way the tenant boundary is tested: adversarially, and by somebody who does not work here. The independent penetration test and tenant-boundary review being commissioned ahead of general availability sets the pattern, and an assistant surface deserves the same treatment because it is a new way to ask the same questions.

When work starts, this page changes to an in-build status and gains an evidence line naming the files that implement it, as every other feature page on this site does. Until then it stays planned, and no roadmap date is published here, because a date invented for a marketing page is a promise nobody has agreed to keep. If an MCP surface matters to your evaluation, say so during a demo and you will get a straight answer about sequencing rather than a slide.