AIP-C01 Data Security and Privacy: Private Bedrock Networking, PII Detection, Masking and Retention

A protected FM environment keeps inference traffic off the public internet by giving each AWS API the application calls its own interface VPC endpoint (AWS PrivateLink), with private DNS enabled so the SDK's default Regional endpoint name resolves to the endpoint's private IP addresses. With private DNS on, existing code works unchanged; with it off, the default name still resolves to public addresses and the code must be changed to use the endpoint-specific DNS name. Adding a NAT gateway also "fixes" a timeout, but it gives the subnets an internet route, which a private-subnet requirement rules out.

Amazon Bedrock is not one endpoint. Each API family has its own service name, and a private subnet needs an endpoint for every family it calls:

An endpoint for one family carries no traffic for any other, so the set of endpoints must match the set of API families the code calls. Endpoint policies and the aws:SourceVpce condition for inference calls are covered in the Domain 2 lesson on secure integration; this task focuses on what else has to be private.

Batch inference inside your VPC

A batch inference job reads its input from S3 and writes output to S3 on your behalf. To make those reads and writes run from inside your VPC, set vpcConfig (subnets and security groups) in CreateModelInvocationJob; Bedrock then places elastic network interfaces in your subnets for the job. Two details matter: the VPC setting is currently available through the API rather than the batch console page, and the job's service role needs the EC2 network-interface permissions to create and manage those interfaces. To make the bucket reachable only through the VPC, add an S3 gateway endpoint and a bucket policy that denies requests whose aws:SourceVpce is not that endpoint. Encrypting the bucket protects the data at rest but does nothing about the network path.

Self-hosted models on SageMaker AI

For a model hosted on a SageMaker AI endpoint, two different directions need protecting:

• Clients reaching the endpoint. InvokeEndpoint is a SageMaker AI runtime call, so private subnets need an interface endpoint for sagemaker.runtime (with private DNS for unchanged code). The sagemaker.api endpoint serves control-plane calls such as CreateEndpoint.
• The container reaching anything else. A model VpcConfig places the container in your subnets, but it can still reach resources and endpoints inside the VPC. Setting EnableNetworkIsolation on the model removes all outbound network access from the container, including calls to other AWS services, and the container receives no AWS credentials. SageMaker AI still downloads the model artifacts from S3 for it, outside the container, using the execution role.

Isolation is a network restriction, not a permissions one: no request leaves the container, whatever the roles and policies allow. So everything the inference code needs at run time must be packaged inside the model artifact (model.tar.gz referenced by ModelDataUrl), which SageMaker AI fetches on the container's behalf.

An Amazon OpenSearch Serverless collection behind a Bedrock knowledge base is protected by three separate layers, and each answers a different question. Confusing them is the usual mistake.

To make a collection private, set AllowFromPublic to false and list the sources allowed in. Your own applications reach it through an OpenSearch Serverless VPC endpoint in their VPC (a function in a private subnet with no NAT has no other path). Bedrock does not come through your VPC endpoint: it reaches the collection as an AWS service, so the policy must also list bedrock.amazonaws.com in SourceServices. Leave it out and knowledge base syncs and Retrieve calls fail even though nothing changed in the data access policy. Note also that whenever AllowFromPublic is true, any SourceVPCEs and SourceServices in the rule have no effect: the collection is public.

Principal-level access is the data access policy's job, because only it names principals and operations; a network policy names sources. Least privilege means one role per kind of user: a role that only reads gets aoss:ReadDocument on the index in the data access policy plus aoss:APIAccessAll in its IAM policy, while the knowledge base's service role keeps the write rights ingestion needs and is assumed only by Bedrock.

A PII-masking guardrail protects only the calls it applies to, so a protected environment needs a way to make it unavoidable. There are three mechanisms, and they behave very differently towards callers that do not name a guardrail.

Merely allowing a guardrail ARN in a role's policy does nothing: a guardrail acts only when a request names it or when it is enforced.

Limits of the IAM condition key

The condition key inspects which guardrail a request names, not what content is evaluated. Two consequences follow:

