How can developers build AI applications that process sensitive customer data without exposing it through model APIs, application logs, or automated workflows?
When building AI copilots and agents, protecting data goes beyond securing the application itself. Prompts, API responses, confidential documents, and user information may pass through multiple services, each with its own data-retention and security policies.
To address privacy concerns at the model-provider level, OpenAI’s Zero Data Retention with Private Safety Processing (ZDR with PSP) is a data-control approach for eligible API customers. This approach enables automated safety monitoring without retaining eligible customer content in OpenAI's standard abuse-monitoring logs.
However, ZDR with PSP does not eliminate all data storage or automatically secure an application's entire architecture. ZDR with PSP excludes eligible customer prompts and responses from OpenAI’s standard abuse-monitoring logs, but it does not make every OpenAI endpoint or feature retention-free. Developers must check endpoint-specific eligibility and application-state behavior.
What is OpenAI ZDR with Private Safety Processing (PSP)?
OpenAI ZDR with PSP is an API data-control approach that combines Zero Data Retention with privacy-preserving automated safety reviews. It allows OpenAI to identify potential misuse while limiting its retention of eligible customer prompts and responses.
The two mechanisms serve different purposes:
Zero Data Retention (ZDR): Excludes eligible customer content from OpenAI's standard abuse-monitoring logs, subject to documented endpoint limitations and exceptions.
Private Safety Processing (PSP): Enables automated safety analysis of selected encrypted interactions within a protected computing environment.
Together, these mechanisms support safety monitoring across multiple interactions without exposing the underlying customer content to OpenAI personnel through PSP's review process.
How is ZDR with PSP Different from Standard API Data Retention?
OpenAI provides different data-control options depending on customer eligibility, API features, and retention requirements.
Data-control option | How customer data is handled |
Standard API retention | Abuse-monitoring logs may contain customer content and are generally retained for up to 30 days. |
Modified Abuse Monitoring (MAM) | Excludes eligible customer content from standard abuse-monitoring logs. |
Zero Data Retention (ZDR) | Excludes eligible content from abuse-monitoring logs and changes response-storage behavior for supported endpoints. |
ZDR with PSP | Maintains ZDR protections while enabling automated safety review using encrypted records in customer-controlled storage. |
Private Retention with PSP | Retains customer content in encrypted abuse-monitoring logs in OpenAI-managed infrastructure, while excluding it from human review unless required by applicable law. |
The table omits Safety Retention, another OpenAI control. For customers approved for ZDR or MAM, OpenAI reserves the right to make particular models ineligible for those controls when reasonably necessary to investigate or prevent severe-risk activity; in that case, it may retain and human-review content detected as potentially violating policies.
The important distinction for developers is that model-provider data retention and application-level data storage are separate responsibilities.
Even when ZDR is enabled, an application may retain information in its own database, logs, monitoring systems, or connected services.
Source: OpenAI API Data Controls.
Why Did OpenAI Introduce Private Safety Processing?
Traditional AI safety checks often evaluate individual prompts and responses. However, some potentially harmful behaviors become apparent only when multiple interactions are considered together.
For example, a single prompt might appear harmless, while a series of related requests could reveal attempts to bypass safeguards. Similarly, an autonomous AI agent might continue performing actions beyond its intended permissions.
OpenAI introduced PSP to address three challenges:
Cross-interaction risk detection: Identify potentially harmful patterns that isolated prompt checks may miss.
Customer confidentiality: Conduct automated safety reviews without giving OpenAI personnel access to protected customer content.
Frontier-model safety: Monitor risks associated with increasingly capable models and longer-running agent workflows.
For developers building agentic applications, this distinction matters because safety risks can emerge across multiple requests, tools, and execution steps.
PSP aims to support broader safety monitoring while maintaining stronger customer data-privacy protections.
Source: OpenAI - Offering Zero Data Retention for Frontier Models.
How Does OpenAI Private Safety Processing Work?
Private Safety Processing uses an asynchronous safety-review pipeline that encrypts selected API interactions and processes them within a protected computing environment. In a ZDR with PSP deployment, the encrypted records are stored in customer-controlled cloud infrastructure.
The architecture separates normal model inference from additional safety analysis through four steps.
Step 1: How are API Interactions Selected and Encrypted?
When an application sends a request through an OpenAI API project configured for ZDR with PSP, the model processes the prompt and generates a response.
Certain interactions may be selected for additional automated review through safety-classifier referrals or approved sampling policies.
Selected prompts and responses are encrypted before storage.
Importantly, selection for review does not automatically indicate a policy violation.
Step 2: Where are Encrypted PSP Records Stored?
Selected encrypted records are written to the customer's configured cloud storage rather than OpenAI's standard abuse-monitoring logs.
OpenAI currently supports four cloud storage services:
PSP records are written with a 30-day time-to-live (TTL). Customers must configure storage lifecycle rules that prevent premature deletion and maintain the permissions required for record retrieval.
OpenAI also maintains an operational index containing storage references and metadata rather than copies of the underlying customer content.
Step 3: How Does the Protected Safety Runtime Analyze Records?
When additional analysis is required, PSP retrieves encrypted records and processes them inside a hardware-attested Safety Review Runtime.
The protected environment is designed to:
Allow only authorized safety-review workloads to decrypt customer content.
Prevent OpenAI personnel from accessing protected prompts and responses through the review process.
Restrict the information that can leave the runtime.
The review operates asynchronously, so additional safety analysis does not need to delay the original API response.
Step 4: What Happens After PSP Completes a Safety Review?
PSP generates predefined safety signals and approved operational metadata instead of exposing complete prompts or conversations.
These signals may indicate potential misuse and support subsequent safety decisions or enforcement. Detailed review results are encrypted before leaving the protected runtime.
The underlying principle is that automated safety monitoring can evaluate potential risks without giving OpenAI personnel routine access to the protected customer content.
Get insights in your inbox!!
Weekly tips on building smarter apps. Join 8,200+ founders and builders.
No spam. Unsubscribe anytime. We respect your privacy.
Source: OpenAI ZDR with PSP Developer Guide.
Does OpenAI ZDR with PSP Still Retain Customer Data?
Yes. OpenAI ZDR with PSP requires selected encrypted interaction records to remain in customer-controlled cloud storage for at least 30 days, even though eligible prompts and responses are excluded from OpenAI's standard abuse-monitoring logs.
This distinction matters because Zero Data Retention does not mean information is never stored anywhere.
Under ZDR with PSP:
Customer content: Selected interactions are stored as encrypted records in the customer's configured infrastructure.
Retention period: PSP records must be retained for at least 30 days. Customers must configure lifecycle rules that prevent records from being deleted before the required retention period ends.
Operational metadata: OpenAI keeps storage references and necessary processing metadata.
Data usage: PSP safety records are restricted to approved safety purposes and cannot be used for model training.
For developers, this means that implementing ZDR does not remove the need for application-level data lifecycle management.
How Do Encryption Keys Protect Customer Data Under PSP?
OpenAI uses layered encryption to restrict access to retained safety records.
OpenAI-managed HPKE encryption forms the inner encryption layer. It restricts decryption of protected customer content to the authorized Safety Review Runtime.
Enterprise Key Management (EKM) adds an optional customer-managed encryption layer. When enabled, decryption requires authorization from the customer's key-management service.
OpenAI also documents a separate PSP decryption capability that can allow customers to decrypt eligible stored records using their own asymmetric keys, subject to availability and configuration.
Revoking EKM authorization can prevent further decryption of retained records, but it does not delete those records or reverse previously completed processing.
Developers and platform teams must therefore manage both the encryption architecture and the storage lifecycle.
Source: OpenAI PSP Developer Documentation.
How Can Developers Configure OpenAI ZDR with PSP?
ZDR with PSP is enabled through OpenAI's organization and project-level data controls, not through a standard model-inference parameter.
Organizations must be approved for an eligible base retention policy, either Zero Data Retention (ZDR) or Modified Abuse Monitoring (MAM), connect supported customer-controlled storage, and validate the configuration before PSP becomes active.
What are the Requirements for Setting Up ZDR with PSP?
The implementation involves four steps:
Confirm base retention-policy eligibility: Obtain OpenAI approval for an eligible base retention policy, either Zero Data Retention (ZDR) or Modified Abuse Monitoring (MAM), and satisfy the applicable requirements.
Configure cloud storage: Connect a supported storage destination with appropriate access permissions, regional settings, and retention lifecycle rules.
Enable PSP at the project level: Associate the storage destination with the intended OpenAI API project and select the applicable base retention policy.
Validate the configuration: Confirm successful storage validation and verify that PSP is active for the project.
OpenAI supports setup through its API console and management APIs.
Once enabled, PSP applies to all API traffic within the configured project, including requests to models that might not otherwise require PSP.
Applications requiring different retention policies should use configured projects separately.
What Should Developers Verify Before Production Deployment?
Successful PSP activation does not eliminate application-level security responsibilities.
Before deployment, developers should verify:
Endpoint eligibility: Confirm that the selected OpenAI models, endpoints, and features support the intended ZDR configuration.
Storage permissions: Ensure the application and PSP services have the appropriate access without unnecessary privileges.
Retention settings: Maintain lifecycle rules that meet the required safety-record retention period.
Storage availability: Monitor connectivity, configuration changes, and access failures.
Data residency: Verify that storage regions match applicable project requirements.
Third-party integrations: Review the data-retention policies of external APIs, hosted tools, and connected services.
Certain API capabilities, including persistent application-state features, may retain information even when ZDR is enabled.
Developers should consult OpenAI's endpoint-specific retention documentation rather than assuming every API feature follows identical rules.
Sources: OpenAI PSP Setup Guide and API Data Controls.
How Can Developers Secure AI Applications Beyond OpenAI ZDR with PSP?
OpenAI ZDR with PSP addresses specific model-provider data-processing activities, but developers must still protect information throughout the application's complete execution flow.
Consider an AI document-analysis application.
A user uploads a confidential document, the backend retrieves its contents, an OpenAI model generates a summary, and the application saves the result.
Even if the OpenAI API project uses ZDR with PSP, sensitive information could still appear in request logs, databases, monitoring platforms, or connected third-party services.
Developers should implement four additional safeguards.
1. How Can Developers Enforce Data Access Before Model Execution?
Applications should validate permissions before retrieving confidential information or sending it to an AI model.
Use role-based access controls, tenant isolation, and authorization checks to restrict what users and AI agents can access.
An agent should never gain broader permissions simply because it can invoke an external tool or API.
2. How Can Developers Prevent Sensitive Data from Appearing in Logs?
Logging is essential for debugging and monitoring, but indiscriminate logging can create unnecessary privacy risks.
Developers should:
Avoid logging complete prompts, API responses, and confidential documents unless necessary.
Redact passwords, access tokens, personal identifiers, and other sensitive fields.
Apply appropriate log-retention periods and access permissions.
Separate security-relevant operational metadata from sensitive customer content.
For example, recording an API request ID, endpoint, execution status, and latency may provide useful diagnostic information without storing the full prompt.
3. How Should Developers Secure AI Agent Tools and External APIs?
AI agents may retrieve documents, query databases, execute code, or interact with third-party services.
These capabilities introduce security responsibilities beyond the language model.
Developers should implement:
Explicit permissions for each connected tool.
Input validation and authorization before executing actions.
Human approval for high-impact operations.
Restrictions on sensitive data shared with external services.
Monitoring of tool execution and policy violations.
These controls reduce the risk of unauthorized actions and unnecessary exposure of business data.
4. How Can Security Policies Remain Consistent Across Environments?
TrendingAI App Development Base44 Integrations: What to Know About Credit Limits
Base44 integration credits can run out quickly when your app uses AI calls, file uploads, emails, SMS, image generation, Google Workspace tools, Slack, Zapier, Twilio, or other connected actions. This guide explains how Base44 integrations work, why users run out of integration credits, how credit limits affect app users, and when to upgrade or consider a Base44 alternative for credit-heavy AI apps.
AI applications often move through development, staging, and production environments with different configurations.
Without consistent policies, a secure production design can be undermined by an insecure testing or deployment workflow.
Use policy-as-code, infrastructure configuration checks, and automated validation to enforce consistent requirements for access, model usage, secrets, and deployment.
Security policies should be tested alongside application functionality before every production release.
How Does CodeConductor Support Secure AI Application Development?
Building privacy-conscious AI applications requires more than integrating a secure model API. Developers also need to govern how models are selected, how agents access business information, and how applications are deployed.
CodeConductor provides a unified platform for building, governing, and deploying AI-powered applications and agents, helping development teams maintain consistent architectural and security controls.
Its capabilities include:
App Studio: Generate full-stack applications using standardized development patterns and exportable code.
Copilot Studio: Build AI-powered copilots and agent workflows.
Policy Engine: Apply policy-as-code, role-based permissions, data boundaries, and governance rules.
Model Router: Control model selection and enforce routing policies based on application requirements.
Flexible deployment: Deploy applications across supported cloud environments, private VPCs, and on-premises infrastructure.
For example, a development team building an internal document assistant could use CodeConductor to enforce document-access policies, govern model selection, and maintain consistent deployment configurations.
Where an eligible OpenAI project uses ZDR with PSP, those provider-level protections can complement the controls implemented in the application architecture.
However, CodeConductor does not automatically enable OpenAI ZDR or PSP. These settings must be configured and validated separately within the relevant OpenAI API project.
Developers can explore CodeConductor's platform architecture and Model Router to understand how application-level governance and model controls work together.
FAQs
Can Developers Enable ZDR with PSP Through the OpenAI SDK?
PSP is configured through OpenAI's project-level data controls and storage setup rather than a standard model-inference parameter. Developers must verify that the intended API project has the correct retention policy and validated storage.
Does Setting store: false Enable Zero Data Retention?
No. The store: false parameter controls response-storage behavior for supported API operations. It does not grant ZDR eligibility, configure customer-controlled PSP storage, or activate Private Safety Processing.
Can Developers Access and Decrypt Their Own PSP Records?
Where PSP decryption is enabled, eligible customers can decrypt supported records using an asymmetric key they control. OpenAI uses the corresponding public key, while the private key remains in the customer’s cloud key-management service. This is separate from Enterprise Key Management.
Does OpenAI ZDR with PSP Prevent Third-Party API Logging?
No. ZDR with PSP governs eligible OpenAI processing. External APIs, monitoring tools, databases, and connected services may retain information according to their own configurations and policies.
Does ZDR with PSP Guarantee GDPR or HIPAA Compliance?
No. ZDR with PSP provides specific privacy and safety controls but does not independently establish regulatory compliance. Organizations must evaluate their complete data flows, contractual requirements, access controls, and applicable legal obligations.
Written by
Paul Dhaliwal
Founder & Chief Executive Officer
Paul Dhaliwal is a tech innovator and Founder of CodeConductor, an open-source no/low-code platform. With 10+ years of experience in AI and scalable development, Paul focuses on crafting intelligent solutions that drive real-world value. A firm believer in the mantra "Eat, Sleep, Code, Repeat," he balances his passion for software with a love for travel and family.
