Direct answer
Instrument coding-agent workflows with correlated task, model-request, tool, repository-change, and verification events. Record identities, timing, status, policy decisions, sanitized error classes, and artifact references; keep raw prompts, code, secrets, and tool payloads out of ordinary telemetry unless a reviewed policy explicitly permits protected capture.
Key takeaways
- Trace the workflow and its controlled actions, not hidden model reasoning.
- Use stable task and trace correlation across client, gateway, tools, and verification.
- Store sanitized metadata and protected artifact references instead of raw sensitive payloads.
- Define retention, access, deletion, incident, and sampling policy before collection.
Key facts
| Fact | Verified value | Evidence |
|---|---|---|
| Telemetry model | OpenTelemetry defines traces, metrics, logs, resources, and shared semantic conventions. | View source |
| Cross-service correlation | W3C Trace Context defines interoperable trace identifiers and propagation fields. | View source |
| Logging controls | OWASP recommends purpose limitation, sanitization, access control, and protection against logging sensitive data. | View source |
| Tool protocol | MCP provides identifiable tool request and result boundaries that can be observed without assuming tool internals. | View source |
What this guide helps you solve
Help platform and engineering teams diagnose agent workflows while preserving privacy and security boundaries.
Verification scope and limits
- Evidence basis
- SpecificationOfficial documentation
- Verification scope
- The model applies standard trace and logging concepts to coding-agent tasks, model calls, tools, repository changes, and checks.
- Limits and invalidation conditions
- - No universal semantic convention for every coding agent is asserted.
- - Telemetry fields depend on client and gateway support.
- - Privacy and retention requirements vary by jurisdiction and organization.
Start with operational questions, not maximum collection
Define the questions telemetry must answer: Which task and repository revision ran? Which policy and route were effective? What tools were invoked? What files changed? Which acceptance checks passed? Where did timeouts or retries occur? Who approved a privileged action?
If a field does not support a documented operational, security, billing, or reliability purpose, do not collect it by default.
Use a layered event model
Represent the task as the root operation, with child spans or events for context loading, model requests, tool calls, command execution, file-change summaries, human approvals, and verification. Record timestamps, status, error class, attempt number, effective policy, and references to protected artifacts.
Do not label model-generated explanations as ground truth. Observed command results and repository diffs remain separate evidence types.
Establish a privacy and secret boundary
Default-deny raw prompts, completions, source contents, environment variables, authorization headers, and tool payloads. Apply structured allowlists, field-level redaction, encryption, access control, and short retention. Test redaction against nested errors and streaming fragments, not only normal responses.
Build alerts from boundary failures
Useful signals include denied-path attempts, unapproved destinations, secret-scanner findings, repeated tool failures, retry storms, context growth, fallback changes, missing terminal stream events, and final checks that never ran. Tune alerts by task class and preserve the underlying sanitized trace for investigation.
Validate the telemetry pipeline itself
Use synthetic tasks to verify propagation, missing-span detection, clock handling, sampling, redaction, retention deletion, and access controls. Confirm that telemetry failure does not silently disable security enforcement and that an observability outage cannot block emergency revocation or rollback.
Official sources and verification scope
This guide is based on public official documentation. Commands and configuration may change between client versions, so verify the linked sources before use.
Read the verification methodology