• RetrieveAndGenerate and InvokeAgent break on a role that carries the deny. These operations make several InvokeModel calls on the caller's behalf, and some of those internal calls carry no guardrail, so they match the deny and the request fails with AccessDenied. The problem is that those internal calls name no guardrail at all, so any deny on this key that applies to the role catches them. Run those operations under a separate role without the deny (or use an enforced guardrail instead).
• Input tags can narrow evaluation. Callers can wrap only part of their prompt in guardrail input tags, and then only the tagged text is evaluated. A caller who tags just the instruction text lets pasted records through unchecked.

Selective versus comprehensive content guarding

Enforced guardrails (account-level and Organizations policies) have selective content guarding controls, set separately for system prompts and for messages. Selective honours the callers' input tags (cheaper, less text evaluated); comprehensive evaluates all content of that kind and ignores the tags. Comprehensive is the default. The two Selective controls treat an untagged request differently: the system control then evaluates no system-prompt content, while the messages control evaluates all message content. That asymmetry is why the system control exists as a separate setting. Because the controls are independent, set each one to comprehensive for the kind of content whose callers' tagging you cannot rely on.

A secure data access pattern means the scope of what an FM application can read is decided by verified identity and enforced by an AWS service, never by the model, the prompt or a value the client can edit.

Tenant isolation in a shared knowledge base

When many tenants share one knowledge base, each document carries a metadata attribute such as tenantId. The backend must:

1. Take the tenant from verified identity, for example the claims of a validated Amazon Cognito token, not from a request body field the client sends.
2. Pass an explicit metadata filter (for example an equals filter on tenantId) in the Retrieve call's vector search configuration. The retrieval service applies it, so only that tenant's chunks can come back whatever the question says.

Two tempting alternatives are not controls: implicit filtering (the model derives filters from the user's question, which a crafted question can steer) and a prompt instruction to "stay within the tenant" (the other tenant's chunks have already been retrieved by then).

Per-tenant knowledge bases with one role (ABAC)

When each tenant has its own knowledge base, IAM can enforce the boundary so that even a bug in the function cannot cross it. Tag each knowledge base (tenant=<id>), have the function assume one shared role with a session tag carrying the verified tenant ID, and allow bedrock:Retrieve only where aws:ResourceTag/tenant equals ${aws:PrincipalTag/tenant}. This is attribute-based access control: one role instead of a role per tenant, and a check that application code cannot skip. A wildcard Retrieve permission plus an if statement in code is exactly what a bug bypasses.

Per-user rows in DynamoDB

For chat history read directly by clients with Cognito identity pool credentials, use the dynamodb:LeadingKeys condition set to ${cognito-identity.amazonaws.com:sub} so each request can touch only partitions whose key is the caller's identity ID. This is the condition key that ties item ownership to identity; it is evaluated on every request, so no application code has to check it.

AWS Lake Formation for data that agents query

When an agent's action group queries a data lake through Amazon Athena, Lake Formation provides central, fine-grained permissions that Athena enforces for the role, so no per-query code is needed:

• Column grants include or exclude columns of a table.
• Data filters (data cell filters) combine column exclusion with a row filter expression, giving cell-level security, for example hiding a salary column and returning only the rows for one department. Column grants alone restrict columns, never rows.
• LF-tags scale grants: grant SELECT on an LF-tag expression such as sensitivity=low and every current and future table carrying that tag is covered. The grant applies only once a table has the tag, so the process that creates tables must also tag them.

IAM cannot express column-level access to catalog tables. And a classic misconfiguration makes filters silently ineffective: while the table still grants Super to IAMAllowedPrincipals (the compatibility default for resources governed by IAM alone), any principal with IAM permissions such as glue:GetTable and s3:GetObject reads the full table and no error appears. Remove that grant to switch on Lake Formation permissions. Principals that query governed data also need lakeformation:GetDataAccess in IAM, which lets Lake Formation vend temporary credentials for the underlying S3 data.

Monitoring data access means recording who read the data an FM application depends on and alerting quickly when the wrong principal does. The building block is CloudTrail delivered to CloudWatch Logs, with a metric filter on the caller identity and a CloudWatch alarm on that metric, which fires within minutes.

What you can alarm on depends on which CloudTrail events the trail records:

Three rules follow. A trail that logs management events only never shows who read an object or who queried a knowledge base. KMS Decrypt is recorded only when the trail records read management events and does not exclude AWS KMS events, so any alarm built on key usage depends on both settings staying that way. And the KMS calls S3 makes on your behalf are KMS events, not S3 data events; with S3 Bucket Keys enabled, S3 calls KMS far less often, so Decrypt events do not map one-to-one to object reads.

