AI observability for agent workflows now depends on local-first control

At a glance

What this is: Arize’s Phoenix story shows how an open-source AI observability project scaled by meeting developers where they work and by adopting OpenTelemetry, OpenInference, and local-first deployment.

Why it matters: For IAM and security teams, the important signal is that agent workflows and telemetry now intersect with access control, authentication, and auditable change boundaries in AI systems.

👉 Read Arize's story of Phoenix’s growth, OpenTelemetry adoption, and AI observability evolution

Context

AI observability starts with the simple problem of seeing what an application is doing, but it quickly becomes a governance issue when traces, prompts, and outputs can include sensitive data. Phoenix is relevant because it moved from notebook-level inspection toward broader observability and, in doing so, exposed the need for transport standards, local execution, authentication, and reviewable workflows.

The primary identity angle is not human authentication alone, but the control plane around developer tools and agent workflows. As AI systems become more operational, the question shifts from whether teams can collect telemetry to whether they can do so without widening access, leaking secrets, or creating unreviewable automation paths.

That makes Phoenix a typical example of the current AI tooling transition: useful, developer-led, and increasingly entangled with identity, permissions, and governance decisions.

Key questions

Q: How should security teams govern AI observability in enterprise environments?

A: Security teams should treat AI observability as a governance control, not a monitoring add-on. Focus on identity attribution, data lineage, output quality, and policy evidence so every meaningful AI action can be traced back to an owner, a model version, and an access decision. That makes investigations, reviews, and accountability possible.

Q: Why do conversational AI systems create new identity and access risks?

A: Because they can combine data retrieval, decision-making, and execution in a single interaction. That collapses the gap between information access and business action, which traditional IAM and security tools were not built to manage. The result is higher exposure when the system can modify records or disclose sensitive guest data.

Q: What do teams get wrong about OpenTelemetry in AI systems?

A: Teams often assume standardised telemetry is automatically safe because it improves interoperability. In practice, standardisation can widen exposure if sensitive AI traces are broadly readable or exported into multiple backends. The control question is whether access policies, classification, and retention rules were defined before instrumentation was scaled.

Q: How should organisations review human and agent permissions in AI pipelines?

A: Use the same governance logic for humans and non-human actors: explicit ownership, least privilege, and periodic access review. For agents, add approval boundaries, short-lived credentials, and a clear audit trail for each delegated action. If a workflow can change code, retrain a model, or move data, it should have tightly scoped identity and documented accountability.

Technical breakdown

Why local-first observability changes the data-governance model

Local-first observability keeps traces, prompts, embeddings, and evaluations inside the operator’s environment instead of shipping them to a central service. That matters because AI telemetry often contains code fragments, private business context, and model outputs that can be sensitive even when the underlying application is not. A local model also changes the trust boundary: the user machine or internal container becomes part of the security perimeter, so authentication, storage, and access review have to extend to developer workstations and internal tooling as well as production services.

Practical implication: treat local observability stacks as governed data-processing systems, not just developer utilities.

How OpenTelemetry and semantic conventions affect AI identity and access control

OpenTelemetry gives AI systems a common transport and schema layer for traces, metrics, and logs, while semantic conventions like OpenInference define how AI-specific events are represented. That is useful because standardisation makes AI activity easier to inspect across frameworks and languages, but it also means more systems can ingest the same telemetry. If permissions are weak, the standardisation that improves portability can also widen exposure by making sensitive data easier to move, aggregate, and reuse across tools.

Practical implication: align telemetry schemas with least-privilege access and data classification before scaling instrumentation.

Why agent workflows turn observability into an authorization problem

Agent workflows change observability from passive inspection into active governance. When an agent can propose code changes, trigger evaluations, or operate in its own sandbox, the question is not only what the system did, but who or what was allowed to do it, under which identity, and with what audit trail. That is an IAM and NHI issue as much as an AI engineering issue because agents, service accounts, API tokens, and CI identities become the actors that need bounded authority and revocable access.

Practical implication: tie agent execution paths to explicit identities, scoped tokens, and auditable approval boundaries.

Threat narrative

Attacker objective: The attacker’s objective is to harvest sensitive AI telemetry or leverage weakly governed agent workflows to expand access and hide activity.

1. Entry occurs when developers or agents work in notebook, container, or local environments that can expose telemetry and credentials if controls are not segmented.
2. Escalation happens when the same observability stack is used across frameworks and deployment environments without tight authorization around traces, logs, and evaluation data.
3. Impact is the loss of confidentiality and governance over sensitive prompts, code context, and agent behaviour, which can also create unreviewable change paths.

NHI Mgmt Group analysis

AI observability is becoming an identity governance problem, not just an engineering concern. Phoenix’s evolution shows that telemetry, evaluation, and developer workflow tooling now carry sensitive data and delegated action paths. Once an AI platform can observe, execute, and review across environments, the question becomes who or what is authorised to see, change, and retain those records. Practitioners should treat AI observability as part of the access model, not as a separate engineering layer.

