Anton Staykov

Posted on Sep 22

Encryption in transit is not end-to-end encryption: block unsanctioned GenAI access

#security #ai #privacy #azure

Encryption in transit is not end-to-end encryption

The distinction is simple and it matters more in GenAI than in most other areas of technology. TLS protects a connection while data is moving across a network segment. It does not mean the application data is protected from every intermediary that handles the request. A reverse proxy, gateway, WAF, or API layer can terminate TLS, inspect the payload, and then forward it onward. That is still encryption in transit. It is not end-to-end encryption.

This is the real security question behind the AI risk conversation. If an employee pastes a secret into a third-party AI assistant, the data leaves the trust boundary of the organization. At that point, the provider, the proxy, and any downstream service can observe, store, or process it. The issue is not whether the connection was protected while it crossed the public Internet. The issue is whether the organization still controls the data lifecycle.

NIST describes TLS as protecting data during electronic dissemination across the Internet in the classic sense, and that is accurate. But it is not the same as saying the data remains protected from every system that participates in the request path. NIST SP 800-52 Revision 2 is careful about transport security, not end-to-end application protection.

There is a quiet assumption baked into many security conversations, and it usually goes unspoken: if the data is encrypted on the wire, the problem is solved. It is not. The network path can be encrypted on every hop while the gateway still sees the plaintext. That is the core distinction.

The common gateway topology looks like this:

sequenceDiagram
    participant Client as Browser/App
    participant Gateway
    participant Backend
    Client->>Gateway: TLS connection 1
    Note over Gateway: TLS terminates here<br/>plaintext exists here
    Gateway->>Backend: TLS connection 2

That diagram has two separate cryptographic relationships. The browser is not cryptographically protected all the way to the backend service. It is protected to the gateway, and then the gateway creates a second protected connection to the backend.

TLS connection 1:
Browser/App <=================> Gateway

TLS connection 2:
Gateway <=================> Backend

That is a valid transport-security architecture. It is not an end-to-end content-protection architecture.

True end-to-end encryption protects the payload from the gateway

End-to-end encryption changes the location of the cryptographic boundary. The gateway can still route the request, enforce some policy, and observe metadata. It cannot decrypt the protected application payload.

sequenceDiagram
    participant Client as Browser/App
    participant Gateway
    participant Backend as Backend Service
    Client->>Client: encrypt(payload, backend key)
    Client->>Gateway: TLS plus encrypted payload
    Note over Gateway: Gateway transports ciphertext<br/>Gateway cannot decrypt
    Gateway->>Backend: TLS plus encrypted payload
    Backend->>Backend: decrypt(payload)

In that model, the application content is protected before it reaches the gateway. The gateway sees an HTTP request, but the sensitive body is opaque unless it has the backend-controlled decryption material.

{
  "payload": "BASE64_ENCRYPTED_BLOB..."
}

The gateway might see routing data and headers like this:

POST /api/messages
Host: service.example
Authorization: ...
Content-Type: application/octet-stream

8gh29HFn4k...     <-- opaque encrypted content

That distinction is not academic. It determines whether the gateway is a reader of the data or a carrier of ciphertext.

Architecture	Data encrypted on wire?	Gateway sees plaintext?	E2E encrypted?
Client -> TLS gateway -> HTTP backend	Partially	Yes	No
Client -> TLS gateway -> TLS backend	Yes	Yes	No
Client encrypts payload -> gateway -> backend decrypts	Yes	No	Yes

The gateway is the control plane, not just a door

This is where the real security story starts. A gateway is not merely a convenience layer between users and services. It is often the central choke point for policy enforcement, authentication, logging, routing, and transformation. In enterprise architecture, that makes it a high-value concentration point for sensitive data and a privileged path to the Internet.

The design pattern is common across Azure and enterprise stacks. An application gateway, API gateway, or reverse proxy does not just pass traffic. It terminates connections, reads headers, inspects payloads, enforces policies, and often writes transaction metadata to logging, monitoring, and analytics systems. Azure Application Gateway TCP/TLS proxy overview describes exactly this behavior: the gateway acts as a reverse proxy and can proxy TCP and TLS traffic as part of the service architecture. In API management terms, the platform sits in front of backend APIs and shapes how traffic moves and is governed. What is Azure API Management? describes the gateway as an operational control layer, not just a network convenience.