Each neighbouring record answers its own question:

Using these logs as a governance audit trail and for source attribution is covered in the Task 3.3 lesson.

Amazon Comprehend detects PII in text you send it; Amazon Macie discovers sensitive data in objects stored in Amazon S3. Pick by where the data is and what you need back.

Amazon Comprehend PII operations

The asynchronous redaction job has two mask modes: MASK replaces each entity with a mask character (such as *), and REPLACE_WITH_PII_ENTITY_TYPE replaces it with its type label (such as [NAME]). Choose the second when downstream readers or models need to know what kind of value was removed. The job is the managed way to redact large volumes of documents in S3 without writing or scaling code. Comprehend PII detection supports English and Spanish text, so other languages need another approach.

Amazon Macie for knowledge base data sources

Before S3 buckets become knowledge base data sources, Macie answers "which buckets and objects contain personal data?". Automated sensitive data discovery continually samples buckets across the account, including new ones, with no scanning code; sensitive data discovery jobs give targeted, scheduled or one-time scans. Macie's managed data identifiers cover standard types (passport, bank account, card numbers and so on). For an internal format such as an employee ID, create a custom data identifier (a regex, optionally with keywords).

Know what Macie does not do:

• It does not redact or move objects. It publishes findings to Amazon EventBridge; a rule that invokes a Lambda function provides remediation, such as moving a flagged object out of the data source prefix before the next sync.
• Allow lists define text Macie should ignore, and suppression rules automatically archive matching findings; both exist to reduce noise.
• It analyzes S3 objects only, not CloudWatch Logs log groups.

A guardrail's sensitive information filter detects PII in prompts and responses and acts on it per entity type (predefined entities such as NAME, EMAIL, PHONE, credit card or national ID numbers) or per regex you define for custom identifiers. Each entry has separate input and output actions:

Choosing per direction is the core skill. If the model needs a caller's details to do its job but saved output must not contain them, set input to NONE and output to ANONYMIZE. Predefined entities recognise standard formats only, so an organization's own identifier formats (an internal reference made of a fixed prefix and digits, say) need a regex entry, which takes the same per-direction actions. (Harmful-content filters, denied topics and prompt-attack defence are covered in the Task 3.1 lesson.)

What the filter does not see

• Tool traffic. In a Converse tool-use loop, the guardrail evaluates user prompts and model text, not tool specifications, tool call arguments (toolUse.input) or tool results (toolResult). PII returned by one tool can be copied by the model into the next tool's arguments untouched, and no trace entry will show it. Your application executes the tools, so run the arguments (or results) through the standalone ApplyGuardrail API and pass on only the masked text.
• Model invocation logs. Guardrail masking changes what the model and the user see, but the invocation log always records the original request input. That is true whatever action the filter takes.

Masking PII in CloudWatch Logs

To keep invocation logs (auditors need them) while hiding the values, attach a CloudWatch Logs data protection policy to the log group (or an account-level policy). It masks matching data identifiers as events are ingested, at every egress point including Logs Insights, subscriptions and metric filters, and only principals with logs:Unmask can view the raw values. Behaviours to know:

• It never rescans stored events. Masking applies only to events ingested after a policy takes effect, at any level. Older events must age out through log group retention or be deleted.
• Encryption and masking are different controls. A customer managed KMS key on the log group decides who can read the log group at all; the data protection policy decides who sees the sensitive values within it (logs:Unmask).
• Alerting needs no code. The policy emits the LogEventsWithFindings metric in the AWS/Logs namespace (alarm on it), and its audit operation can send findings reports, listing which identifiers matched, to CloudWatch Logs, Firehose or S3.

Amazon Bedrock's built-in privacy guarantees are on by default: it does not use prompts or completions to train AWS or third-party foundation models, and models run in model deployment accounts owned by Bedrock that the model providers cannot access, so providers never see your inference data. These guarantees need no configuration. Model invocation logging is off by default and, when on, writes only to your own CloudWatch Logs or S3.

Data retention modes