Local-first architecture creates a narrower vendor risk but a broader operator responsibility. Running observability on the customer side reduces dependency on a central SaaS control plane, but it shifts security obligations to local storage, workstation controls, and internal permissioning. That means identity lifecycle, token handling, and audit retention must be designed for distributed deployment. For teams managing AI tools alongside IAM, the lesson is that locality is not the same as governance.

Open standards reduce integration friction, but they also standardise exposure if access rules are weak. OpenTelemetry and OpenInference make AI activity easier to move between tools, languages, and backends. That portability is valuable, yet it also means any control failure can propagate faster across the stack. The named concept here is observability portability risk: the more reusable the telemetry model, the more important it is to apply consistent access controls and data minimisation. Practitioners should standardise governance as aggressively as they standardise instrumentation.

Agent workflows collapse the separation between monitoring and execution. The article’s future-facing section is the real signal for the market: observability tools are now expected to inspect coding agents, human-in-the-loop approvals, and autonomous changes in the same environment. That places AI agents, service identities, and developer permissions inside one governance surface. Teams should assume that the next control failure will involve delegated action, not just data collection.

The market is moving toward evidence-based AI operations, and identity teams should be part of that operating model. The combination of authentication support, local execution, and reviewable telemetry points to a future where AI system trust depends on traceable identities and scoped access. That makes IAM, PAM, and NHI governance relevant to AI engineering programmes even when the product story is framed as observability. Practitioners should embed identity controls into AI operations early, before agent workflows become the default path.

What this signals

The next phase of AI observability will be judged less by feature depth and more by whether it respects data boundaries. Teams should expect scrutiny around where traces live, who can export them, and how agent activity is attributed when multiple identities are involved.

Observability portability risk: as AI telemetry becomes easier to move across frameworks and backends, governance must become portable too. That means the same access model, review cadence, and retention policy should follow the data wherever instrumentation is deployed.

For practitioners

• Classify AI telemetry as sensitive operational data Map traces, prompts, embeddings, and evaluation outputs to data classes and define who can view, export, or retain them. Apply tighter controls to local databases, notebooks, and developer sandboxes than you would to ordinary metrics streams.
• Bind agent execution to explicit identities Require each agent, CI job, or evaluation workflow to use a scoped identity with revocable credentials, separate from human developer accounts. Log approval steps and execution context so delegated actions remain attributable.
• Review authentication paths in developer tooling Audit OIDC, Keycloak, Cognito, and other authentication integrations used by observability tools. Confirm that access is constrained by role, environment, and data sensitivity, not just by repository membership.
• Standardise governance across telemetry backends Apply the same access review, retention, and export rules to every backend that can receive observability data, including local SQLite, Postgres, Elasticsearch, and internal logging platforms.

Key takeaways

• Phoenix’s growth illustrates that AI observability is now inseparable from governance over telemetry, identity, and delegated execution.
• Open standards and local-first design improve portability and privacy, but they also demand tighter controls over access, retention, and auditability.
• As agents become part of the development workflow, IAM, PAM, and NHI controls must extend into AI engineering before the control gap widens.

Key terms

• AI observability: AI observability is the ability to see how AI systems are being used, what information they process, and what actions they trigger. In security programmes, it extends beyond uptime or model quality to runtime visibility, policy enforcement, and audit evidence across human and agent-driven use cases.
• OpenTelemetry: An open standard for collecting and moving traces, metrics, and logs in a consistent format. It helps teams avoid re-instrumenting every system when tools change, and it supports cross-platform analysis by keeping telemetry structured and portable.
• Agent Workflow: An agent workflow is a machine-driven sequence where an AI system can call tools, access data, and continue execution with limited human involvement. These workflows need governance that sees API activity and tool use, not just browser sessions or user clicks.
• Local-First Architecture: Local-first architecture keeps processing and storage on the user’s device or inside the operator’s own environment rather than forcing data into a central cloud service. It can reduce external exposure, but it also shifts responsibility for endpoint security, retention, and access governance to the organisation.

What's in the full article

Arize's full article covers the implementation detail this post intentionally leaves for the source:

• The maintainers’ discussion of why Phoenix moved from notebook extension to containerised deployment before building a database layer
• The practical reasoning behind OIDC support and community-driven authentication requests such as Keycloak and Cognito
• The internal debate that led to OpenTelemetry adoption and the creation of OpenInference semantic conventions
• The team’s forward-looking view of agent workflows, including human review patterns and sandboxed coding-agent observability

👉 Arize's full article covers the maintainer interviews, platform evolution, and agent workflow plans in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and agentic AI identity. It helps practitioners connect identity controls to the operational realities of modern security and AI programmes.