That matters because gateway functionality is never isolated from data exposure. The same component that handles TLS, routing, and policy enforcement also sees the application content unless the design explicitly encrypts beyond that boundary. If the gateway is visible to the enterprise as a single control point, then the enterprise also has to treat it as a single blast-radius concentration point.

This is the part many organizations miss. Endpoint controls are designed for the client devices, not for the central trust boundary that sits between the organization and the Internet. The endpoint can be managed, patched, and monitored. The gateway is different. It is a shared service used by many applications and many users. It often sits near the edge of the trust boundary, and it often has deep visibility into the same data that the browser or mobile app sends.

That makes the gateway a strategic security object. It is both:

a concentration point for highly valuable company information, because it sees data from many users, workloads, and applications, and
a gateway to the Internet, because it provides the path that traffic uses to leave the enterprise boundary.

If you treat the gateway as purely an infrastructure detail, you miss the real architectural risk. You are treating a privileged control plane as if it were just a traffic relay.

The trust boundary is the thing that matters

The key concept here is the trust boundary. A prompt sent to a public AI assistant crosses the enterprise trust boundary whether or not the network path is encrypted. In many cases, the user is not just calling a service. They are handing their data to a third party and the provider decides what it does with the data next. The organization may not control the log retention, model training settings, contract terms, or retention policy.

The same architectural reality appears in an internal enterprise API gateway. If a backend service has to see customer data to do its job, then the gateway is an important intermediary but not the authoritative security boundary. The real security question is where the data becomes visible and who can access it.

This is exactly why the phrase "encrypted in transit" is not enough. It says the data is protected while traveling between endpoints. It does not say the data is protected from the endpoints themselves. A TLS connection between browser and gateway and then between gateway and backend can be secure and still leave the gateway in the clear. The gateway can observe the plaintext, and that is enough to change the risk model.

The honest answer is that you do not need a single broken protocol to create a dangerous exposure pattern. You need a better boundary model.

Why the GenAI risk is different

The GenAI category widens that problem because it combines two factors that are easy to ignore when taken separately:

employees are under pressure to move quickly and show productivity, and
the AI assistant experience is designed to feel like a normal consumer product, not a corporate system with controls.

That combination is toxic. People paste code, customer data, pricing files, internal proposals, and architecture notes into tools that are not part of the approved enterprise trust domain. Sometimes it is a free tier. Sometimes it is a personal subscription. Sometimes it is because the company license is exhausted or the app is simply more convenient. Sometimes it is because the employee is trying to solve a real business problem under pressure and there is no policy or review path.

This problem is not theoretical. The recent AI supply-chain and exposure stories show the broader pattern: the path to an AI model is no longer just an application call. It is a software supply chain, a routing layer, a credential boundary, and sometimes a logging sink. The article about the LiteLLM compromise describes a malicious package supply-chain story in which compromised open-source tooling resulted in secrets theft and credential exposure from CI/CD and runtime environments. The investigation is presented as a real-world supply-chain incident, with the article citing forensic research from Snyk, Trend Micro, and Cycode and describing the malicious package behavior in detail. InfoStealers on the LiteLLM incident and the linked Snyk, Trend Micro, and Cycode coverage point to the same risk class: if a tool sits in the path to the model, it becomes part of the exposure surface.

The Pandaily story about a reported 6 TB LLM router log data exposure should be treated carefully. It is not the same as a definitive forensic closure on every claim, but it reinforces the same basic truth: AI router layers, model gateways, and data processing intermediaries are becoming valuable operational targets. Pandaily claim on LLM router logs is a useful cautionary example even if the final attribution and scope remain contested.

The broader point is not that every AI service is malicious. The point is that once a prompt, file, or API key crosses into an unvetted service, the organization no longer controls the trust boundary. The data becomes part of a new processing environment with a different contract, a different logging model, and a different risk posture.

This is why the enterprise question is not "does this service use TLS?" It is "what is the data-handling contract and where is the trust boundary?"

Strong AI governance already has an identity plane

The governance answer is not only "block the app." It is also "move the control plane to the identity layer." Microsoft Entra Global Secure Access gives organizations a cloud-delivered security service edge that can enforce policy around private and internet access based on identity-aware controls, rather than relying only on endpoint posture. What is Global Secure Access? frames the problem in exactly this way: the modern workforce needs an identity-aware, cloud-delivered network perimeter.

