Operational observability for AI agents changes production governance

At a glance

What this is: This is an analysis of how AWS Bedrock AgentCore Runtime and Arize AX change the production operating model for AI agents by pairing managed runtime infrastructure with end-to-end observability.

Why it matters: It matters because AI agents increasingly behave like governed systems with tool access, runtime decisions, and secret-bearing integrations that security, IAM, and AI governance teams must be able to trace and control.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.

👉 Read Arize's walkthrough of production observability for AI agents on AWS Bedrock AgentCore

Context

AI agent observability is the governance problem that emerges when autonomous software can call tools, handle secrets, and make runtime decisions faster than teams can inspect those actions. In production, the issue is not whether the model works in a notebook, but whether engineers, IAM teams, and security operations can reconstruct what the agent did, what it accessed, and why it behaved that way.

The article positions observability as the missing layer between agent runtime and operational trust. That is relevant for identity programmes because agents that authenticate with IAM roles, call external tools, and interact with data sources create an access trail that must be monitored like any other privileged workload.

This starting position is now typical for teams moving from prototype to production, but it becomes atypical once agents are allowed to handle sensitive workflows without traceable controls.

Key questions

Q: How should security teams govern AI tools that can act with privileged cloud roles?

A: Security teams should govern AI tools as privileged identity paths, not as harmless application components. That means binding each tool to a task-scoped execution role, tightly controlling who can invoke it, and logging invocation activity as a high-risk event. If a tool can execute actions in a role’s context, it belongs in IAM and PAM review cycles.

Q: Why do AI agents complicate traditional access reviews?

A: AI agents complicate access reviews because they can accumulate permissions across tools and environments faster than manual certification cycles can observe. A review process built for stable human accounts does not fit an executor that can act across systems, create new access paths, and complete work before the next review window begins.

Q: What do security teams get wrong about runtime policy for agents?

A: They often assume runtime policy alone is enough. In practice, inline enforcement can block unsafe requests, but it does not discover shadow NHIs, clean up stale credentials, or fix lifecycle ownership gaps. Mature programmes need both request-time control and estate-wide visibility so governance and enforcement reinforce each other.

Q: Who should own AI agent governance in an enterprise identity programme?

A: Ownership should sit with identity and security teams, not with model governance alone, because the operational risk comes from credentials, privilege, and runtime enforcement. The accountable team must be able to see the agent identity, scope its access, and retire it when the workflow changes.

Technical breakdown

Why agent observability matters more in production than in notebooks

A notebook proves that an agent can complete a task in a controlled setting, but production introduces variable prompts, tool latency, retries, and failure states. Observability captures spans, tool calls, model interactions, and timing so teams can reconstruct the full execution path. Without that trace layer, root-cause analysis becomes guesswork and policy enforcement becomes reactive. For identity teams, this matters because agent actions are often mediated by IAM roles, secrets, and external APIs, which means the audit trail must include both behaviour and authorisation context.

Practical implication: instrument agents with trace data rich enough to support access review, incident investigation, and runtime governance.

OpenTelemetry and OpenInference as the control plane for agent telemetry

OpenTelemetry provides a standard way to collect traces across applications, while OpenInference adds a semantic structure tailored to AI systems. That combination matters because agent frameworks differ, but security and governance teams need consistent event models for prompts, tool usage, model calls, and outputs. The article shows a conversion layer that normalises framework-specific spans before export. This is an identity-relevant pattern because consistent telemetry is what makes it possible to correlate privileged actions, data access, and downstream effects across platforms.

Practical implication: standardise agent telemetry early so audit evidence remains portable across frameworks and cloud services.

Managed runtime and secret-bearing workloads need separate governance

AgentCore Runtime removes much of the infrastructure work by handling containers, scaling, and deployment, but that does not remove governance responsibility. Once an agent can call tools and access external services, the runtime becomes a privileged workload that needs authenticated endpoints, scoped permissions, and controlled secret handling. The article’s production pattern shows that observability and runtime management are complementary, not interchangeable. The security lesson is that managed infrastructure can simplify operations while still leaving the core identity and access questions unresolved.

Practical implication: treat AI agents as privileged workloads and apply access scoping, secret minimisation, and traceable runtime controls.

Threat narrative

Attacker objective: The objective is to gain or abuse agent-mediated access paths so actions, data retrieval, or credential use happen outside meaningful human visibility.

1. Entry occurs when an AI agent is given runtime access to tools, web search, and cloud services through production infrastructure and managed credentials.
2. Escalation happens if the agent can invoke external systems, reach sensitive data sources, or reuse secrets without granular constraints on each action.
3. Impact appears as uncontrolled data exposure, opaque tool use, or unreviewable decisions that security teams cannot reconstruct after the fact.

NHI Mgmt Group analysis

