Problem: “No retention” is not the same as “no disclosure risk”

Enterprise AI APIs marketed as “no data retention / zero data retention (ZDR)” can still expose regulated data through:

• Abuse-monitoring and safety systems (content and/or derived metadata)
• Feature-level persistence (prompt caching, stored outputs, file APIs, grounding/browsing)
• Operational access planes (support workflows, contractors, incident response)
• Legal holds and compelled disclosure requirements
• Tool/browsing egress paths (web search, external sites, connectors)

OpenAI, for example, documents that API inputs/outputs may be retained up to 30 days for service delivery and abuse detection (unless approved for ZDR for eligible endpoints), with legal exceptions, and that access may include authorized employees and specialized contractors for support/abuse/legal compliance.

Google documents that achieving “zero data retention” depends on conditions and that some grounding features store prompts/context/output for 30 days and cannot be disabled for that feature set.
Anthropic documents that ZDR scope can be product-limited, with carve-outs (e.g., file-related persistence).

The Imbrulo approach: reduce third-party custody and isolate environments

Imbrulo offers a “no surprises” privacy posture built around:

• Dedicated environment per firm (no shared customer runtime)
• Encryption in transit and at rest
• No model training or analysis using customer data
• Models run on Imbrulo infrastructure (no third-party model providers for private data)
• Configurable retention, deletion controls, and audit logging
• SSO/MFA, RBAC, IP allow-listing/VPN options

Deployment options aligned to risk level

• Dedicated tenant (Imbrulo secure cloud): single-tenant environment managed end-to-end; optionally restrict access to office/VPN networks.
• On-prem (in your office): pre-configured server shipped to customer site; data stays in customer network; remotely maintained.

What this means for regulated matters

If disclosure risk is dominated by third-party custody, feature carve-outs, and legal/operational access, then the strongest lever is an architecture that:

1. minimizes third-party custody of sensitive content, and
2. provides provable isolation + auditable access controls.

Let's explore how Imbrulo's architecture compares to AI services relying third-party API services like OpenAI, Anthropic, Grok, ect... advertising a ZDR (zero data retention) posture.

Enterprise API "Zero Data Retention" vs Imbrulo Private AI

Area	Enterprise API	Imbrulo Dedicated Tenant	Imbrulo On-Premise	Risk Assessment
Prompt/output persistence	Often conditional; may retain for abuse monitoring by default and/or allow persistence via features; legal exceptions common.	Tenant-scoped storage; configurable retention; deletion controls; no third-party model provider for private data.	Customer-controlled storage lifecycle.	“No retention” must be validated per endpoint and feature, not assumed globally.
Abuse monitoring logs	May contain content and derived metadata (classifier outputs). ZDR may require prior approval and can shift compliance responsibility back to customer.	Dedicated environment narrows blast radius; audit logging and access monitoring positioned.	Local logging under customer governance.	Even when content is excluded, derived metadata can still be sensitive.
Feature carve-outs (caching, files, stored outputs)	Common source of “surprise persistence.” Google explicitly documents that some grounding features store data for 30 days and cannot be disabled.	Imbrulo offers configurable retention and “no surprises” controls.	Customer can disable/segment features at perimeter.	Most real-world privacy failures are configuration/feature failures, not “base model” failures.
Tool/browsing egress	Any web search/connector can disclose sensitive context to third parties; ZDR does not protect against external egress.	Web-assisted research is an optional capability; must be governed/disabled for regulated matters.	Same.	Treat tool/browsing as a separate trust boundary.
Human access (support/ops)	Vendor policies often allow limited employee/contractor access for support/abuse/legal compliance.	Dedicated environment + RBAC + audit logging positioned.	Mostly customer-controlled; remote maintenance must be constrained and auditable.	In regulated settings, support workflows are a primary leakage channel.
Compelled disclosure / legal hold	Third-party custody increases subpoena/legal hold surface area; legal exceptions common.	Still a service operator, but scope is narrowed if isolation is real.	Data custody remains with customer; strongest posture for “assume subpoena” environments.	Highest-impact risk category: legal compulsion + third-party custody.
“No log” claims	Some providers claim no logging of prompts/completions (e.g., Bedrock), but warn that tags/free-form fields can leak into billing/diagnostic logs.	Imbrulo provides tenant-level audit logging that customers can govern.	Customer can centralize logs + minimization.	“No logging” rarely means “no metadata anywhere.” Validate every field.

Verified Failure Modes (documented by major providers)

