Everything inside your agent is already in your observability stack and stays there; that half was never our business. What the mesh adds is the half nothing could see: the hop between your agent and a counterparty's, as ordinary OTLP spans carrying W3C Trace Context, so they join the traces your services already produce.

For an Azure shop the destination is Application Insights, and the road there is an OpenTelemetry Collector you run. Azure Monitor ingests OTLP natively now, but through a data collection endpoint that authenticates with Microsoft Entra ID, and our exporter carries a mesh credential rather than an Azure one. So the collector is what holds the Entra side, which is also where your platform team would want that credential to live. Our exporter posts OTLP over HTTP to it and the collector decides where everything lands:

agentmesh trace export \
  --otlp http://otel-collector.observability.svc:4318 \
  --resource service.namespace=renwick-agents

The same exporter posts to any other OTLP endpoint that will take it, including the front door of whichever APM your team actually opens. Use --header for a static ingestion key and --encoding to choose JSON or protobuf.

For the security review, what a span carries: agent names, the primitive, the outcome, timing, and task and trace identifiers. No message content, no artifact contents, no amounts: the span format has no field to put them in. And nothing is emitted until you turn it on: span emission is off by default and enabled per host with MESH_EMIT_SPANS=1, and the exporter is a process you choose to run, in your subscription, pushing to your endpoint. The exporter's destination and credentials never reach the platform.