OpenDetector detection models
Scope AI-text detection and prompt injection or jailbreak detection with a separate serving contract, operating policy and measured evaluation.
OpenDetector has two separate model families. OpenDetector-AI provides AI-generation signals for text review. OpenDetector-Injection provides prompt injection and jailbreak signals for application and agent protection. A text can be generated without being malicious, or human-written and contain an attack. Keep the signals and evaluations separate.
Access is evaluation by request. Start on the Detection page and describe the models, integration, volume, languages, operating criteria and deployment requirements. The pilot confirms serving readiness, account access and commercial terms. The public catalog does not assign callable Grid IDs or a production endpoint to these models.
Choose an integration#
| Integration to scope | Where the check belongs | Decision to agree |
|---|---|---|
| Standalone Detection API | Submitted text from your application, with any model provider | Record a signal or route text for review |
| Inference guardrail | Before user input or retrieved text reaches the model | Observe, review or block according to policy |
| Agent guardrail | Retrieved passages and tool results, before a subsequent model call or action | Escalate suspicious content while retaining separate tool permissions |
| Private deployment | A defined environment and reserved capacity | Agree region, access, retention, version and operating responsibilities |
These are pilot integration paths. Your agreement defines which are enabled. Do not send a detector name to chat completions or assume Smart Router automatically runs a detection check. Detection has a separate request and response contract.
Define the serving contract#
Confirm the API base, exact model and version, authentication, enabled checks, input limits, timeouts and error behavior during onboarding. A detection response should identify the served version, coverage and signal separately from the policy decision.
The following is a contract design example for discussion, not a live API response or a promise of a specific label schema. The numbers are illustrative, not a measured model result.
{
"request_id": "example-request",
"status": "completed",
"model_version": "agreed-pinned-version",
"coverage": { "complete": true, "reason": null },
"signals": [{ "kind": "prompt_injection", "score": 0.82 }],
"policy": { "version": "customer-policy-version", "action": "review" }
}
Treat scores as model signals whose interpretation depends on calibration. A score is not an authorship certificate or a universal probability that an action is safe. Categories, spans and explanations require their own validation; a binary classifier does not by itself produce a reliable attack subtype or explanation.
Coverage and decisions#
Agree the languages, text lengths, document types, extraction requirements and attack classes the pilot will measure. Long documents require measured segmentation and aggregation. A backbone's maximum context does not establish the served detector's validated limits.
Require explicit states for unsupported input, insufficient text, incomplete extraction, truncation, timeout and unavailable checks. Do not convert any of these into a clean verdict. The customer policy decides whether to retry, request review or stop an action.
AI-text detection supports triage and human review. It should not independently authorize an adverse decision about a person. Injection detection complements bounded tool access, authorized retrieval and approval for consequential actions. The OWASP prompt injection guidance describes layered controls for model and agent applications.
Evaluate before enforcing#
Build a representative, labeled set for each detector. Include normal work and difficult cases. Separate training, calibration and acceptance data. Keep an untouched acceptance set and pin the model, calibration and policy for the production decision.
For AI-text detection, include human text, generated text, edits and paraphrases across required languages and lengths. For injection detection, include direct attacks, indirect instructions, jailbreaks, obfuscation and benign content that resembles an attack.
Measure false positives, missed detections, abstentions, coverage, review effort, response time percentiles and total cost. Start with observation. Move to review or blocking only after the operating policy passes the agreed acceptance criteria. Plan rollback to a validated version and a defined response to detector failure.
Commercial scope#
There is no published detection rate card. A quote confirms the chargeable unit, currency, model version, text limits, throughput, region, support and any minimum commitment.
Include long-document segmentation, repeated checks, unsuccessful or incomplete scans, private capacity, extraction and additional services in the cost boundary. Define how these are metered before comparing providers. Detection does not generate an output-token stream, so the chat inference calculator and its Batch discount do not establish detection costs.
Compare cost per completed check and cost per accepted workflow result, including human review. See detection pricing scope, the evaluation guide and deployment review.
Prepare the access request#
Describe the data categories and requirements without pasting documents, datasets or credentials into the inquiry. Confirm authorization and data handling before transferring pilot samples. Production rollout also needs verified account permissions, usage metering, effective rates and the agreed failure policy.