Loading documentation…

Loading…

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.com/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 probesFastest

Standard

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

~2minCap: 200 probesDefault

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.com/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

Queued

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

Running

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

Evaluating

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

Completed

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

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.com/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.

Comparing scans

Run the identical probe set against two agents — typically staging and production — and diff the findings. Available on Team plans and above; credits are metered per scan, so a comparison costs twice a single scan.

Launch

New Scan → Compare two agents. Pick a staging and a production agent, each with its connection; suites derive from the staging agent.

Live progress

Both sides run in parallel with per-role progress bars. Results appear only when both scans finish.

Four buckets

Regressions (severity escalated), persistent, new in production, and fixed in production — with per-side risk scores.

History

Past comparisons live under Compare in the sidebar. Each side stays a normal scan row for retry, export, and audit.