VisorBishop iter-4: Adjacent platforms (Opik, AgentOps, Phospho)

NuClide Research · 2026-05-11

Summary

Fourth iteration of the Phase 3 loop. iter-1/2/3 expanded the IP-direct-shadow port set; iter-4 expands platform coverage, adding fingerprints for three platforms not in Phase 1’s original sweep:

DCWF KSAT coverage

Auto-derived from DCWF AI work-role rule files (ksat-tag).

• 672 (AI Test & Evaluation Specialist): K7003, K7004, K7044, S7068, S7070, S7075, T5858, T5904, T5919
• 733 (AI Risk & Ethics Specialist): T5868, T5893
• overlap (Common AI KSATs (all 5 roles)): K1158, K1159, K22, K6311, K6935, K7003, K942

• Comet ML Opik: Dropwizard-based observability + experiment tracking
• AgentOps: agent-monitoring with Langfuse-as-trace-store pattern
• Phospho: open-source LLM analytics

VisorBishop v0.1.4 adds opik.go and agentops.go probers. Phospho’s self-hosted population was too small to merit a dedicated prober (see negative-result section below).

Reproduce with VisorBishop ≥ v0.1.4: visorbishop -i hosts.txt -ip-shadow

Headline findings:

1. agenticorc.com runs AgentOps + Langfuse on linked AWS hosts, surfaced via a single AgentOps /api/health probe that discloses the backing Langfuse host (https://107-21-194-219.sslip.io, Langfuse v3.160.0).
2. Opik self-hosted population is tiny (1 of 21 cert-CN-matched hosts is real Opik). The 20 others are unrelated .opik.net domains (public-domain name collision).
3. Phospho has 0 confirmed self-hosted instances, the 16 Shodan-derived candidates are all biotech/biochem sites (affbiotech, sabbiotech, kendallscientific, etc.) where “phospho” appears as a chemistry term, not a platform identifier.

Population summary

Total iter-4 new confirmed-platform yield: 3 instances (1 Opik + 2 AgentOps).

The low confirmation rates reflect the name-collision noise problem already documented in Phase 1 (“Phoenix AZ businesses” pattern). Generic terms in HTML or TLS certs saturate dorks; only API-shape probing disambiguates real platform instances from name-collision noise.

Critical finding: AgentOps /api/health discloses backing Langfuse

Host: 54.197.255.244 (controlplane.agenticorc.com, AWS US-East-1) Platform: AgentOps self-hosted Disclosure: Backing Langfuse host URL via unauthenticated /api/health

$ curl -sk https://54.197.255.244/api/health
{"status":"ok","langfuse_host":"https://107-21-194-219.sslip.io"}

$ curl -sk https://107-21-194-219.sslip.io/api/public/health
{"status":"OK","version":"3.160.0"}

The AgentOps health endpoint discloses the Langfuse instance that AgentOps uses as its backing trace store. The Langfuse instance is itself properly auth-fronted on protected endpoints (Phase 1 pattern: 0% unauth across the Langfuse population), so direct exploitation requires credentials. But the discovery is gratis: any external party can map the AgentOps→Langfuse architecture without authentication.

This is the AgentOps analogue of LangSmith’s /api/v1/info customer disclosure finding. Both are “unauthenticated info-disclosure endpoints reveal more than just version strings. They reveal architectural/customer context that becomes load-bearing for targeted attacks.”

The operator (agenticorc.com) appears to be an AI agent orchestration SaaS. controlplane.agenticorc.com for AgentOps control plane, lf.agenticorc.com and 107-21-194-219.sslip.io for their Langfuse backing store. Cross-platform attribution comes free with the disclosure.

Phase 2 deep-dive on AgentOps would extend this. The source-level audit for the /api/health shape, the population-level probe of whether other AgentOps operators also disclose their backing infrastructure. Queued for iter-5.

Opik: tiny self-host population, well-defended where it exists

ssl.cert.subject.cn:"opik" returns 21 hits. After probing each:

opik.tilla.ai posture:

• /api/is-alive/ping → 200, healthy response (intentionally public per Opik docs)
• /api/is-alive/ver, /api/openapi.json, /swagger, /api/v1/private/* → 403 Forbidden (Cloudflare WAF blocks)
• All sensitive surfaces are behind both auth AND a WAF layer

This is the inverse-Phoenix pattern: Opik self-hosters are highly defensive operators. The product has a small self-hosted population (SaaS-first, similar to Helicone), but the operators that do self-host tend to invest in proper WAF + auth fronting.

Phospho: 0 confirmed self-hosted instances

All 16 Shodan hits on http.html:"phospho" are biotech/biochemistry domain sites. affbiotech.cn, sabbiotech.com, kendallscientific.com, bioworlde.com.cn, antibodydirectory.com, and similar. Where “phospho” appears as a chemistry term (phosphorylation, phospho-signaling, etc.).

One borderline case: 43.156.0.132:3000 returns a NextAuth.js-style 307 → /en/auth/login on /health, suggesting a real AI/observability SaaS, but the /api/v2/health route doesn’t return a Phospho-shaped response. Could be a different LLM-related product using the same NextAuth.js patterns. Not Phospho.

Phospho’s GitHub population is small (mostly hosted at phospho.ai SaaS); self-hosting isn’t a primary deployment mode. Negative result ruled in, no public-internet Phospho self-host population at population scale on 2026-05-11.

Methodological refinement: probe at multiple confidence layers

iter-4 reinforces a pattern from earlier iters: Shodan dorks surface candidates; API-shape probing confirms. The confidence layers are:

The dork-only confidence is consistently 5-30% real-platform rate at population scale. Real iteration needs the API-shape probe to be useful.

VisorBishop bakes this in: every Prober.Probe implementation requires the platform-specific endpoint to respond with the correct shape before flagging Confirmed: true. The Shodan hit is just the seed. The prober is the disambiguator.

This is candidate for Methodology Insight #15: Dork hits ≠ platform instances. Always probe the platform-specific API shape before treating a host as a real instance. Confirmation rate < 30% at population scale is typical for generic dorks.

Cross-platform attribution emerging

After iter-3 (Rogers’ Phoenix + Qdrant on same host) and iter-4 (agenticorc’s AgentOps + Langfuse on linked hosts), a pattern is visible:

The class pattern: AI infrastructure operators co-locate multiple platforms either on the same host or on linked hosts where one discloses the others. VisorBishop’s value here isn’t just per-platform fingerprinting. It’s the multi-platform cross-correlation that emerges from running all probers on all hosts and surfacing the linkage.

Phase 4 (web UI) should visualize this. Operators-running-multiple- platforms is the threat-graph natural unit.

Performance

iter-4 sweeps:

• Opik: 21 hosts × 3 probe round trips (/api/is-alive/ping, optional /api/is-alive/ver, /api/v1/private/projects) → 22.5s
• Phospho: 16 hosts × 1 probe → 33.5s (slower due to many slow biotech sites)
• AgentOps: 18 hosts × 2 probes → 45.6s (some slow hosts)

All within iteration-cadence budget. VisorBishop v0.1.4 builds clean and runs against the existing iter-3 corpora without regression (verified via local smoke tests).

Next steps

1. iter-1: extended dev-tooling ports ✓
2. iter-2: message-broker ports (zero-yield, refined methodology) ✓
3. iter-3: AI-stack pipeline ports + Rogers find ✓
4. iter-4: adjacent platforms (Opik, AgentOps, Phospho) ✓ (this document)
5. Methodology Insight #15 writeup. “Dork hits ≠ platform instances” + the confirmation-rate-at-population-scale pattern
6. iter-5 candidates: Argilla, Promptfoo, LiteLLM Proxy (different category, gateway not observability, but adjacent), Trulens, Inspekt-ML, LangChain Hub self-host
7. Phase 4 (web UI) for VisorBishop with multi-platform cross-attribution visualization

Evidence pack

~/recon/2026-05-10-llm-sweep/visorbishop-results/iter4/

• opik-noshadow.json / .csv. Opik 21-host iter-4 sweep
• agentops-noshadow.json / .csv. AgentOps 18-host iter-4 sweep
• phospho-noshadow.json / .csv. Phospho 16-host iter-4 sweep
• opik-shadow.json, agentops-shadow.json. IP-shadow on confirmed instances
• agenticorc-lf-shadow.json: IP-shadow on the agenticorc-disclosed Langfuse host

Source: Nicholas-Kloster/VisorBishop@v0.1.4

Cross-references:

• iter-3 case study
• LangSmith deep-dive (similar info-disclosure pattern)
• Phase 3 case study
• Methodology Insight #12