AI Tenant Isolation: Protect Hiring Data Beyond Your ATS

AI tenant isolation keeps one customer’s AI inputs, retrieved context, and outputs inaccessible to other customers. In a hiring workflow, you need to examine both the application that authorizes candidate access and the provider that processes the resulting prompt. A promise that your data will not train a model answers a different question.

That distinction matters even when your recruiter has permission to read every field you send. Authorization can be correct at the start of a request while another part of the processing chain needs its own controls. Follow the candidate context through that chain, including the response you receive.

Ask a specific question: what evidence supports sending these fields through this route for this task? Start there before approving another AI feature across your hiring process.

What did the Cloudflare disclosure establish?

Cloudflare’s October 26 disclosure concerns GLM-5.3 on Workers AI. It reports cross-customer content exposure in 155 responses between August 27 and September 9, 2026, involving prompts longer than 681,280 tokens. It identifies no other affected Workers AI model and reports no evidence of deliberate exploitation.

According to Cloudflare, its serving engine failed to pass a prefill rejection to the decode stage, which then read cache pages that the request had not written. Cloudflare received the researcher’s report on September 8, restricted the model the next day, and restored it after correcting the configuration and engine behavior. Publication followed coordinated disclosure.

This describes an inference isolation failure, not evidence that customer prompts were used for training. The Hacker News discussion made the disclosure a current topic; neither source establishes that hiring records or Kit traffic were affected.

Which AI privacy promises answer different questions?

Review training, retention, authorization, and isolation separately. A reassuring answer about one does not establish the others.

Official documentation often separates these topics. Workers AI’s current data usage page discusses training and inference retention alongside stateful features, selected storage, and logging or caching through gateways. Read the conditions for the service you actually use; do not carry one service’s commitments over to another service reached through a gateway.

Microsoft Foundry’s privacy documentation separately discusses customer isolation, training use, stored features, and abuse monitoring. Its conditions depend on the deployment and features involved. These pages illustrate the questions to ask; they do not establish a ranking of providers.

For each answer, record its scope. “No training” without a named service and applicable terms leaves your team guessing. “No retention” without a list of enabled features does the same. Keep a dated link or approved contractual reference beside the configuration it describes, so a later reviewer can see what the original decision covered.

What candidate context does this task actually need?

Choose the minimum fields for the task before constructing the prompt. A member’s permission to open a candidate profile does not mean every field belongs in an AI request.

Consider a hypothetical request: “Summarize this applicant’s experience operating production databases against the requirements for this backend role.” The task needs relevant experience and the role criteria. It usually does not need a phone number, a home address, an email signature, or unrelated private correspondence.

Write down the intended input before connecting the integration:

This is a proposed field selection, not a claim about a particular product’s defaults. A different task may need different information. Drafting a message might require a name; sending it requires a destination in the sending system. Neither necessarily requires placing the destination into the model’s prompt.

OWASP’s sensitive information disclosure guidance covers least privilege, restricted data sources, and redaction or tokenization. Apply those principles to the actual task rather than treating a generic instruction to “keep data private” as a control.

An internal reference also deserves care. If your application can map it back to a person, do not describe the result as anonymous. A detailed employment history may identify someone without their name. Minimization reduces the material exposed; it cannot repair a serving engine or remove every inference someone could draw.

Create a short review record for each workflow. Record the task, initiating role, source records, selected fields, destination, and where inputs or outputs remain stored. Include retries and fallback routes. Mark unanswered questions explicitly, with an owner, so uncertainty cannot quietly become an approved assumption. Our candidate-data security guide provides broader context for handling the records around that request.

What should you ask the inference provider?

Ask for evidence tied to your service, model, and deployment. A general security page is useful context; your decision needs to account for the route that will receive candidate material.

Start with a concrete description of your workflow. Explain which kinds of records you plan to submit, whether you use a gateway or router, which stored features are enabled, and whether your application retries failed requests. Give the provider enough detail to address your configuration.

Then ask questions that help your team decide:

• Processing separation: How does customer separation apply during inference and to reusable processing state? Which parts are shared, and which controls enforce the boundary?
• Failure behavior: What happens when a request is rejected, cancelled, interrupted, or retried? Does the documented isolation approach cover those paths?
• Persistence: Which enabled features store prompts, outputs, or associated records? Which logging and caching settings belong to a gateway rather than the model service?
• Incident evidence: Which identifiers let the provider locate a request and scope a reported problem? How will you learn if the relevant service or model is affected?
• Change ownership: Who tells your team when a route, model, feature, or processing condition changes enough to require another review?

These are proposed buyer questions. They are not a certification scheme, and a vendor may reasonably withhold sensitive implementation details. Your security owner still needs enough scoped evidence to decide whether the workflow is acceptable.

