Arize AX MCP tracing in Antigravity shifts agent observability

At a glance

What this is: Arize shows how an MCP-based tracing assistant can instrument AI agents inside Antigravity and surface traces without leaving the IDE.

Why it matters: For IAM, NHI, and AI security practitioners, this matters because agent telemetry is becoming part of governance, not just debugging, and traceability is foundational to control.

👉 Read Arize's analysis of MCP tracing for AI agents in Antigravity

Context

AI agent observability is no longer a post-deployment exercise. When instrumentation is embedded inside the same workflow used to build and modify agents, the control gap shifts from missing logs to whether the organisation can trust what the agent was allowed to do. In practice, that becomes an identity and governance question as much as an engineering one, especially where agents invoke tools, access data, or operate with delegated secrets.

MCP is relevant here because it is a standard way to connect an agent to tools and data sources, which means tracing is not just about application telemetry. It also becomes evidence for reviewing which actions were taken, which dependencies were introduced, and whether the agent’s runtime behaviour stayed inside policy. That intersection is especially important for teams governing NHI and agentic AI programmes.

Key questions

Q: How should security teams govern AI agents that can choose tools at runtime?

A: Security teams should govern runtime agent choice as an access event, not as a simple application action. That means scoping permissions to the task, limiting token lifetime, logging every tool decision, and blocking the agent from reaching systems outside its approved context. Static roles alone are not enough when the execution path changes on each run.

Q: Why do AI agents complicate traditional observability and access control models?

A: AI agents can act across tools, data, and code paths in ways that are hard to predict from static role definitions. Traditional controls often assume a stable user or service account, but an agent may change behaviour, invoke new dependencies, and execute tasks dynamically. That makes traceability and least privilege necessary in the same control design.

Q: What do security teams get wrong about AI traceability?

A: They often treat traceability as reporting instead of control. Reporting tells you what was linked in the past, while control ensures the current dependency chain is visible enough to support change review, accountability and rollback decisions.

Q: How should organisations decide whether agent instrumentation is enough for governance?

A: Instrumentation is enough only when it is paired with access limits, approval workflows, and dependency governance. If the agent can reach sensitive systems, modify packages, or operate with broad secrets, then traces are evidence, not control. Governance is working when the organisation can both observe and constrain the agent’s runtime behaviour.

Technical breakdown

MCP tracing as a control plane for agent visibility

MCP lets an agent connect to tools and data through a structured protocol rather than ad hoc integrations. When tracing is attached to that workflow, the organisation gains records of tool calls, dependency changes, and execution steps that would otherwise be hidden inside the IDE or runtime. The important point is that observability here is not only for debugging. It becomes a governance layer that helps security teams understand what the agent touched, what it attempted, and where delegated access was used.

Practical implication: treat MCP tracing as evidence for policy review, not just a developer convenience.

Why instrumentation inside the IDE changes operational risk

Embedding instrumentation guidance directly into the development workflow reduces friction, but it also collapses the distance between code change and telemetry change. That can improve adoption, yet it can also create blind trust if teams assume the presence of traces means the agent is safe. Tracing tells you what happened after the fact; it does not by itself prevent overreach, credential misuse, or unsafe tool access. In identity terms, this is the difference between seeing delegated activity and governing it.

Practical implication: pair tracing with access scope limits and approval rules for the agent’s tool permissions.

OpenTelemetry dependencies reveal the real complexity beneath automation

The article’s dependency conflict example is a useful reminder that agent observability is rarely a one-click exercise in production environments. OpenTelemetry, instrumentors, SDKs, and runtime libraries must align, and each added package expands the operational surface that needs version control and review. For security teams, that means observability pipelines deserve the same discipline as production code. If the tracing stack is loosely governed, it can become another unmanaged dependency chain.

Practical implication: inventory instrumentation libraries and pin them under the same governance as other production dependencies.

Threat narrative

Attacker objective: The objective in this pattern is not direct compromise but unchecked expansion of agent capability and visibility, which can mask unsafe delegated access.

1. Entry occurs when the agent is given runtime access to instrumentation tooling and package dependencies inside the IDE.
2. Escalation happens if the agent can modify dependencies, resolve conflicts, and alter execution paths without a separate control check.
3. Impact is improved visibility, but also a larger governance surface if tracing artifacts are treated as proof of policy compliance rather than evidence to review.

NHI Mgmt Group analysis

