The Pipeline
Every MCP request passes through Ultra’s observability layers before reaching the upstream connector. Responses pass back through the same layers:
The audit layer is the only one that will block a successful operation if it can’t record — guaranteeing every completed MCP call has a corresponding audit record. The others absorb errors silently so observability never breaks your workflow.
Enforcement runs in this same pipeline. When a device has local storage, governance and guardrail interceptors are appended after the observability layers, so a blocked request is still traced and audited before it is stopped. See Guardrails and Governance.
Where Data Lives
Observability data is stored locally on your device by default. Trace records, audit events, and metrics all live on-device unless you enable Hub sync or OTLP export.Viewing Data
Hub Sync
When connected to Ultra Hub, traces and audit events are automatically synced to the cloud for team-wide visibility. Local storage is always maintained regardless of Hub connectivity.What Gets Recorded
MCP Operations
For Every Operation
- Trace ID and Span ID — OpenTelemetry-compatible identifiers for distributed tracing
- Upstream connector — Which connector handled the request
- Tool/resource/prompt name — What was called
- Request payload — The arguments sent
- Response payload — The result returned
- Duration — How long the operation took
- Status — Success or error
- User — User identity (when connected to Ultra Hub)
- Principal — The MCP agent identity
- Agent context — Which MCP agent made the call, and its version
- Connector context — Transport, process, and authentication method of the upstream connector
Next Steps
Traces
Understand trace record structure
Audit Log
Security audit events
Dashboard
View data in the web dashboard
Alerts
Prioritized feed of high-signal security events
Anomaly Detection
AI-driven analysis of MCP traffic
OTLP Export
Export to Jaeger, Grafana, or Datadog
SIEM Export (Panther)
Send alerts to Panther through S3