HTTPS only protects the transport path between your device and the provider’s server. The provider terminates that encryption to process the prompt in plaintext, which is how hosted AI services work. That means transport security does not answer who can read stored chats, whether chats train models, or whether a third party receives the content for inference.
Why transport encryption is not the same as content confidentiality
HTTPS answers one narrow question: can someone on the network path read or alter traffic in transit? It does not answer who terminates the TLS session, who processes the payload, or where the plaintext exists after decryption. For hosted AI, the provider must decrypt the prompt at its edge or application tier to generate a response, so transport protection and content handling are separate problems.
That distinction matters because the content can be visible to the service operator, to systems the operator uses for inference, logging, safety review, abuse detection, or storage, and sometimes to approved subprocessors. NIST AI 600-1 GenAI Profile is useful here because it treats content provenance, governance, and disclosure as distinct from transport security.
Where the provider can still see or retain chat content
A provider generally has to decrypt the request, inspect it, and return a response, which means the plaintext is exposed inside the provider-controlled trust boundary. That exposure can be transient, but it can also be copied into logs, customer support workflows, model evaluation pipelines, rate-limit telemetry, or retention systems depending on the product and contract.
For practitioners, the key question is not whether TLS was used, but whether the provider’s data handling terms, retention settings, and tenant isolation controls match the sensitivity of the conversation. EU General Data Protection Regulation (GDPR) is relevant when the chat contains personal data, because storage, access, and retention obligations extend beyond transport protection.
In some products, the provider may also use chat content for model training, fine-tuning, abuse monitoring, or human review unless those uses are disabled by policy or contract. That is why “encrypted in transit” is a baseline security measure, not a confidentiality guarantee about the content itself.
What to verify before treating a chat as confidential
Security teams should verify four things: who can access the plaintext, whether it is retained, whether it is used for training or evaluation, and whether subcontractors receive it. Those answers belong in the provider agreement, privacy notice, enterprise controls, and administrative settings, not in the presence of HTTPS alone.
Technical evaluation should also include whether the service supports stronger access protections around the account and API layer, because weak account security can expose chat history even when transport is protected. NIST SP 800-63 Digital Identity Guidelines is relevant when access to the chat system depends on strong authentication, and NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference for access control, audit, and system integrity expectations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI 600-1, NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI 600-1 | Generative Artificial Intelligence Profile | Chat confidentiality depends on GenAI data handling, provenance, and disclosure controls. |
| Recommendation — Map chat retention and use policies to the GenAI profile and verify how plaintext is handled after decryption. | ||
| GDPR | Art.32 — Security of Processing | Chat content may include personal data and requires processing safeguards beyond transport encryption. |
| Recommendation — Apply security-of-processing controls to limit access, retention, and disclosure of chat content. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Access to chat history and provider consoles depends on strong authentication and session protection. |
| Recommendation — Use phishing-resistant authentication for accounts that can view or administer chat content. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Visibility into who accessed plaintext or chat history depends on auditable access and review. |
| AC-6 — Least Privilege | Provider and customer staff should only access chat content when their role requires it. | |
| Recommendation — Log and review access to chat content and administrative actions that can expose plaintext. Restrict chat-content access to the minimum set of authorized roles and functions. | ||
Practitioner Guidance
What to verify: Confirm whether the vendor can inspect plaintext, whether retention is configurable, and whether training or human review is enabled by default. If you cannot answer those three questions from the contract and admin console, do not treat the chat as confidential merely because HTTPS is in use.
Decision rule: If the content would be sensitive in a meeting room or email thread, assume it is sensitive in a hosted chat service unless you have explicit controls for retention, access, and downstream use. Transport encryption reduces interception risk, but it does not substitute for a data-handling decision.
What good looks like: The provider publishes clear retention and training terms, the tenant offers administrative controls for data use, and your team can show who may access chat history and for what purpose. If those answers are vague, treat the service as a processing environment, not a private envelope.
Practitioner takeaway: HTTPS protects the path, not the provider’s ability to process, store, or reuse the content, so confidentiality depends on governance and access controls after decryption, not on transport encryption alone.
Related resources from NHI Mgmt Group
- What breaks when AI coding agents can read web content and write local files?
- What breaks when AI assistants can read private repository context without strict content controls?
- What breaks when teams let AI agents read HAR files and console logs without content-level inspection?
- Why do indirect prompt injection attacks become more dangerous when AI agents can read and act on external content automatically?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
