What did our sandbox establish?
Our sandbox recorded successful install, build and test commands in Detection/ on September 27, 2026, at commit abc12c2. The full revision was abc12c20893f793aa1c22fcd0296052423de00f1. Installation took 154 seconds, with 324 packages occupying 7,037 MB; build took 5 seconds and the test step took 42 seconds. These observations belong to that stored run. This correction involved no new execution.
The stored parser summary records 248 passed, 0 failed, 0 skipped and 0 errors. It does not establish exhaustive unique test coverage. The raw pytest footer separately reports "248 passed, 25 warnings in 28.27s". We retain that suite duration alongside the harness's command duration and do not add repeated footer counts. The attached run records no collection error.
Our harness records command outcomes through success status, exit code, elapsed time, timeout status and parsed test counts. Each of these three commands returned zero without timing out. The MrKeyoor testing methodology explains this reporting model and its limits; its current description does not establish which methodology version governed this older run. The record does not demonstrate live agent collection, a Sensor CLI deployment, OTLP delivery, benchmark workload completion or detector accuracy.
Does the public release prevent unsafe actions?
ADR Prevention is excluded from the public release. The Uber ADR README lists Discovery, Sensor, ADR-Bench and Detection as public components and also excludes the offline Explorer engine. Discovery inventories endpoint AI tools; Sensor normalizes recorded activity; the benchmark supplies evaluation material; Detection combines triage with deeper reasoning about suspicious sessions.
Use those components when investigation or evaluation is your immediate need, and plan enforcement separately. Uber reports deploying ADR in production, but that vendor statement does not validate deployment of the public components in your environment. It also does not extend our Detection command results to the Sensor or Discovery components.
Can you deploy the benchmark in production?
The Detection README requires an isolated environment and says the benchmark is not intended for production deployment. It explains that dependencies pinned for paper reproducibility carry known CVEs. Synthetic credentials, prompt-injection payloads and emulated vulnerable MCP servers are intentional research fixtures; the documentation forbids pointing the benchmark at live systems, real credentials or production MCP servers.
Our sandbox's pip-audit result recorded 166 advisories across 19 packages. These are recorded dependency advisories, not demonstrated exploits. The record does not supply scannedPackages, so the total number of packages scanned remains unknown. Successful tests do not remove the Detection README's isolation requirement or establish the security of the dependency tree.
What data can Sensor export?
The Sensor's documented OTLP exporter applies no redaction or field projection to captured telemetry. Its payload can include prompts, responses, tool arguments, tool results, usernames, hostnames and local paths. Export is disabled by default and requires an explicit configuration file. Before enabling collection or export, decide which records your organization may retain, who can access them and which destination may receive them.
The Sensor README also describes source-specific limits. Claude Code arguments and results have documented truncation, while the Gemini parser adds no redaction or truncation. Normalization therefore does not establish identical capture across agents. Content-free health diagnostics are separate from captured session data, and the documentation warns that a healthy summary does not prove complete capture. Our Detection run did not test these endpoint behaviors.
Did our tests validate detector effectiveness?
Our run did not measure detection precision, recall or false positives. The README's paper results concern a particular evaluation, while our stored parser summary describes test-command output. Treating those as the same evidence would overstate what we tested.
The Detection documentation distinguishes the current task inventory from the paper's evaluation set. It also identifies ALRPHFS and GuardAgent as paper-only results because their implementations were removed for licensing reasons. Before attempting reproduction, check the available conversations, labels and runnable detector. The default ADR path requires hosted-model access and Claude CLI authentication; the documented keyless LlamaFirewall path offers a narrower smoke test, without evidence here that our sandbox executed it.
Which alternative fits application testing?
Garak probes LLM-backed applications for unwanted behavior. Its README describes probes for hallucination, data leakage, prompt injection and other weaknesses. Choose garak when probing an application or model is the immediate task. That role can complement ADR's collection of recorded agent activity; the supplied evidence does not establish equivalent endpoint discovery or telemetry collection.
Promptfoo is a CLI and library for evaluating and red-teaming LLM-based applications. Its README also documents automated CI/CD checks. Choose promptfoo for application evaluations within a development workflow. It can complement ADR telemetry rather than replace the Sensor's collection role. Neither alternative was executed in our ADR sandbox run.
What do the editorial ratings mean?
Setup ease is 2/5 because the measured footprint and documented isolation and authentication requirements demand substantial preparation. These ratings assess the reviewed evidence, not runtime performance or security. The rubric is: 1 means major obstacles, 2 substantial operator work, 3 usable scope with material limits, 4 strong documented support and 5 unusually explicit guidance within the reviewed scope. A dimension without sufficient evidence remains unassessed.
Documentation receives 5/5 for explicit setup, isolation, telemetry and reproduction boundaries, without implying every path was tested. Maturity receives 3/5 for documented public components with material exclusions; Uber's production statement remains vendor evidence. Community is unassessed because the supplied extracts do not establish contributor breadth, maintainer responsiveness or support quality.