Guide

Scans

A scan executes a set of security probes against an agent endpoint. Scans run asynchronously via a Redis-backed worker queue.

Creating a scan

Select a probe set and an agent. If no probe set is specified, all available probes are used (up to 200).

Create a scan
curl -X POST https://api.orithos.dev/v1/scans   -H "Authorization: Bearer {api_key}"   -H "Content-Type: application/json"   -d '{
  "agent_id": "agent_abc123",
  "probe_set": "prompt-injection",
  "name": "Weekly prompt injection scan"
}'

Scan depth levels

Orithos offers four depth levels that control scan thoroughness. Choose based on your security posture needs and time budget.

Quick

Takes only the top 3 highest-severity probes per category. Skips low-severity and redundant tests. Best for CI/CD pre-commit hooks or rapid sanity checks.

~30sCap: 50 probes
Fastest

Standard

Runs all selected probes as-is. No filtering or variant generation. Suitable for regular security audits with predictable coverage.

~2minCap: 200 probes
Default

Deep

Runs all probes plus 3 prompt variants per probe using different social-engineering wrappers (polite request, urgent need, authority claim). Catches surface-level guardrails that only block specific phrasings.

~4minCap: 150 probes

Exhaustive

DEEP + 5 variants per probe + regression re-run of probes that had findings in the original scan (for rerun workflows). Maximum coverage — use for compliance audits and pre-release certification.

~8minCap: 200 probes

Specifying depth via API

curl -X POST https://api.orithos.dev/v1/scans \
  -H "Authorization: Bearer {api_key}" \
  -H "Content-Type: application/json" \
  -d '{
  "agent_id": "agent_abc123",
  "probe_set": ["probe_prompt_injection_01", "probe_tool_misuse_01"],
  "depth": "exhaustive"
}'

Valid values: quick, standard, deep, exhaustive. Default: standard.

Cap limitations

Each depth level has a maximum probe cap to prevent ARQ job timeouts (30-minute limit). Probes beyond the cap are dropped from the end — variants are dropped first, then regression probes, then originals. If you consistently hit caps, reduce the initial probe set size or use a lower depth level.

Scan lifecycle

1

Queued

The scan is enqueued in Redis and waits for a worker to pick it up.

2

Running

A worker acquires the job and begins executing probes. Progress updates stream in real-time.

3

Evaluating

Each probe response is analyzed by the LLM-as-Judge evaluator for vulnerability detection.

4

Completed

All probes executed. Findings, verdict, and compliance mappings are persisted.

5

Failed

The scan encountered an error (endpoint unreachable, evaluator failure, scan timeout). No quota charged.

Progress tracking

Scans expose real-time progress via the API. The completed_tests, current_probe_name, and probes_completed fields are updated after each probe execution.

curl https://api.orithos.dev/v1/scans/{scan_id}   -H "Authorization: Bearer {api_key}"

Rerunning scans

Rerun a completed scan with different scope. Useful for regression testing after fixing vulnerabilities.

Same

Rerun the exact same probe set.

Failed only

Only probes that produced findings.

Passed only

Only probes that passed without findings.