Agent observability: useful evidence without exposing sensitive context

A trace, the chain of events in an execution, can help an investigation while also creating a second copy of information that should not circulate. The architecture question is which evidence is needed to explain a decision, who needs access and for how long. Capturing everything and deciding later transfers the problem to storage and the people receiving the material.

This article proposes an observability contract for agent systems. It does not describe a mechanism already operating across all Trustyu products, nor present client results or a certified implementation. The contract must be adapted to the organization’s risk, domain and obligations.

Start with the investigation questions

A team must be able to establish which objective was authorized, which system version ran, which tools could act, how the outcome was verified and which effects occurred. In many workflows, identifiers, versions, states and measurements can answer these questions without storing entire conversations or documents.

This does not mean content is never necessary. It means the need should be defined by purpose, with appropriate access and retention. An incident may require specialized investigation under controls different from routine monitoring.

Separate three evidence planes

1. Operations: duration, final state, failure, intervention and work units, using controlled dimensions to prevent free-form fields from turning metrics into a context repository.
2. Decision: references to the objective, policy, version and verifier, sufficient to explain why an action was eligible and who accepted it.
3. Investigation: additional data, when necessary and authorized, with defined access boundaries, purpose, duration and removal options.

The three evidence planes do not need the same backend, readers or retention. A widely used operations dashboard should not automatically inherit access to a restricted document. Technical correlation links records; it is not permission to consult all of them.

Evidence should limit the agent’s authority, not expand it

An agent can emit observations about its execution. Records proving authorization, effects and acceptance must not rely solely on its generated statements. Preserve verifiable references in components with their own responsibilities. History, policy and execution isolation are distinct boundaries; choosing another model does not replace that design. [HARNESS31-C2]

A policy identifier helps locate the rule used, but does not alone prove that it was applied. A verified field is not evidence either if the executor can fill it without external verification. The contract must identify who emits each record and what independent observation supports the displayed state.

Minimize before exporting

OpenTelemetry security guidance covers data minimization and processors that remove or transform attributes. OWASP recommends defining events, protecting logs, and excluding secrets and unnecessary sensitive data. These guidelines do not validate any particular configuration.

In the proposed contract, accepted attributes belong to an explicit set. Headers, tokens, document bodies, user instructions and free-form responses are not included for convenience. Exceptions must be justified and exercised with synthetic data before accessing authorized real content.

OpenTelemetry also warns that predictable input values may be recovered from their hashes. Hashes or pseudonyms are not automatic anonymization. Technical and privacy owners must assess reference utility, reidentification risk and access permissions in context.

A collector configuration does not undo earlier exposure in the SDK, console, queue or model provider. The proposal is to reduce collection at the source and verify every output, including tool arguments, exception messages and free-form fields in instrumented libraries. An allowlist must also restrict values: a field called status that accepts the model’s entire response still carries context.

A synthetic case: investigate without copying the entire request

Imagine an agent authorized to open an internal ticket. It prepares the request, but the integration times out. The interface says the ticket was created. A useful trail must reveal that discrepancy without sending the issue description or personal details to the general dashboard. This illustrative example is not an incident, client or deployed control.

The dashboard receives state, duration and version. The decision record holds protected references. If investigation requires the original request, access happens in the authorized system with its own purpose and duration. The identifier correlating records does not grant that permission.

A timeout creates another decision: before repeating an operation with effects, query the destination or use the idempotency mechanism it actually provides. A trace alone does not prevent duplication. Verification may also arrive later: record that confirmation as a new event linked to the same operation, preserving the previously observed state and distinguishing event time from ingestion time.

In W3C Trace Context, section 6, traceparent and tracestate serve correlation and must not carry personal or sensitive information. In this article’s proposal, neither acts as an access credential or a place to store ticket context.

Check the quality of the telemetry itself

A system may execute correctly and produce an incomplete record. It may also record an action that never reached its destination. Separate attempts, tool acceptance, observed effects and outcome confirmation. If a process requires a receipt to release a material action, its absence must remain visible as failure or inconclusiveness.