Tracing is becoming a governance control for agentic systems, not just an engineering aid. Once AI agents can call tools and mutate workflows, telemetry becomes evidence of delegation, scope, and runtime behaviour. That makes trace data relevant to IAM, PAM, and NHI governance because it helps answer who or what acted, under what permissions, and with what effect. Practitioners should treat observability as part of the identity control stack, not a separate developer utility.

MCP introduces a new form of instrumentation trust boundary. The protocol standardises how agents reach tools and data sources, which means the trace layer now sits between policy intent and runtime execution. If access scopes, tool permissions, and trace collection are not governed together, teams can end up with detailed logs of unsafe behaviour rather than prevention of it. The practitioner lesson is to align MCP adoption with least-privilege design.

Artifact-driven workflows improve transparency, but they can also create false confidence. Plan files, walkthroughs, and debug scripts make the process visible, yet visibility is not the same as control. A trace that proves an agent changed packages or resolved conflicts does not prove the agent stayed within approved boundaries. Security teams should regard these artifacts as review inputs for NHI and AI governance, not as control substitutes.

Observability debt is the named concept this pattern exposes. When AI teams ship agents faster than they instrument them, the organisation accumulates a backlog of unseen runtime behaviour, unresolved dependency chains, and undocumented tool use. That debt lands on IAM and security teams when they are asked to explain agent actions after the fact. The practical conclusion is to make instrumentation mandatory at the point of agent introduction, not after deployment.

What this signals

Observability debt: the issue is not whether teams can instrument an AI agent, but whether they can maintain traceability as agents accumulate tools, dependencies, and delegated access. The programme risk is that security teams inherit a visible but poorly governed runtime, which is harder to defend than an invisible one. For governance teams, the immediate priority is to connect tracing to identity controls and review workflows rather than treating it as a developer-only concern.

MCP-based integrations will likely push more organisations to formalise how agent-to-tool connections are approved, logged, and reviewed. That will matter for NHI programmes because the agent’s effective identity is increasingly defined by what it can reach at runtime. For a broader control view, align the operating model with the OWASP Top 10 for Agentic Applications 2026 and use it to pressure-test tool-use boundaries.

For practitioners

• Define traceability requirements for every production agent Require trace capture for tool calls, package changes, and external data access before an agent is approved for production use. Tie the requirement to the agent’s identity, the secrets it can reach, and the systems it can invoke.
• Govern instrumentation dependencies as production assets Track OpenTelemetry libraries, instrumentors, and agent SDKs in the same change-control process as application code. Pin versions, review upgrade paths, and record which tracing components are allowed to handle runtime data.
• Pair observability with least-privilege for agents Do not use tracing as a substitute for access control. Limit the agent’s tool permissions, scope the secrets it can use, and require review when tracing reveals behaviour outside the approved task boundary.
• Use trace artifacts for post-run review and exception handling Store implementation plans, walkthroughs, and debug outputs as reviewable evidence for security and platform teams. Use them to identify when an agent resolved conflicts, added dependencies, or expanded its runtime reach.

Key takeaways

• AI agent observability is becoming a governance requirement because traceability now sits inside the control path for delegated actions.
• Instrumentation helps teams see agent behaviour, but it does not replace least privilege, approval workflows, or dependency governance.
• As agent adoption accelerates, organisations that cannot audit tool use and package changes will accumulate observability debt faster than they can contain it.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• AI Traceability: AI traceability is the ability to reconstruct how a model output was produced by linking data sources, prompts, model versions and deployment context. It turns AI operation into an auditable evidence chain rather than a set of disconnected technical events.
• 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.
• Tool Permission Scoping: The practice of limiting what a non-human identity can do with each tool, including which data sources it can reach and which actions it can trigger. Strong scoping is a core control for agent governance because it reduces overreach, improves auditability, and supports revocation.

What's in the full article

Arize's full article covers the implementation detail this post intentionally leaves at the governance layer:

• The exact Antigravity workflow used to add the Arize AX MCP server and trigger instrumentation from inside the IDE.
• The dependency-resolution steps for OpenTelemetry conflicts, including package upgrades and compatibility fixes.
• The final verification walkthrough used to confirm traces were flowing to Arize AX.
• The specific artifacts generated during the process, including plans, task notes, and debug scripts.

👉 Arize's full post covers the instrumentation workflow, dependency resolution, and trace verification details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, and secrets management. It helps practitioners align identity controls with the realities of delegated access across modern AI and automation programmes.