• Default abuse-monitoring retention (content and/or derived metadata) unless approved/eligible for ZDR.
  Impact: unexpected retention expands breach scope and discovery exposure; violates internal retention policy; triggers notification obligations.
• Feature-driven persistence (grounding/browsing, caching, file APIs, stored outputs). Google documents 30-day storage for certain grounding features with no disable option for that feature set.
  Impact: regulated content can be stored even when the “base” API is configured for lower retention.
• Product-scope limitations of ZDR (ZDR may apply only to specific products/endpoints; carve-outs exist).
  Impact: a team uses a non-covered surface (console/beta/tooling) and silently exits the intended privacy posture.

Implied failure modes (architecturally inherent to third-party APIs)

• Metadata leakage (tenant identifiers, timing, volume, client/matter inference) even when content isn’t stored.
  Impact: adversaries or auditors can infer sensitive activity; reputational and legal exposure in M&A, investigations, litigation.
• Operational access plane exists (support/incident response). OpenAI documents limited access by authorized employees and specialized contractors for support/abuse/legal compliance.
  Impact: insider risk, accidental exposure via tickets/screenshares, and implicit disclosure during incident handling.
• Shared control plane / multi-tenant blast radius
  Impact: low-probability, high-severity events (misconfig, vuln) can create cross-tenant exposure.

Potential failure modes (high-consequence edge cases)

• Legal hold overrides / compelled disclosure (provider custody becomes the chokepoint)
  Impact: forced preservation/production; adverse publicity; client trust loss; privilege disputes.
• Tool egress + prompt injection (web search, external sites, connectors)
  Impact: inadvertent exfiltration of confidential context outside approved boundaries.
• Policy drift (terms/features change; new persistence surfaces introduced)
  Impact: compliance posture degrades without code changes; audit findings and contractual breach.

Summary and conclusions

For regulated workflows where inadvertent disclosure creates legal, financial, and reputational harm, the risk-dominant failure modes are not “model quality” issues but custody and control: feature carve-outs that store or cache data, abuse-monitoring and derived telemetry, operational access planes, tool/browsing egress, and legal-hold/compelled disclosure dynamics that can override normal retention promises.

Enterprise APIs marketed as “no data retention/ZDR” are frequently conditional and scope-limited, and they introduce an additional, structural problem: lack of verifiability. Because critical controls (logging behavior, internal access, incident response handling, backup/replication deletion semantics, and legal preservation) are ultimately implemented and enforced by a third party, customers often cannot independently prove end-to-end non-persistence or non-access—creating both known residual exposure and unknown exposure from opaque or changing internal systems and processes.

By contrast, Imbrulo’s dedicated-tenant and especially on-prem options are designed to minimize third-party custody, narrow the blast radius, and support stronger isolation and governance, making Imbrulo the lowest-risk path for high-sensitivity regulated use; many alternative enterprise API approaches can produce risk profiles that are difficult to substantiate in audit and may be untenable under strict confidentiality, privilege, or regulatory obligations.

InfoSec for Enterprise API - Quick FAQ

Q: Does “no data retention” mean nothing is stored anywhere?
A: Not necessarily. Major providers document exceptions based on abuse monitoring, feature-level caching/storage, and legal requirements.

Q: What is the main privacy gap with enterprise APIs, even under ZDR?
A: Third-party custody, feature carve-outs, and operational/legal access paths remain; these are the dominant drivers of high-severity disclosure in regulated matters.

Q: How does Imbrulo reduce this risk?
A: Imbrulo positions dedicated per-firm environments, encryption, configurable retention, audit logging, and an on-prem option to keep data in the customer network.

Q: What controls should we require regardless of vendor?
A: Disable/strictly govern tool egress, enforce endpoint/feature allowlists, define retention precisely (including derived telemetry and backups), and require auditable support access.

Vendor Security Questions

Still considering use of AI provided via an Enterprise API? Ask the following questions of the provider and make sure you get comprehensive responses before committing.

1. Enumerate all products/endpoints/features included in “ZDR/no retention” and all exclusions.
2. Describe abuse monitoring: what is logged (content vs derived metadata), where stored, how long, who can access.
3. Identify features that persist state: prompt caching, stored outputs, file APIs, grounding/browsing/connectors; document retention per feature.
4. Define support access controls and auditing (employee/contractor access, approvals, exportable logs).
5. Clarify legal process handling: notification, scope minimization, and preservation behavior.
6. Provide deletion semantics for content, metadata, and backups; specify any verified deletion options.
7. Provide subprocessor list and change-control commitments.