Do not impose a universal block for every lost metric. Define which signals are required for authorization and which are diagnostic only. The decision depends on impact and recovery; turning every dashboard failure into a shutdown can create another operational problem.

Cost, retention and investigation also have limits

Sampling selects some executions for diagnosis. In this proposal, it can reduce operational trace volume, but must not decide whether a receipt required for a material action is preserved. That obligation needs its own recording path. A dashboard should show the denominator: eligible, sampled, incomplete and unverified executions; a rate calculated only from well-formed traces can hide collection failures themselves.

For costs, track provider-reported units, attempts, telemetry volume, storage and human investigation work separately. Token counts are not the total bill. Execution identifiers should enable targeted lookup without becoming a free-form dimension in every metric; the set of value combinations, called cardinality, needs a budget.

Retention is not a universal number. Define purpose, owner, duration, preservation obligations, backups, exports and covered vendors. If a copy cannot be removed immediately, record the limitation and its expiration cycle; do not announce deletion across the entire chain. Policy must reconcile investigation, evidence integrity and applicable obligations. Aggregated data also needs assessment when small groups allow participants to be inferred.

More content may improve failure reproduction, while less content may better protect context. There is no single solution to this tension. One option to assess is a temporary diagnostic capture, authorized for a bounded case, with expiration and restricted readers. It does not make permanent capture of every conversation acceptable.

Minimum validation matrix

These are proposed defensive tests. Passing them does not certify privacy, security or compliance. Evidence must include the exercised configuration, version, scope and remaining limits, including paths that were not evaluated.

Maintain a list of exercised destinations and readers. Not finding a marker at an inspected destination is a bounded result; it does not prove that untested components cannot leak. OWASP includes logging failure tests, access controls and injection resistance among recommended checks; the matrix above is a proposed application to agents.

The decision connecting engineering and business

Useful observability should explain quality, cost, failures and recovery without creating an indiscriminate information archive. Business defines which outcomes merit monitoring; engineering demonstrates how signals are produced; domain owners define access and use conditions. None of these responsibilities disappears when a tool exports a visually complete trace.

NIST AI RMF Core connects evaluation, monitoring and risk treatment throughout the lifecycle. Here it guides the separation between measuring, interpreting and acting; it does not prescribe the proposed three evidence planes or certify their adoption.

For a concrete review, select a business action and walk through authorization, execution, verification, effects and record removal with the responsible people. If your company needs to structure this contract, talk to Trustyu about your workflow and constraints. Diagnosis depends on the case; this article promises no deadline, compliance or commercial outcome.

Reading glossary

• Telemetry: signals collected about execution, such as metrics, logs and traces.
• Idempotency: a property allowing an operation to be retried under a defined contract without improperly repeating its effect; it must exist in the system performing the action.
• Effect receipt: a verifiable reference to the observed result at the destination, distinct from the agent’s intention or merely sending a call.
• Minimization: limiting collection and circulation to what the defined purpose requires.

Sources and limits

1. OpenTelemetry — Handling sensitive data. Telemetry design guidance; not an audit of a Trustyu deployment.
2. OWASP — Logging Cheat Sheet. Logging, data exclusion and protection recommendations; application depends on context.
3. NIST — AI RMF Core. A voluntary framework for responsibilities and monitoring, without implied certification.
4. W3C — Trace Context, Recommendation of 23 November 2021. Sections 6 and 7: privacy and security of correlation propagation; not an authorization contract.

Editorial and responsibility note

Sources were consulted on 20 October 2026. The three evidence planes, validation matrix and contract are the author’s engineering proposals prepared editorially, not experimental results or descriptions of operating controls. Research and writing were assisted by AI. Authorship, factual review and final publication approval belong to Fernando Parreiras, with disclosed self-review. This version has not undergone independent human review. Trustyu and Tech Human work commercially in AI engineering and governance. This content does not replace technical, legal, security or privacy analysis of a specific case.