NIST’s secure development guidance for generative AI addresses producers and acquirers across the lifecycle. Use that broader perspective when assigning responsibility: acquisition, configuration, operation, and incident handling need owners. The questions above are our application of that perspective to hiring workflows, not a checklist prescribed by NIST.

Record the result as an explicit decision. You might approve a narrow task, reduce its input fields, disable a stored feature, or leave the workflow unapproved until a material question is resolved. Keep the reasoning beside the route inventory. A future teammate should understand what would require revisiting it.

What can your own isolation tests prove?

Your tests can verify observed behavior in the application and environments you control. They cannot certify the internal operation of a managed provider’s serving fleet.

Use synthetic candidates in accounts your organization owns. Give the records distinct invented facts and references. Do not use real candidate material as a test marker, and do not attempt to retrieve another customer’s content.

A useful application test plan follows access through the response:

1. Check the account boundary. A member in test account A requests the synthetic candidate belonging only to account B. Verify that the application refuses access before constructing an outbound request containing B’s context.
2. Check restricted work within an account. A member excluded from a restricted job requests its synthetic context. Verify the applicable posting permissions, rather than relying on account membership alone.
3. Check errors and retries. Interrupt a request in the controlled test environment. Verify that a retry retains the authorized account and task context, and that an error does not trigger broader retrieval.
4. Check the destination. Complete a permitted request and verify where its answer is saved and displayed. Check background completion as well as the immediate response.
5. Check access after a change. Change the test member’s permissions while work is pending. Verify the behavior your product promises when the response later becomes available.

For each test, record the expected result before running it. Capture enough evidence to distinguish a refused request from one that fetched unauthorized data and merely hid the answer afterward. Those are different application behaviors with different implications.

Unique synthetic markers can help trace a mistake in your own system. A clean run does not prove that every request, model, device, or provider deployment is isolated. Keep the test result narrow: the tested application path behaved as expected under the recorded conditions.

Define when the test plan needs updating. Changes to retrieval, background jobs, provider fallback, or output storage can change the boundary even when the visible hiring feature looks identical. Review the relevant tests when those paths change, and keep the provider questions separate from application assertions.

How should you handle unexpected data in an AI response?

Treat an unexpected personal record as an incident to contain and investigate. A confident explanation from the model is not evidence of where the material came from.

First, restrict access to the response and pause the affected workflow or model route while the incident owner assesses it. Keep the scope precise enough that your team knows which processing is paused. Avoid copying the unexpected record into a shared chat, a support screenshot, or another external AI tool for analysis.

Preserve the identifiers and configuration needed for investigation: request and response references, timestamps, model and route, relevant settings, and the initiating account. Follow your incident process for retaining the minimum necessary content. Keep access to that evidence limited, with a named owner.

Then contact the provider through its incident or security channel. Ask for help establishing the source and scope of the response. Your own investigation should also examine retrieval and output routing; an application error remains a possible explanation until evidence establishes otherwise. If you are building that reporting channel, our vulnerability disclosure guide covers the surrounding intake process.

Trace what happened after the response arrived. Was it saved as a note, included in a candidate summary, exported, or displayed to another reviewer? Containment needs to cover these copies as well as the original request. Record the findings without widening access to the personal information itself.

Let your designated privacy and security owners assess any notification obligations using the confirmed facts and applicable requirements. The appearance of unexpected text alone does not establish a particular legal conclusion. Before restoring the workflow, document what failed, which change supports restoration, and what remains uncertain.

Keep the hiring boundary explicit in Kit

Include Kit’s application controls and provider settings in the review, and state what each covers. Neither removes the need to examine the material sent outside the application.

A source review of Kit’s candidate-summary MCP tool shows a concrete application boundary: it requires account membership, resolves the candidate within the current account, and checks accessible job postings. A candidate associated only with restricted postings is not returned through that tool to a member without access.

The authorized summary can still contain a candidate’s name, email, telephone number, and accessible résumé context. Email and telephone encryption at rest does not mean those fields cannot appear as plaintext in an authorized tool result. Review the actual tool and task before assuming that candidate contact details have been excluded.

Kit’s AI provider documentation also describes separate processing routes. The preferred provider controls most in-app chat and generation work. Semantic indexing and search use Google’s embedding service through Kit’s platform key independently of that preference. Hiring Live Review uses the account’s own Gemini key, and Compensation Research background enrichment has another fixed Gemini path. Account-key spend caps do not stop all of these separate paths.

An external assistant connected through MCP adds its own processing boundary. Its permission to request information from Kit and its handling of the returned information are separate review questions. Changing Kit’s preferred provider does not configure that external assistant.

Start with one hiring task. Identify who may retrieve the records, inspect the fields that leave the application, and review the real processing route and saved output. Then test the application boundaries you control and resolve the provider questions with the appropriate owner. If you are evaluating Kit, use the documented routes and a synthetic candidate to make that review concrete before adding sensitive hiring context.