Agent Observability Without Centralizing Conversation Content
What you’ll learn
- Why Zero Data Retention, a configuration intended to prevent prompts and responses from being retained, does not mean that no information is ever stored
- Why recording entire conversations and documents creates more places where confidential information is stored
- How monitoring can separate conversation content from information that indicates a safety concern
- What to check before retaining a record for monitoring
Monitoring Can Separate Conversation Content from Safety Signals
Monitoring an AI agent—an AI system that can search or operate external systems in response to a request—requires visibility into what it did and whether it performed a risky action. Agent Observability means being able to understand an agent’s behavior and state through execution records and related information.
However, collecting every conversation and internal document in one place for monitoring also accumulates confidential information in that location. Privacy-preserving monitoring therefore separates conversation and document content from information that indicates a safety concern.
One development related to this approach came on August 19, 2026, when OpenAI announced Private Safety Processing for environments eligible for Zero Data Retention (ZDR). The design processes safety signals across multiple interactions without OpenAI retaining prompts or model responses after processing. At the time of the announcement, it was being tested with early customers and was not a generally available, finalized specification.[2]
This article separates what the announcement establishes from the design choices an organization still needs to make. Its focus is how to detect a risky sequence of actions and support an investigation without storing conversation content in a central monitoring system.
The Convenience and Storage Risk of Full-Content Logs
Agent monitoring often sends the following information to one logging platform, a system that collects execution records so they can be searched and reviewed:
- Prompts, meaning instructions or other input sent to the AI, and responses
- Tool calls, meaning records of the AI using external functions such as search, file operations, or an API
- The user and execution time
An API is an interface through which systems exchange data or functionality.
Collecting these records together makes it easier to investigate a problem. It also means that the logging platform stores confidential information from the original business system.
For example, an agent supporting merger and acquisition research may process unpublished financial statements, contract terms, and the names of involved parties. Copying the full trace—the chronological record of processing—to an external monitoring service can make troubleshooting easier. It also increases the number of storage locations and people with access. Deletion schedules, cross-border data transfers, and vendor controls then require review as well.
Official OpenAI documentation states that abuse monitoring logs for standard API use may be retained for up to 30 days. Approved customers can use Zero Data Retention or Modified Abuse Monitoring, which changes how abuse monitoring logs are handled.[1]
Enabling ZDR does not mean that no information is stored anywhere, including by connected services. The handling of application state—state or data stored so that processing can work—varies by API capability. Information sent to a third-party MCP server, which connects an AI system to external data or functions through a common protocol, is subject to that service’s retention policy.[1]
Two Management Areas for Content and Monitoring Information
Privacy-Preserving Agent Observability handles conversation content and the information needed for a safety decision through separate paths.
This article organizes those paths as follows:
- Content Plane: the area that handles instructions, documents, tool results, and responses
- Safety Signal Plane: the area that handles risk classifications and the information needed for decisions such as stopping or continuing execution
These are not official OpenAI product terms. They are categories used in this article to apply the announced design to organizational monitoring decisions.[2]
| Information category | Examples |
|---|---|
| Information kept in the Content Plane | Prompts and responses, internal documents and search results, tool inputs and outputs, customer, employee, and case details, and original traces used for investigation |
| Candidate information for the Safety Signal Plane | Risk category, detection time, pseudonymous agent or session ID, applied rule ID, and actions such as stop, continue, or review |
A session is a related group of interactions or processing steps. Pseudonymization replaces a direct identifier such as a person’s name with another identifier.
This article calls the information sent for monitoring a safety signal. If a signal includes too much detailed conversation summary, the record becomes close to full-content logging. At the other extreme, a single “anomaly detected” flag is not enough to determine whether a detection was false or how far its effects reached.
The design must therefore decide both what will not be sent and what information is still needed to make a decision.
Detecting Sequences with Short-Lived Records
An agent’s risky behavior may not be visible in a single request or operation. A customer lookup, list export, or external connection can look routine in isolation but become concerning because of its order or combination with other actions.
The Private Safety Processing announcement likewise describes the need to identify patterns across multiple interactions.[2]
Even without centrally storing conversations, an organization can keep short-lived processing state in an environment it controls and review sequences such as:
- An agent limited to lookup begins exporting a large volume of data
- An agent reads internal data and immediately attempts an unapproved external connection
- New tool calls continue after a user stop instruction
- The same rule violation occurs across several sessions in a short period
The important decision is not whether to store conversations indefinitely, but which records the organization needs for each monitoring purpose and for how long. The records can be separated by purpose:
| Purpose | Information retained |
|---|---|
| Detect risky behavior | Short-lived processing state used to evaluate the order and relationship of operations |
| Support an audit | Safety signals showing the detected risk and the action taken |
| Investigate an individual case | Original traces needed to understand the detailed sequence of events |
Using a separate retention period for each purpose makes it easier to explain why the records are stored.
Graduated Access to Detailed Execution Records
Minimal safety signals may not be enough to identify a cause. An investigation procedure can therefore allow an approved person to review the original trace within the organization’s controlled environment.
The investigation records:
- The session and reason for the investigation
- The approver and the person who performs the review
- The scope of information available and the access deadline
- Whether data may be exported
- How data is deleted when the investigation ends
A high-risk signal alone cannot establish employee misconduct or a customer violation. The applied rules, the agent’s permissions, and the actual execution result still require review.
Metadata—identifiers, timestamps, and other information attached to a record—can also be sensitive. Combining an agent ID, time, risk category, and frequency may reveal the existence of an unreleased project or other organizational activity.
Monitoring information therefore needs access control, a retention period, and restrictions on secondary use even when it does not contain conversation text.
Checks for Limiting Monitoring Fields
Monitoring fields tend to expand when they are chosen from whatever information is available. The first question should instead be whether a field supports detection, stopping, investigation, or reporting.
The following checklist can be used before adding a telemetry field. Telemetry is information collected to understand a system’s operation or state.
| Check | Confirmed state |
|---|---|
| Decision purpose | The organization can explain whether the field is used for detection, stopping, investigation, or reporting |
| Information granularity | The organization has considered whether the same decision can be made without sending conversation or document content |
| Identifiers | The organization has checked whether direct names or customer IDs can be replaced with pseudonymous identifiers |
| Retention period | Separate retention periods are defined for detection, audit, and investigation records |
| Access permissions | Routine monitoring and exceptional review of detailed information use different permissions |
| Third-party transfer | The destination’s retention policy, data-processing region, and subprocessors have been reviewed |
| Deletion and expiry | Methods exist to delete expired data and invalidate keys or identifiers |
| False-positive handling | A person can review a decision, reverse a stop, and correct the record |
ZDR is not a certification that automatically satisfies this checklist. OpenAI documentation describes capabilities that are not eligible for ZDR, temporary application-state retention, third-party services, and exceptions related to legal obligations or severe safety risks.[1]
The organization must therefore review its contracts, enabled capabilities, connections, data-processing regions, and legal obligations against its actual deployment.
Summary: Separate and Minimize Records According to Their Purpose
Privacy-preserving agent monitoring separates conversation and document content, the minimum information needed for safety decisions, and the records needed for individual investigations. Defining what information is handled, for what purpose, for how long, and by whom provides the foundation for combining monitoring with protection of confidential information.
An organization can begin by classifying its current logs as conversation or document content (Content), indicators of safety concerns (Signals), or evidence needed for an investigation (Investigation Evidence). Adding a decision purpose and deletion deadline to each category reveals which records are necessary and which can be considered for reduction.
Full-content logs without an explainable retention purpose are strong candidates for review. At the same time, the design needs to preserve enough information for false-positive review and root-cause investigation by accounting for both routine monitoring and detailed investigations.
This article is a general information summary and is not legal advice. Confirm practical decisions with a qualified specialist.
References
- OpenAI API Documentation, Data controls in the OpenAI platform
- OpenAI, Offering Zero Data Retention for frontier models, August 19, 2026
For the latest releases and updates, check the official website and official documentation.