Observability is becoming an identity governance control, not just an engineering convenience. When AI agents can call tools, retrieve data, and execute actions in production, traceability becomes part of authorisation. The article shows a runtime pattern where OpenTelemetry and OpenInference turn execution into evidence. That aligns with broader NHI governance because an agent is effectively a non-human workload identity with behavioural drift potential. Practitioners should treat trace completeness as a prerequisite for trust.

Managed runtime reduces operational friction, but it does not solve privilege design. AgentCore-style infrastructure can scale execution, but scaling does not equal governance. The real question is whether the agent’s IAM role, tool permissions, and data reach are tightly bounded to task scope. Without those controls, production convenience can expand blast radius faster than teams can review it. Practitioners should re-evaluate whether runtime simplification is masking access overreach.

Production AI systems now create an auditability gap that looks like a governance debt problem. The more agents rely on external tools, the more their behaviour depends on systems that must be logged, correlated, and retained. AI observability debt: the growing mismatch between how much an agent can do and how little of that action chain is retained in a form usable for security, compliance, or incident response. Practitioners should close the gap before agents become business-critical.

Identity-aware observability will become a baseline requirement for agentic AI programmes. Security teams already know that machine identities need lifecycle control, but agents introduce decision paths that are harder to reconstruct than static service accounts. That makes telemetry, secret use, and role assumption part of the same governance model. Practitioners should expect AI operations and IAM teams to share responsibility for evidence, not just availability.

What this signals

Agent observability is now part of the identity control stack because every tool call, delegated action, and model output becomes audit evidence. Teams that cannot trace agent behaviour will struggle to prove least privilege, especially when agents touch secrets, external APIs, or regulated data. For a useful framework on this shift, see the Ultimate Guide to NHIs , 2025 Outlook and Predictions and the NIST AI Risk Management Framework.

AI observability debt: the gap between what an agent can do and what the organisation can later explain is becoming a programme-level risk. Security leaders should expect more pressure to correlate telemetry, IAM logs, and evaluation data across the full lifecycle of agent deployment.

The operational signal is clear: if the agent cannot be observed, it cannot be governed with confidence. That means observability standards, not just model quality, should shape approval gates for production deployment.

For practitioners

• Instrument agent traces end to end Capture prompts, tool calls, model outputs, and latency in a single trace model so investigators can reconstruct every decision chain. Make trace retention long enough to support incident review and access audits, not just engineering troubleshooting.
• Scope IAM roles to task-level access Assign each agent the smallest practical role for the exact tools and data sources it needs, then separate read-only and write-capable actions where possible. Review role assumptions as part of change management, especially when new tools are added.
• Minimise secrets exposed to agents Avoid persistent credentials in agent runtime where short-lived tokens or delegated access can be used instead. Track which secrets each agent can retrieve, and revoke anything that is not directly required for the current workflow.
• Correlate observability with access reviews Use trace data alongside identity logs to verify whether the agent only touched approved systems and whether its behaviour matched policy. Feed repeated exceptions back into IAM, PAM, and AI governance reviews.
• Test failure and abuse paths before production rollout Replay failed requests, simulate tool errors, and inspect how the agent behaves when prompts, permissions, or data inputs change. Validate that the control plane still exposes enough evidence for containment and post-incident analysis.

Key takeaways

• AI agents create a governance problem when runtime decisions, tool calls, and secret use outpace the visibility teams need to control them.
• Production-grade observability turns agent behaviour into evidence, which is essential for identity review, incident analysis, and policy enforcement.
• Security teams should pair managed runtimes with task-scoped access, trace retention, and identity-aware monitoring before expanding agent use.

Key terms

• AI Agent Observability: AI agent observability is the practice of tracking what an agent does across systems, including actions, permissions, and data access. It provides visibility into behaviour, but it does not by itself establish what the agent was authorised to do or when access should be revoked.
• OpenInference: A set of OpenTelemetry semantic conventions for AI workloads. It standardises how agent activity, tool calls, model steps, and latency are recorded so different evaluation and observability tools can read the same trace data.
• Task-Scoped Identity Boundary: A control boundary that links access, execution, and evidence to one defined task rather than to a persistent user or machine profile. This matters for agentic delivery because the trust model should end when the task ends, not when a person logs out.
• Observability debt: Observability debt is the accumulated inability to explain system behaviour because logging, tracing, and evidence capture were left too shallow for the risks in play. In MCP and agentic systems, it shows up when investigators can see that a tool was used but not what happened next.

What's in the full article

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

• Step-by-step notebook code for wiring OpenTelemetry into a Strands-based agent and exporting traces to Arize AX
• AgentCore Runtime configuration details for container creation, ECR setup, autoscaling, and IAM role provisioning
• The exact environment variables and launch parameters used to redirect observability data to Arize AX
• Trace view and agent graph workflows that show how to inspect tool calls, latency, cost, and failure patterns

👉 Arize's full article covers the deployment notebook, telemetry wiring, and trace inspection workflow.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to emerging autonomous workloads and production AI systems.