AWSAWS Certified Generative AI Developer - Professional2026-103.2 Implement data security and privacy controls
Sanitize logs before exporting agent traces
Completed by the knowledge check
Learning objective
Redact PII and sensitive tool parameters from application logs and agent traces independently of Bedrock invocation logs.
Core idea
For an architect operating an agent, observability creates its own disclosure path. A safe user-facing answer can coexist with an unsafe log entry containing the original prompt, a tool credential, or a customer identifier. Disabling Bedrock model invocation logging does not disable the application’s logger or its trace exporter.
Treat logging as a consumer with an explicit data contract. Decide which fields operators need, remove disallowed values before serialization, and inspect each destination independently. Bedrock invocation logging is covered in 3.2.8; this lesson addresses the copies your application produces around model and tool execution.
How it works
Map the independent copies
A request can pass through application request logs, model adapters, tool adapters, exception handlers, and trace exporters. Each can serialize content before another component masks it. A debug logger can also expose a complete request object even when the normal operational event contains only safe metadata.
Define an application event schema with approved fields such as an opaque operation identifier, tool name, status, elapsed time, and policy version. These are design choices, not AWS-defined event fields. Keep free-form prompts, response bodies, authorization headers, and tool parameters out of the default event. A field called metadata is not safe if callers can put arbitrary text in it.
Prefer an allowlist to serializing a whole object and then searching for known secrets. A tool’s typed contract can identify a sensitive field more reliably than a detector recognizes its value. A password or internal account key remains sensitive even if no PII model matches it. Keep authorization and tool validation in the mechanisms described in 2.1.10 and 3.2.2; log sanitization complements those boundaries.
Sanitize Bedrock agent traces explicitly
For Bedrock Agents, InvokeAgent enables tracing through enableTrace: true. Trace output describes reasoning and orchestration, including action-group inputs and outputs and knowledge-base queries and results. It is valuable debugging material precisely because it can contain the content that drove a decision.
Inspect the documented structures before deciding what to export. OrchestrationTrace.invocationInput.actionGroupInvocationInput can carry parameters with name, type, and value, and a requestBody. Model invocation inputs and observations can also contain free-form text. Do not restrict sanitization to the top-level user question while exporting the nested tool payload unchanged.
Build a projection of the trace rather than forwarding the raw response. Retain approved structural identifiers and outcomes, and replace or omit sensitive parameter values and content-bearing fields. An opaque trace identifier can preserve correlation without storing the tool payload. Decide whether session identifiers are linkable personal data in your application before exposing them broadly.
Turning off enableTrace reduces collection through this response path, but it does not sanitize logs your tool adapters already emitted. Conversely, enabling trace for a bounded debugging session does not require making the complete raw trace an ordinary operational log. Your exporter owns that release boundary.
Account for Guardrails originals
Bedrock Guardrails sensitive information filters evaluate prompt and response text, but exclude tool-call arguments, tool results, and tool definitions. Those excluded fields can contain identifiers that later appear in application logs or trace events. An authorized tool can legitimately receive a value that the operational logger should never retain.
Guardrails also expose original PII through detection results. The documented GuardrailPiiEntityFilter.match field contains the original value rather than the masked replacement. Its action can report ANONYMIZED, BLOCKED, or NONE; an ANONYMIZED result does not make the whole assessment object safe to serialize.
The sensitive-information documentation separately states that the invocation-log input contains the original unmodified request. Therefore, implement distinct controls for application events, agent trace projections, Guardrails assessment output, and invocation-log destinations. A shared redaction library can enforce your application schemas, but it cannot retroactively rewrite every service-managed copy.
Add CloudWatch data protection as another layer
CloudWatch Logs data protection policies audit and mask sensitive data that matches selected managed or custom data identifiers. You can apply policies at account or log-group scope. The policy’s Audit operation reports matches; its Deidentify operation masks them. PutDataProtectionPolicy configures the log-group policy with both operations. Configure both the detection criteria and the intended operation rather than assuming detection alone hides content.
By default, matching sensitive data is masked at egress points including Logs Insights, metric filters, and subscription filters. Principals with logs:Unmask can view the original. This is access-controlled masking, not removal of the original before ingestion. If your requirement prohibits storing a value at all, the application must remove it before sending the event.
A policy applies to data ingested after the policy takes effect. It does not mask previously ingested events. AWS documents support for both Standard and Infrequent Access log classes. Inventory existing log groups and historical exposure instead of declaring the policy a repair for past logs.
The AWS/Logs metric LogEventsWithFindings reports events with sensitive-data matches. Use it to alert on unexpected detector hits in supposedly sanitized application logs. A hit is evidence that your upstream projection or schema might have failed; a zero value does not prove the absence of every sensitive format.
Verify every emission path
Test with synthetic values in a prompt, tool argument, tool result, Guardrails match, and nested agent trace. Exercise success, validation failure, timeout, and exception paths. Inspect what the application sends before ingestion and what ordinary log readers receive afterward. The former tests minimization; the latter tests destination masking.
Do not log the unsafe payload again to explain a sanitization failure. Emit a safe failure category and correlation identifier. If detailed incident evidence is necessary, define its approval, storage, access, and deletion separately from routine telemetry. No detector substitutes for that application decision.
Key distinctions and trade-offs
Sanitization before storage versus masking on retrieval: Upstream sanitization prevents the value from entering that store. CloudWatch masking controls ordinary visibility while retaining an unmasking permission path.
Execution payload versus operational evidence: A tool might need an address to fulfill an authorized request. Operators can usually investigate success and latency using the tool name, outcome, and correlation rather than the address.
Trace collection versus trace export: enableTrace controls returned Bedrock agent trace information. Your application separately decides which fields to persist, display, or forward.
Architecture / decision scenario
A customer-service agent logs each tool attempt and exports Bedrock agent traces for troubleshooting. An engineer enables Guardrails masking and disables invocation logging, yet a support dashboard still shows email addresses. The addresses came from nested action-group parameter values and GuardrailPiiEntityFilter.match records serialized by the application.
The team replaces raw object logging with an approved event schema and a trace projection. It omits contact fields, request bodies, and original PII matches, preserving tool outcome and opaque correlation. CloudWatch data protection provides another visibility control, with logs:Unmask restricted to the approved investigation role.
Synthetic tests verify each nested field and exception path before release. LogEventsWithFindings alarms identify regression in future ingested events. Historical events receive a separate retention and deletion review rather than being counted as protected by that policy.
Common exam traps
- Assuming disabled invocation logging disables application telemetry.
- Logging a full Guardrails assessment because its action says
ANONYMIZED. - Sanitizing user text while exporting tool parameters or nested traces unchanged.
- Treating CloudWatch masking as deletion of the stored original.
- Expecting a data protection policy to mask previously ingested events.
- Using a zero detector metric as proof that every secret is absent.
What to remember
- Define logging and trace export as independent release boundaries.
- Remove prohibited fields before serializing application events.
- Guardrails matches and agent traces can contain original sensitive values.
- Use CloudWatch masking and findings metrics as additional controls, not proof of upstream removal.
Knowledge check
A tool’s typed contract marks its accountKey and password fields as sensitive. The team wants operators to see each tool attempt without ever storing those values. Which logging design fits?
A Bedrock agent exports traces from InvokeAgent with enableTrace: true for troubleshooting. Reviewers find customer account numbers in the exported traces, although the user’s question is already sanitized. What should the exporter do?
enableTrace for every session and debug from application logsactionGroupInvocationInput with parameter value fields and a requestBody . A projection keeps the structure and outcomes operators need and drops content-bearing fields. Turning off trace loses the debugging evidence, and masking at the destination still stores the originals.A guardrail masks email addresses in a model response, and its assessment reports the action ANONYMIZED. The application logs the whole assessment object. What does the log now contain?
match fields{EMAIL} placeholders, because the action was ANONYMIZEDGuardrailPiiEntityFilter.match holds the original detected value, by design, so the application can act on it. The action describes what the guardrail did to the response, not what the assessment object contains, so it must be projected before logging.A requirement forbids storing customer phone numbers in operational logs. A CloudWatch Logs data protection policy masks them for ordinary readers, and only an investigation role has logs:Unmask. Is the requirement met?
logs:Unmask can still view the original. A no-storage requirement is met only by removing the value before the event is sent; destination masking is an additional control.A team applies a data protection policy to a log group that has held unmasked email addresses for six months. Which statement about the older events is correct?
LogEventsWithFindings reports matchesLogEventsWithFindings counts matches; it removes nothing.