GenAI Cloud Trust Boundaries And Ownership

Generative AI application security starts by fixing the trust boundary. A trust boundary is the line where a different operator or policy set can observe, change, or block a request.
In this course, we secure a GenAI application that sends prompts, retrieves private data, calls tools, and returns outputs. The security work differs from traditional apps because model inputs and outputs are not reliably separable from instructions.
We also treat model output as untrusted input to every downstream system that parses it or acts on it. That single assumption prevents many avoidable data exfiltration and tool misuse failures.

What we secure in a cloud GenAI app

A GenAI app has the same baseline surfaces as any web workload. It still needs identity, network segmentation, encryption, logging, and incident response.
A GenAI app adds exposures through prompts, retrieval context, tool arguments, and model outputs. Those paths can carry sensitive data even if the provider commits to not training on inputs.
The first job in threat modeling is to name the asset and the boundary that protects it. In GenAI, the most common high value assets are proprietary text, credentials, and tool capabilities.

Consumption modes and shared responsibility

Cloud responsibility shifts based on how the model is consumed. A consumption mode is the operational choice that decides who runs the model and who can access its runtime.
We can group the common modes into calling a hosted model API, customizing a managed model, building on a managed AI platform, and self-hosting model weights. Each step toward self-hosting increases what we must secure directly.
A provider can operate the model service and still be outside the application trust boundary. The application team still owns prompt handling, retrieval filtering, tool authorization, and output handling.
We can now inspect how ownership shifts across these modes.

Core trust boundaries we must name

We anchor the rest of the course on a small set of boundaries. Each boundary becomes a place to apply a control and later verify evidence.
Identity boundary means which principal can call an API and with what permissions. This boundary includes workload credentials, session scope, and authorization checks on every tool call.
Network boundary means where traffic can flow at the packet level. This boundary includes private connectivity, egress restrictions, and whether a service is reachable from the public internet.
Data boundary means which storage systems and logs can persist prompts, retrieved context, and outputs. This boundary includes retention, access control, and whether sensitive fields are redacted before logging.
Model artifact boundary means how model files, adapters, and containers enter the build and runtime. This boundary includes provenance, integrity, and dependency exposure during load and deployment.
Tool boundary means what actions the model can trigger through connectors, functions, or agents. This boundary includes per-action authorization and limits on what arguments can reach a tool.
External egress boundary means what data can leave to third parties, plugins, or the open internet. This boundary is critical because exfiltration needs an outbound path.
We can now visualize how prompts, retrieval, tools, logs, and egress cross these boundaries.