That matters because AI governance is not just a DLP conversation. It is also an access-governance conversation. What is entitlement management? describes how organizations can automate access request workflows, assignments, reviews, and expiration across apps, groups, and SharePoint resources. Governance fails when access is granted on an ad hoc basis and never reviewed. Entitlement management is how you turn AI access into a time-bound, auditable trust decision.

And the last layer is user authentication. If the employee is authenticating with a phishing-resistant method such as a passkey, Face ID, or Windows Hello, the enterprise is materially reducing the chance that the decision to use a third-party AI tool is driven by a credential theft event. Passwordless authentication in Microsoft Entra is the modern model here: secure, modern credentials reduce the risk that a weak human factor becomes the path into an unauthorized AI workflow.

You do not solve unsanctioned GenAI risk by adding one more checkbox to a policy page. You solve it by combining: a real trust boundary, policy enforcement at the edge, time-bound access, and phishing-resistant identity. That is how you turn a convenience problem into a governed control plane.

The real answer is not a policy slogan. It is a system design rule

Most organizations already know the first half of this story. They know they should not permit employees to dump customer data into a random public AI tool. The harder question is how to make that true in practice without breaking productivity.

The answer is simple but not trivial: build an approved AI path and block the rest.

That means a clear policy that treats unsanctioned GenAI like a data exfiltration control issue, not an employee-choice convenience issue. It means approved enterprise services with explicit contracts, data handling statements, and retention boundaries. It means DLP rules that detect prompts, attachments, and API keys. It means browser and network controls that prevent direct access to unapproved AI endpoints. It means a governance process that makes it easy to use the sanctioned tool and hard to use the unsanctioned one.

This is also where the gateway again becomes central. If the gateway is the high-value choke point, then the policy should be enforced there. If an organization treats the gateway as a neutral network device, it will miss the operational fact that the gateway is one of the highest-value security assets in the environment. The gateway is where you can identify unauthorized model traffic, inspect prompts in transit, block exfiltration, and enforce control-plane policy at the edge. That is not a minor operational detail. It is a foundational design decision.

The issue is not that "maybe one employee clicked the wrong thing." It is that the gateway is already the place where a lot of sensitive information is concentrated. Endpoint controls do not apply to the gateway. Endpoint controls do not protect the shared trust boundary. They protect the device. The gateway is not the device. The gateway is the enterprise chokepoint.

This is why the right default posture is to ask a sharper question before approving a new AI use case:

what data crosses the enterprise boundary?
which service receives it?
what logging and retention obligations are in force?
what downstream processing and model training settings apply?
what is the contractual and legal boundary for the data?

If the answers are vague, the answer is no. If the service is not part of the approved enterprise trust domain, it should not receive business data.

And that means the governance question is not about the browser. It is about the trust contract

A lot of AI governance conversations still focus on the user experience. They ask whether a feature is easy to use, whether employees can paste a prompt into a chat box, and whether the assistant is helpful. That is not the right security frame. The question is whether the organization is handing data to a service that it can trust, monitor, and govern.

That is the point behind the Azure AI guidance: approved enterprise services are designed around data boundaries and customer data handling commitments. Data, privacy, and security for Models sold by Azure in Microsoft Foundry lays out the important contract: Microsoft explicitly states that Azure OpenAI does not use customer data to retrain models for the foundation model service, which is a materially different security and governance posture from a personal or unsanctioned AI app.

The organization is not just buying a productivity feature. It is buying a trust contract. A service that does not provide a clear data-handling boundary cannot be treated as a sanctioned enterprise AI tool just because it is convenient.

The policy implication is direct. If you do not have a clear control plane, a policy boundary, and a trusted data-handling contract for the AI service, then the enterprise should not allow business data into it. That is the architectural rule. The app might be encrypted. The gateway might be protected. The logs might be clean. But if the organization does not control the data lifecycle, it does not control the risk.

The gateway is a privileged point in your architecture. You should design around it as if it were a crown jewel. If it sits on an unsanctioned AI path, the enterprise data is already outside the trust boundary. That is not a training issue. It is a governance issue.

DEV Community