---
title: "The agent's log does not need the secret"
slug: "o-log-nao-precisa-do-segredo"
date: "2026-10-29"
publishedAt: "2026-10-29T06:05:00-03:00"
author: "Rodrigo Jorge"
summary: "Logging every input and output makes debugging easier, but can create another copy of credentials and restricted documents. The execution trail needs a data contract."
origem: "Analysis"
status: "published"
---

**Rodrigo Jorge** · Prepared October 29, 2026, at 6:05 a.m. Brasília time (UTC-3). Publication time to be confirmed.

An agent calls a tool using a protected credential. The call fails. To investigate, the integration logs the entire request, including the authentication header.

In this hypothetical scenario, the credential may be securely stored and still end up somewhere else: the error log. Anyone who can read that log now has access to a copy the original design may not have accounted for.

The same question applies to prompts, tool arguments, retrieved documents, and responses. Enabling full capture for easier debugging changes the data the observability system receives. That change needs an explicit decision.

OWASP recommends that data such as access tokens, passwords, and keys should generally not be logged directly. OpenTelemetry's documentation advises minimizing collection and reviewing what instrumentation libraries emit. It also makes clear that the tool cannot determine on its own what is sensitive in every context.

For an agent that can take action, I propose starting with an event contract. What information lets us reconstruct the action without copying its sensitive content? A conceptual example, with illustrative values, would be:

- `operation_id`: `op-exemplo`
- `tool`: `consultar-alerta`
- `authorization`: `allowed`
- `result`: `upstream_error`
- `content_recorded`: `false`

This record helps correlate calls, but it is not a complete audit trail. Depending on the operation, a timestamp, a controlled reference to the target, the policy version, and the responsible identity will still be needed. Those fields also need classification and access controls. Metadata is not synonymous with public data.

## Test the error paths too

A check that follows only a successful call may miss the path that dumps the entire request when an exception occurs. I would ask for the same test with an authentication error, a timeout, and a malformed response, using synthetic markers instead of real secrets.

The check needs to cover the destinations the integration uses: application logs, traces, export queues, and any support bundles. Looking for the marker only on the debug screen does not show what was transmitted or retained elsewhere.

OpenTelemetry documents processors that remove or transform attributes. They can help, but filtering in the Collector does not eliminate a copy the application already wrote upstream. Reducing capture at the source and checking the entire path are therefore separate decisions.

Some investigations require detailed content. In those cases, I would separate exceptional capture from operational logging: a defined purpose, narrow scope, controlled access, and a retention period chosen for that need. This article specifies no universal retention period and makes no promise that masking a few patterns will remove all sensitive data.

The test should deliver two results: an explanation of which action was attempted and what response it received, and evidence of where the synthetic marker appeared or did not appear. If removing the secret makes investigation impossible, the evidence being collected needs to be redesigned. Copying everything and deciding later what matters passes the problem to the people who store and query the logs.

### References

- [OWASP: Logging Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html), Data to exclude section, accessed October 29, 2026.
- [OpenTelemetry: Handling sensitive data](https://opentelemetry.io/docs/security/handling-sensitive-data/), accessed October 29, 2026.