Security & AI Data Handling

Nimloth helps employer teams define roles, configure evaluation modules, publish candidate application flows, review evidence, and record human decisions. Employer-side content such as role context, evaluation intent, internal review notes, operational metadata, and company settings remains employer-facing unless a specific customer-facing or candidate-facing surface is used.

Employer-only evaluation context is not shown to candidates. Where AI features use employer context, Nimloth sends task-specific data needed for that AI task.

Candidate data may include contact information, application submissions, answers to candidate-facing modules, timestamps, and evidence records used by the hiring organization. Nimloth keeps candidate application views separate from employer-only planning, review, and decision-support views.

Candidate submissions support the employer's recruitment process. Nimloth does not make binding employment decisions and does not present AI output as an automatic hire or rejection decision.

Nimloth may use configured AI providers, including OpenAI, for specific features such as employer review support and evaluation-design assistance. These features provide decision support; they do not act as autonomous decision makers.

Nimloth uses task-specific data minimization for AI features: the service prepares a narrow payload for the relevant task, validates returned output against product and governance rules, and keeps the employer responsible for final review and decision making.

Nimloth does not send the following to AI providers for normal configured AI tasks:

• secrets, API keys, cookies, auth tokens, or session tokens
• billing or payment secrets
• admin/internal operations data
• unrelated company, job, or candidate records
• raw production logs or broad debug payloads
• full provider prompts or raw provider responses in normal production logging

Some AI features may require candidate evidence for the specific candidate being reviewed, or summarized employer evaluation context for the specific job being configured. Those uses remain narrow and task-specific.

Nimloth supports human decision accountability. AI output may support review, highlight evidence, identify gaps, or suggest review attention, but the hiring organization remains responsible for final decisions.

Nimloth does not provide numeric candidate scoring, ordinal ranking, hire/no-hire automation, hire probability, or automated rejection language in AI-supported review flows.

Internal operational access is limited to authorized Nimloth operators and used for production support, readiness checks, smoke testing, and audited correction workflows. Admin views do not expose secrets, raw environment values, raw session identifiers, provider payloads, or broad candidate-private answer dumps.

Write actions available to internal operations are explicit, narrow, and auditable.

Nimloth keeps secrets and runtime credentials in server-side runtime configuration and does not render them in browser pages. Production logging uses safe operational metadata rather than raw payloads where possible.

Provider-boundary logs use metadata such as task type, status, model identifier, prompt version, field counts, or payload hashes rather than full prompts, raw provider responses, tokens, or candidate-private data.

Retention and deletion are currently governed by customer configuration, contract terms, operational needs, and applicable law. Nimloth supports deletion or correction requests where applicable, subject to technical, legal, and audit-retention constraints.

This page describes Nimloth's current V1 baseline and intended operating model. Final contractual terms, data processing terms, and customer-specific commitments are governed by the applicable written agreement and remain subject to legal review.