"Not used for training" is not the same as "never stored". Bedrock now has explicit account-level data retention modes that govern whether AWS keeps inference data: none, default and aws_review (plus inherit, which falls back to each model's default, and a legacy provider-sharing mode). Points that matter:

• The mode is set per account and per Region (PutAccountDataRetention); setting it in one Region does not carry to another.
• Only none means zero retention; under default, AWS can still retain inference data for abuse detection.
• On the newer bedrock-mantle endpoint, a project-level setting can override the account. The effective mode is the first value that is not inherit, checked in the order project, account, model default. Some models support only none and never retain data whatever the setting.
• To stop administrators changing it, add a service control policy that denies bedrock:PutAccountDataRetention unless the bedrock:DataRetentionMode condition key equals the approved mode.
• Some models require aws_review (human review for abuse detection). Under none or default those models are unavailable: calls fail with a ValidationException. Plan for that side effect.

Invocation logging is storage in your own account and has no bearing on what AWS retains.

Encryption with keys you control

Bedrock encrypts custom models with an AWS owned key by default; you can neither audit its use nor disable it. To audit every use of the key protecting a fine-tuned model and to be able to make the model unusable by disabling a key, specify a customer managed KMS key as the custom model encryption key on the model customization job. Keys on the training data and output buckets are separate settings that protect those S3 objects; the model's own key is chosen on the customization job. Knowledge bases, agents and their resources (such as RetrieveAndGenerate session data and ingestion intermediates) can likewise use customer managed keys.

A data retention policy is enforced by the storage service's own expiry mechanism, so deletion happens automatically and provably without a scheduled cleanup job. Each store has its own mechanism:

S3 Lifecycle in versioned buckets

Expiring the current version in a versioned bucket does not delete data: it adds a delete marker and the data becomes a noncurrent version. Corrections to an object also leave older noncurrent versions. To truly delete after N days while versioning stays on, combine expiration of current versions with NoncurrentVersionExpiration (permanently delete noncurrent versions after a short period). Storage-class transitions move data rather than remove it, and "retention" in S3 Object Lock means the opposite of expiry: it prevents deletion until a retain-until date and never deletes anything itself.

Lifecycle rules select objects by prefix, object tags or size; user-defined metadata is not a supported filter. When objects that share a prefix need different retention periods, have the writer tag each object with its retention class and create one rule per tag value; tagging leaves the object keys unchanged.

Logs and chat history

For invocation logs in CloudWatch Logs, set the log group's retention; it deletes events once they are older than the period, including events already stored. For conversation memory in DynamoDB, store an expiry timestamp attribute (epoch seconds) and enable TTL; DynamoDB deletes expired items in the background, at no write-capacity cost, so no scheduled cleanup code is needed.

Privacy-focused design removes identifying values from what the FM sees while keeping exactly the information the task needs. The technique depends on whether the real values must come back and whether the model must tell individuals apart:

Reasoning through the choices:

• If the final output must contain real names or account numbers, swap each value for a consistent token (the same customer keeps the same token), keep the mapping in an encrypted, access-controlled table, and restore values in the application after the FM call. Restore by finding each token in the generated text: the output is new text, so offsets from the input do not apply to it.
• If the model must keep parties apart (who said what in a multi-party conversation), type labels and mask characters destroy the distinction; numbered placeholders keep it.
• If no one may be able to re-identify individuals, tokens are not enough, because tokenization is pseudonymization: the map holder can reverse it. Send the derived fact the task uses, computed in code, such as an eligibility category instead of the record it was derived from. Whatever transformation you choose must preserve that fact exactly; one that destroys or distorts it makes the output wrong.
• Anything in the prompt, system prompt included, is sent to the model; an instruction not to repeat a value does not protect it.

Keeping PII out of the vector store

For RAG, redaction must happen before embedding. Masking answers with a guardrail on RetrieveAndGenerate is too late: the raw values are already stored in the vector index. If the original files must stay unchanged and you do not want a second redacted copy, add a custom transformation Lambda function to the knowledge base's ingestion (customTransformationConfiguration, typically at the post-chunking step, using an intermediate S3 location); it redacts each chunk's text, so only redacted text is embedded and indexed. Alternatives fit other constraints: a Comprehend redaction job that writes redacted copies to a separate prefix when a second copy is acceptable, and a Macie-plus-EventBridge gate that moves flagged objects out of the data source. Whatever the method, the test is the same: the raw value must never reach the vector index.