No-Log Default

A no-log default is a product posture in which the provider does not retain conversation history in the normal operating path. It reduces provider-side exposure, but it does not automatically eliminate local storage, upstream model visibility, or other forms of metadata collection.

Expanded Definition

A no-log default describes a service posture where the provider does not retain conversation history in the ordinary operating path. The practical boundary is important: it usually speaks to provider-side retention, not to every possible form of collection, temporary processing, enterprise integration, or end-user export. In other words, “no-log” is a storage policy, not a blanket guarantee that content never exists outside the user interface.

For security and governance teams, the term is most often used to contrast retention minimisation with products that keep chat transcripts for product improvement, troubleshooting, abuse detection, or human review. The most common misunderstanding is treating no-log default as equivalent to absolute invisibility. It is not. Metadata, prompt routing, connected tools, local browser caches, tenant-level archives, and model-adjacent telemetry can still create exposure depending on the deployment.

NHIMG treats this as a boundary-setting term rather than a compliance label. Where organisations need stronger assurances, they should verify exactly what is excluded from retention, what is retained temporarily, and which controls govern that data path. For a general control baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference point for understanding retention, auditing, and data handling expectations.

Examples and Use Cases

• A consumer chatbot states that it does not keep chat transcripts by default, which lowers routine provider-side exposure but still leaves open questions about transient processing and abuse telemetry.
• An enterprise AI assistant is configured to avoid long-term logging for internal prompts, while security teams separately decide whether session records must be captured in a SIEM or archived for compliance.
• A customer support workflow uses a no-log default for live interactions, but supervisors may still enable limited retention for quality review, creating a deliberate trade-off between privacy and oversight.
• A regulated organisation reviews whether the “no-log” claim applies to attachments, embedded files, and tool calls, not only to plain-text conversation text.
• A product team uses the label to signal reduced data retention in a sales process, but procurement still checks whether the provider retains operational diagnostics in another system.

The trade-off is straightforward: less retention generally means less exposure, but also less historical traceability when incident investigation, abuse review, or dispute handling is needed. That is why the operational question is rarely “logs or no logs” and more often “which records are retained, for how long, and under what governance.”

Security Implications

No-log default matters because retained conversation history can become a high-value corpus for privacy breaches, insider misuse, subpoena scope, and accidental overexposure. When the term is misunderstood, organisations may assume content has been eliminated from the risk surface even though copies still exist in browser storage, endpoint caches, integrations, support tooling, or downstream archives.

The failure mode is usually a retention mismatch. Security, legal, and platform teams may each assume another layer is responsible for deletion or minimisation, so sensitive prompts remain accessible longer than intended. This becomes more consequential when users submit secrets, personal data, credentials, incident details, or regulated material into the system.

A practitioner observation from NHIMG’s identity and AI security work: the biggest gap is often not the stated retention policy, but the surrounding data path. If a prompt reaches plugins, external tools, or workflow automation, the effective exposure can extend well beyond the provider’s stated default.

Domain and Governance Relevance

No-log default sits at the intersection of privacy engineering, data minimisation, and operational trust. In AI security, it is relevant because model interactions frequently contain sensitive context that users would not normally place into a long-lived repository. In identity-heavy environments, the issue becomes sharper when prompts, files, or session data include API keys, service account details, access tokens, or administrative instructions.

For governance, the key question is not whether the provider markets itself as “no-log,” but which records are actually retained and who can access them. Organisations should treat the claim as one control characteristic among several, then test it against their own requirements for monitoring, retention, legal hold, and incident response.

For NHI and agentic workflows, the meaning shifts further: an autonomous system may generate, route, or transform sensitive content at machine speed, so even short-lived retention can create an audit, leakage, or replay risk if those records are not tightly scoped. In that context, no-log default reduces one exposure layer, but it does not replace identity scoping, secret handling, or data-flow governance.

Related resources from NHI Mgmt Group

• Should security teams disable OneDrive auto-sync by default?
• What breaks when RC4-only Kerberos accounts are migrated into AES-default Active Directory domains?
• What breaks when secrets are used as the default for workload access?
• What breaks when organisations keep passwords as the default identity control?