Phoenix — agentic threat model

Not certain from the listing — Phoenix is model-agnostic and does not ship with its own foundation model, but it uses LLMs for evaluation. Threats include adversarial inputs bypassing evaluation prompts or poisoning the evaluation LLM's outputs.

Phoenix ingests and stores trace data, spans, and evaluation datasets. The primary threat is data exfiltration of sensitive prompt/response payloads containing PII or proprietary data stored within the tracing backend.

Not certain from the listing — Phoenix is an observability tool rather than an agent framework, but it integrates with frameworks like LangChain and LlamaIndex. Threats include insecure integration where tracing instrumentation leaks internal framework states.

Phoenix runs locally or can be self-hosted. A major threat is exposed service ports (e.g., the default visualization UI port) without proper network segmentation or host-level access controls, leading to unauthorized trace access.

This is Phoenix's primary domain. Threats include evaluation gaming, where developers or malicious actors manipulate prompts to pass Phoenix's evaluation metrics, or blind spots in span-level visibility that fail to capture malicious agent actions.

Not certain from the listing — As an open-source tool designed for local troubleshooting, it may lack robust built-in authentication, role-based access control (RBAC), and audit logging out of the box, requiring external security wrappers.

Not certain from the listing — Phoenix does not operate as an active agent in an ecosystem, but it is used to monitor multi-agent systems. Threats are limited to tracing pipeline failures when handling complex, recursive multi-agent interactions.