Private data and model access are often presented as two configuration screens: where the documents live and which models are enabled. In a production generative AI system, they are one trust-boundary problem. A user request can cause data retrieval, prompt assembly, model inference, logging, tool calls, and downstream actions. Every hop creates a place where authorization can become broader than the business intent.
The AIP-C01 security and governance scope is therefore best understood as a path question: which identity is acting, which resource is being accessed, which data is entering the model context, and what evidence proves that the boundary held?
A design can be “private” at the network layer and still be over-permissioned at the identity layer. It can use least privilege for model invocation while a retrieval role can read every document in the organization. Security comes from the composition of controls, not one setting.
Separate user identity, application identity, and service identity
The human user, the application runtime, and managed AWS services do not need the same permissions. The user may be authorized to ask a question about one department. The application role may be allowed to invoke a specific foundation model. A knowledge-base or data-source role may be allowed to read only the documents assigned to that workload.
Collapsing these identities into one powerful execution role simplifies early development but increases blast radius. If the application is compromised, the attacker inherits every permission the combined role carries. If a retrieval bug ignores a tenant filter, the service role may expose data the user was never entitled to see.
The least-privilege discipline described in AWS identity and data-protection design should therefore be applied separately at each boundary. Permissions should express the actual job of that identity, not the maximum capability the team might want later.
Model access is an authorization decision, not just catalog visibility
A production organization may approve some models for public data, others for confidential data, and a smaller set for regulated workflows. Model access should reflect legal terms, data-handling requirements, Region availability, cost, and risk appetite rather than being enabled uniformly because the model appears in a catalog.
Application roles should be scoped to the model resources and operations they require. A runtime that only needs inference does not automatically need administrative control over prompts, agents, knowledge bases, or model configuration. Separating build-time permissions from runtime permissions reduces the impact of compromised application credentials.
The current AWS Certified Security – Specialty perspective is useful because model endpoints are simply another sensitive service boundary. Identity policies, resource policies where available, organization controls, and audit evidence all contribute to the effective permission.
Private networking reduces exposure but does not replace authorization
Interface VPC endpoints can keep service traffic on private AWS networking paths and avoid internet gateways for workloads that require that boundary. Endpoint policies can also narrow which principals, actions, and resources are allowed through the endpoint. Those controls are valuable, but they should not be mistaken for user authorization.
A workload inside the right VPC can still be using an over-privileged role. A compromised function can still call a model it should not use if IAM allows it. Conversely, a perfectly scoped IAM role can still send sensitive prompts through an architecture that violates an organization’s network policy. The controls address different failure modes.
Network design should therefore follow the data-flow diagram. Which subnets host the application? Which services require private endpoints? Where can data leave the VPC? Which DNS path resolves service endpoints? Which egress paths are still present? The answer should be explicit enough to test.
Retrieval authorization must survive the move into vector search
RAG creates a subtle data problem because the searchable representation is derived from source documents. If access rules exist only in the source repository but not in retrieval metadata or index design, the application may retrieve a passage the current user cannot read directly.
Multi-tenant and department-scoped systems should carry authorization context into retrieval. That may mean separate indexes, document-level metadata filters, application-side policy checks, or a combination. The important point is that “the vector store contains it” is not authorization.
Deletion and revocation must also propagate. Removing access to a source document should eventually remove or block its derived chunks, embeddings, caches, and logged content. Otherwise the AI layer becomes a stale copy that outlives the control on the source system.
Encryption decisions should include derived and logged data
Organizations often encrypt the source documents and then overlook embeddings, vector indexes, prompt logs, evaluation datasets, or traces. Those artifacts can reveal sensitive information even when they do not look like the original document.
Encryption at rest, encryption in transit, key policy, and key access should cover the whole lifecycle. AWS KMS and Secrets Manager make those controls concrete when keys, secrets, and application credentials have different owners and rotation requirements. If customer-managed keys are required, operations must also understand what happens when a key is disabled, rotated, or permissioned incorrectly. Security controls have availability consequences.
This is why broad AWS security foundations remain important in GenAI systems. The model changes the application behavior, but data classification, encryption, secrets management, logging, and access review still determine whether sensitive information is controlled.
Logs and evaluation data can become a shadow data store
Detailed model logs are excellent for debugging, but they can capture prompts, retrieved passages, outputs, tool arguments, and user identifiers. A team may secure the primary document repository carefully while giving far broader access to observability data that contains excerpts of the same information.
Logging policy should define what content is captured, how it is redacted, who can read it, how long it is retained, and whether production samples can be exported to evaluation systems. Security teams should review the data path into analytics and testing tools just as they review the inference path.
The same issue appears in regression datasets. A failure example copied from production may contain confidential context. Sanitization or controlled storage is required before it becomes a long-lived test artifact.
Access reviews should follow actual use
Static IAM review can identify obvious over-permission, but production evidence adds another dimension. Which roles actually invoke which models? Which data sources are read? Which tools are called? Which permissions have never been used? That evidence can support permission reduction and detect unexpected behavior.
Changes also need ownership. Enabling a new model, expanding a retrieval role, adding a VPC endpoint, or changing a key policy can all alter the effective boundary. High-impact environments may require approval or separation of duties so the developer who wants broader access is not the only person validating the risk.
The objective is continuous confidence rather than a one-time secure configuration. Access patterns drift as applications grow, and the review process has to keep pace.
A strong design can explain every boundary in one request
Take one real request and trace it. Which human identity initiated it? Which application role handled it? Which model was allowed? Which documents could retrieval access? Which network path carried the call? Which key protected stored data? Which logs recorded the event? Which policy would stop an unauthorized variant?
If those questions can be answered precisely, the architecture has a defensible security model. If the answer is “the application role has broad access but the network is private,” the design is relying on one boundary to compensate for another.
Private data and model access are therefore governance questions as much as configuration questions. The goal is to keep authorization, network reachability, data lineage, encryption, and evidence aligned with the same business boundary from the user request all the way through inference and storage.
Threat modeling should include the control plane as well as the data plane. A runtime request may be tightly restricted while an administrator can broaden model access, replace a knowledge-base role, or change a key policy without review. Those changes can silently invalidate the assumptions the application relied on. Governance needs controls around who can modify the boundary, not only who can use it.
Cross-account designs make ownership especially important. Central platform teams may host models or shared retrieval services while business units own the source data. Resource policies, trust policies, and organization controls should make clear which account can delegate access and who is responsible for revocation. Ambiguity becomes dangerous during incidents because each team may assume the other owns the control.
Data minimization is another boundary. Even an authorized model call should receive only the information required for the task. Retrieval filters, field selection, redaction, and prompt construction can reduce the amount of sensitive material placed in context. Least privilege applies to data volume as well as API permissions.
Finally, incident response needs a containment path. Teams should know how to revoke a model role, disable a compromised data source, invalidate credentials, block an endpoint, or stop logging sensitive content without waiting for a full application redeploy. A security design is stronger when its boundaries can be narrowed quickly under pressure.
Vendor and model changes should trigger a boundary review too. A workload may move from one foundation model to another for quality or cost reasons, but different providers can have different Regions, service terms, access prerequisites, and logging behavior. Model routing must stay inside the data-use policy rather than treating every approved model as interchangeable.
Governance also needs an evidence-retention decision. Audit data should be kept long enough to investigate incidents and prove control operation, but not so long that detailed prompt traces become an unnecessary archive of sensitive information. Retention periods should follow the risk and compliance purpose of the data.
Periodic tabletop exercises can validate that the people, permissions, and containment steps actually work together when the boundary is under pressure.
