aifromzero.dev

Security, Privacy, and Governance: IAM, PII, and Responsible AI (AWS GenAI Developer Pro, Module 10)

Module 10 of 16 16 min read D3 · 20% Lab code ↗

This is Module 10 of AWS GenAI Pro Mastery, a free 16-module course that takes you from your first Amazon Bedrock call to AWS-certified.

CloudCart is going for SOC 2, and the auditor has read your architecture. The email is short: “Your support bot sends customer data to a foundation model. Show me what data it saw last Tuesday, who could access it, how long you keep it, and your documented limitations.” Silence. The Relay you built through Module 9 resists hostile content beautifully — but every ticket still carries a customer’s name, email, and phone, and that text goes raw to the model, into the logs, and into memory. The lab role can do almost anything; there is no record of who invoked what, no retention policy, no document stating what Relay is not allowed to do. None of that is a quality problem — it is why a perfectly good agent is undeployable in an enterprise. By the end of this module, every line of that email has a tooled answer.

In this module

You’ll learn how to:

  • Architect a protected FM environment: VPC endpoints, least-privilege IAM, access monitoring, KMS encryption at rest (3.2.1).
  • Detect and mask PII with the right tool — Comprehend (text in flight) vs Macie (S3 at rest) vs the guardrail PII filter — and apply S3 retention (3.2.2, 3.2.3).
  • Implement PII redaction in Relay’s intake, before any FM call (skills 3.2.2, 3.2.3).
  • Build traceability: CloudTrail audit, decision logs, source attribution, lineage, and continuous-governance logging (3.3.1, 3.3.2, 3.3.4).
  • Document Relay in a model card and organize governance — policies, oversight, compliance (3.3.1, 3.3.3, 3.4.3).
  • Apply responsible AI principles: transparency through citations and tracing, fairness as a documented principle (3.4.1, 3.4.2).

You’ll build: PII redaction in Relay’s intake (before any FM call), least-privilege IAM roles per component, an audit trail of the agent’s actions, and Relay’s model card.

Exam domains covered: D3 — AI Safety, Security, and Governance (20% of the exam). Module 9 covered Task 3.1 (input/output safety controls); this module covers Tasks 3.2, 3.3, and 3.4 — data security and privacy, governance and compliance, and responsible AI principles. Domain 3 is shared between these two modules, and one skill (3.4.2, fairness) is shared with Module 13. Together M9 and M10 close out the domain.

Prerequisites: Modules 1–9. An AWS_PROFILE that resolves to your course account, us-east-1 everywhere. You need the Module 6 intake pipeline, the Module 7 agent and tables, and the Module 9 guardrail.

Where you are in the build

One stop on a 16-module road. M1–M9 are behind you; M10 is here; M11–M16 are ahead.

  • ✅ M1–M9 — secured account, structured triage, the converse() router, a cited Knowledge Base, multimodal intake, a Strands agent on AgentCore, and a guardrail with an adversarial suite.
  • 👉 M10 — Relay passes a security review. PII masked at the intake edge, one least-privilege role per component, an audit trail, and a model card.
  • ⬜ M11–M16 — deployment, cost, evaluation, observability, and the capstone.

Relay after this module: PII is masked at intake before any model call (including the screenshot read), each component has a minimal IAM role with explicit ARNs and zero wildcards, the agent writes a redacted decision log that audit_report.py crosses with CloudTrail, and docs/model-card.md documents the system’s limits — deployment behind a public API is M11.

The security perimeter of an FM workload

Before you redact anything, map where Relay’s data lives — that is what the auditor is really asking. Ticket text lands in the relay-tickets table; docs sit in S3 and feed the Knowledge Base index; screenshots land under attachments/; the agent leaves a decision log; AgentCore Memory distills durable facts across sessions. On every model call, a slice of that data crosses a trust boundary to Amazon Bedrock. Skill 3.2.1 is controlling that whole perimeter.

Three controls define it. VPC endpoints (powered by AWS PrivateLink) keep traffic to Bedrock on the AWS network — the answer whenever a requirement says “data must never traverse the public internet.” KMS (AWS Key Management Service) encrypts data at rest — S3 objects, DynamoDB tables, logs — with keys you control. And least privilege is the IAM discipline of granting each component exactly the actions and resources it needs and nothing more — the lever you build in this lab. One more perimeter term: AWS Lake Formation gives table- and column-level access control over a data lake — overkill for Relay’s two tables, but the exam’s answer for a shared analytics lake.

A note on scope: VPC endpoints bill by the hour, so this module teaches them as theory; the free IAM roles you build for real.

Here is Relay’s data flow with its trust boundaries — what is encrypted, what crosses to Bedrock, and where PII is masked:

flowchart TD
    T["customer ticket<br/>(raw PII)"] --> I["intake (M6)"]
    I --> R["PII redaction (M10)<br/>Comprehend · by offset"]
    I -. "image bytes" .-> V["vision read · FM call"]
    V -. "summary appended<br/>to masked text" .-> A
    R -. "masked text only" .-> A["agent · FM calls"]
    A --> KB[("Knowledge Base<br/>S3 docs · KMS at rest")]
    A --> DB[("relay-orders / relay-tickets<br/>DynamoDB · KMS at rest")]
    A --> DL["decision log<br/>(redacted)"]
    subgraph trust ["trust boundary → Amazon Bedrock"]
        V
        A
    end
    R === EDGE["the edge: nothing past here sees raw PII"]

Per the official AIP-C01 exam guide, skill 3.2.1 names VPC endpoints, IAM secure-access policies, Lake Formation, and CloudWatch access monitoring as the toolkit for “protected AI environments.” Learn the four by the problem each solves: network isolation, identity-bounded access, granular data-lake permissions, and access visibility.

PII: detect, mask, anonymize, retain

This is the heart of the module. PII — personally identifiable information — is any data that identifies a person: a name, email, phone number, postal address, government ID. CloudCart tickets are full of it, and Modules 2 through 9 sent it raw to the model. The fix is to remove it at the right place, with the right tool.

The three PII tools are not interchangeable — learn what each acts on and when:

Amazon ComprehendAmazon MacieGuardrail PII filter (M9)
Where it actsText in flightObjects at rest in S3At the model-call boundary
When you use itRedact a string before it reaches a model/logDiscover PII across a data lake or bucketMask/block PII on one Bedrock call
GranularityPer entity, with character offsetsPer S3 object, scheduled jobsPer request/response
ActionYour code masks by offsetReports findings (does not redact in place)mask or block
Cost shapePer unit of text (pennies)Per GB scanned, scheduledPer model call (idle = $0)

Amazon Comprehend is the in-flight detector. Its DetectPiiEntities operation returns each entity as a {Type, BeginOffset, EndOffset, Score} — character offsets, not the matched substring — so you mask by slicing the original text at those offsets, never with a home-grown regex. Amazon Macie is the at-rest discoverer: scheduled jobs over S3 that report which objects contain PII — it finds PII in a bucket, it does not redact in flight. And the guardrail PII filter from Module 9 masks or blocks entities on a single model call — but it fires at one call’s boundary and does nothing to stop raw PII landing in your decision log or memory first.

That last point is the whole design. Relay redacts at intake on one principle: redact at the edge, and everything downstream inherits the protection. Once intake replaces a name with [NAME], the foundation model, the entity-extraction pass, the decision log, TicketRecord, and AgentCore Memory all see the masked version — whereas a guardrail-only design still writes the raw prompt to your invocation logs.

Masking is one of two privacy strategies skill 3.2.3 names. Masking replaces a value with a typed placeholder ([NAME]) — the model still knows a name was there, not its value. Anonymization goes further with consistent pseudonyms: the same customer becomes the same stable token across tickets, so you correlate a person’s history without storing their identity. Relay masks; consistent anonymization is a “Try it yourself” extension. The third lever is retention: an S3 Lifecycle rule expires objects under a prefix after N days — the documented control for “purge transcripts after 30 days.”

⚠️ Common misconception: “Bedrock trains on our prompts, so PII is leaked to the model provider.” False. Amazon Bedrock does not use your prompts or completions to train any model, and does not share them with the model providers. The real PII risk is on your side of the boundary — invocation logs, agent memory, DynamoDB rows, committed fixtures — which is exactly why Relay redacts at the intake edge and bounds retention.

Governance: audit trails, lineage, and model cards

Now answer the auditor’s “who saw what.” Two trails do it, and the exam keeps them distinct. CloudTrail records management events — who (which IAM principal) called which AWS API, and when — the API call, never the prompt content. The application decision log records what Relay decided and why: which tools it ran, on what (redacted) input, with what result. CloudTrail proves access; the log proves decisions.

A model card is the governance artifact an auditor asks for by name. It documents a system’s intended use, the models it relies on, the data it touches, and its known limitations. SageMaker AI can produce model cards programmatically; for Relay, the card is a versioned Markdown document. The load-bearing word is documents — a model card documents, it does not enforce; enforcement is the guardrail and IAM.

Two more terms round out skills 3.3.1–3.3.4. Lineage is the provenance of data — where generated content came from. The AWS Glue Data Catalog registers data sources and metadata tagging carries source attribution through a pipeline; Relay touches this through its citations, which trace each answer to a source document. And continuous governance (skill 3.3.4) watches for misuse, drift, and policy violations over time — concepts here, with the CloudWatch tooling that operationalizes them in Module 14.

Map the auditor’s questions to artifacts:

Auditor asks…The artifact is…
”Who invoked the model and when?”CloudTrail management events
”What did the bot decide, and on what input?“the decision log (redacted)
“Where did this answer’s facts come from?“citations / lineage (source attribution)
“What are the system’s documented limits?“the model card
”Who can access the customer data?“the IAM roles (least privilege)

There is a governance question the SOC 2 auditor has not asked, but a privacy regulator will: not who may access the data, but where it may go.

🌍 THEORY — data sovereignty as a governance control (skill 2.3.4). Every model call here sends a slice of customer data — even masked, the redacted text, the order context, the FM’s response — to Amazon Bedrock in one Region (us-east-1). That single-Region choice is not just a deployment default; it is the data-residency boundary the governance program leans on. Data sovereignty is the rule that a jurisdiction’s data must be processed under that jurisdiction’s law — GDPR for EU residents’ PII, sector rules that forbid data leaving a country. Run Relay in one Region and you can state, in the model card and to the regulator, exactly which jurisdiction every input and output is processed in: the inference never silently crosses a border. When a law forbids data leaving a jurisdiction with no Bedrock Region, the lever is to bring inference to the data — AWS Outposts (Bedrock infrastructure inside your own facility) or AWS Wavelength (the telecom edge) keep the FM call physically in-jurisdiction. The governance reasoning is the exam’s: residency is a documented control (the model card names the Region; redaction bounds what PII reaches the boundary at all), enforcement is the architecture. Per the official AIP-C01 exam guide, skill 2.3.4 names Outposts, Wavelength, and edge deployment as the cross-jurisdiction toolkit. Module 11 revisits these through the deployment lens; here they answer a governance question — which jurisdiction may the customer’s data lawfully be processed in?

Responsible AI: transparency, fairness, policy

Responsible AI is the practice of building FM systems that are transparent, fair, and accountable — Task 3.4. Relay already has its strongest pillar — transparency. Source attribution — the citations from Module 5 — lets a customer (and an auditor) see why Relay answered as it did, tracing each claim to a document; reasoning displays and agent tracing extend this (the tracing tooling is Module 14). When a scenario asks “users must understand why the bot said that,” the answer is attribution plus tracing plus a confidence display — not a bigger model.

Fairness is the second pillar: ensuring outputs do not vary unjustly across groups of users. AWS frames it with pre-defined fairness metrics in CloudWatch and A/B testing through Bedrock Prompt Management. Relay documents fairness as a principle and can A/B prompts, but the measured fairness harness — LLM-as-a-judge scoring twin-pair prompts — is built in Module 13 (the one Domain 3 skill, 3.4.2, that M10 shares with M13).

The third pillar is policy compliance (skill 3.4.3): guardrails derived from your policies (Module 9), a model card documenting the limitations, and automated compliance checks. Relay’s card lists the limits openly — including the Module 9 attacks that still slip the guardrail — because a card that hides its failures is useless to an auditor.

Build it: redact, lock down, and audit Relay

The lab takes Module 9’s relay/ byte-for-byte and adds the governance layer: a Comprehend redactor wired into intake before any model call, one least-privilege IAM role per component, a redacted decision log, an audit report, and Relay’s model card. It still passes every smoke test from Modules 1–10 offline, and cost me $0.02 on June 2026 prices.

Detect and mask, by offset (relay/pii.py, NEW). redact() runs DetectPiiEntities, drops spans below a confidence floor, and masks each by slicing the original text. A failed Comprehend call raises — never treated as “no PII found,” which would ship raw data to the model:

def redact(text, *, client=None, min_score=None) -> RedactionResult:
    spans = detect_pii(text, client=client, min_score=min_score)   # by offset, not regex
    if not spans:
        return RedactionResult(text=text, redacted=False, counts={})
    counts = {}
    for span in spans:
        counts[span.entity_type] = counts.get(span.entity_type, 0) + 1
    masked = mask_spans(text, spans)        # replaces from the LAST span backward
    return RedactionResult(text=masked, redacted=True, counts=counts)

The entity allowlist (config.PII_ENTITY_TYPES) decides what is masked. It deliberately keeps order numbers — Comprehend does not class #1042 as PII; it is a business key lookup_order needs — and skips DATE_TIME, operational signal the agent uses. Run it on a string:

$ uv run python -m relay.pii "Hi, I'm Dana Lee (dana.lee@example.com, 555-0100), order #1042 is late."
Hi, I'm [NAME] ([EMAIL], [PHONE]), order #1042 is late.
[pii] masked 1 EMAIL, 1 NAME, 1 PHONE

The [pii] summary carries counts only — no raw value — so it is safe to log; the order number survives, the identity is gone.

Redact at the edge (relay/intake.py, MODIFIED by addition). Intake runs redaction on the normalized text before the Comprehend entity pass and before the Nova Lite vision read — the order is load-bearing:

normalized = validate_nonempty(normalize(raw_text))
# --- REDACT PII (M10) — BEFORE any FM call and before the entity pass ---
redaction = pii.redact(normalized, client=pii_client) if redact_pii else None
safe_text = redaction.text if redaction else normalized
entities  = detect_entities(safe_text, ...)        # runs on the REDACTED text
# ... vision read (an FM call) also runs on safe_text ...
ticket = Ticket(..., pii_redacted=bool(redaction and redaction.redacted))

pii_redacted is the only field Module 10 adds to Ticket, by addition, default False, so every earlier fixture still validates:

class Ticket(BaseModel):
    ticket_id: str
    channel: Literal["email", "chat"]
    customer_message: str
    attachments: list[Attachment] = []   # ADDED M6
    pii_redacted: bool = False           # ADDED M10
    created_at: str

Run it on the demo fixture and the entity line is computed on the already-masked text — proof redaction runs first:

$ uv run python -m relay.intake data/tickets/pii_ticket.json
# Ticket with name/email/phone → [NAME]/[EMAIL]/[PHONE], "pii_redacted": true
# the [Entities] line was computed on the REDACTED text (date 2026-06-10; #1042) — no PII

One least-privilege role per component (iam/policies/*.json, NEW). A single broad lab role would fail the review. Each component gets its own role with explicit actions and resource ARNs and zero wildcards. The agent’s policy is the clearest example — it reads orders but cannot write them, writes tickets, applies only the named guardrail, and reasons only on the allowed inference profiles:

{ "Sid": "ReadOrdersOnly", "Effect": "Allow",
  "Action": ["dynamodb:GetItem", "dynamodb:Query", "dynamodb:BatchGetItem"],
  "Resource": ["arn:aws:dynamodb:${REGION}:${ACCOUNT_ID}:table/relay-orders"] }

setup.py substitutes ${ACCOUNT_ID}/${REGION} from STS and attaches each JSON as the role’s inline policy. The intake role cannot read the order book; the API role cannot call a model:

$ grep -rE '"Action":\s*"\*"|"Resource":\s*"\*"' iam/
# (zero results — no wildcards anywhere)

The audit trail (relay/agent.py decision log + audit_report.py, NEW). The agent appends one structured JSON-Lines record per run — tool calls, redacted inputs, outcome, timestamp. Inputs are re-redacted before writing, so no raw email lands in the file. audit_report.py crosses it against CloudTrail:

$ uv run python audit_report.py --last 1h
# decision log: search_kb tool calls on REDACTED inputs, outcome + timestamp per ticket
# CloudTrail:  CreateRole / PutRolePolicy / CreateGuardrail by the macbook principal
# Note: CloudTrail records the API CALL (who/what/when), not the prompt content.

Across a real agent run, grep for the fixture’s raw values in the decision log returns zero matches while dates and the tracking number survive. Offline, the cumulative suite is 226 passed, 9 skipped; the opt-in live smoke (RELAY_LIVE_TESTS=1) ran 7 passed, 2 skipped (the two skips are inherited MCP-backed agent tests the account blocks via anonymous Lambda Function URLs — an environment constraint, not an M10 defect). The four IAM roles were AWS-CLI-verified: account and region substituted, zero wildcards, the table ARNs scoped to relay-orders (read) and relay-tickets (write). The KB and guardrail ARNs use ${KB_ID}/${GUARDRAIL_ID} placeholders that setup.py resolves to the resource’s system id at deploy — a Bedrock Knowledge Base or guardrail ARN keys off that id, never the human name, so a name-based ARN would silently match nothing.

Document it (docs/model-card.md, NEW). Relay’s model card lists intended use, the active inference-profile IDs (never a bare or legacy ID), the data it touches and how each store is protected, and — honestly — the known limitations: the guardrail is probabilistic and some M9 attacks still slip, redaction can miss or over-mask, the system is single-Region and English-first, and fairness is documented but not measured until Module 13.

Try it yourself. (1) Swap masking for consistent anonymization: hash each detected NAME to a stable pseudonym so the same customer reads identically across tickets — a different replacement at the same offsets in mask_spans. (2) Add an S3 Lifecycle rule expiring objects under attachments/ after N days — one put_bucket_lifecycle_configuration call, the retention control the auditor asked for.

In production

A redaction pipeline and a set of roles are things you operate, not ship once.

IAM hygiene. Roles drift — a new action gets granted broadly under deadline, and a year later the “least-privilege” role is anything but. Use IAM Access Analyzer to find unused permissions and over-broad grants, and review roles on a fixed cadence — least privilege is a process, not a one-time file.

The right to be forgotten. A data-subject access request — find and purge everything about one customer — is a key-design problem you solve before it lands: partition data so one customer’s records are addressable, paired with S3 Lifecycle so transcripts age out. Redaction at intake helps: if raw PII never entered your stores, there is less to erase.

Cost and local rules. CloudTrail management events are free, but data events (object-level S3 reads) are billed — turn them on deliberately. And the redaction rules are jurisdiction-specific — what counts as PII, and how long you may keep it, differs by law (distinct from where it is processed; that is the sovereignty box). A single English-first Comprehend pass is a starting point. Module 14 turns these decision logs into dashboards and alarms.

Exam corner

What the exam tests here. Tasks 3.2, 3.3, and 3.4 — the governance and privacy half of Domain 3:

  • Protected FM environments: VPC endpoints, IAM, Lake Formation, CloudWatch monitoring.
  • Privacy-preserving systems: Comprehend and Macie for PII, Bedrock native data privacy, S3 Lifecycle retention, masking and anonymization.
  • Compliance and lineage: programmatic model cards, Glue lineage, source attribution, decision logs, Data Catalog, metadata tagging, CloudTrail.
  • Responsible AI: transparency via attribution and tracing, fairness metrics and A/B, policy-compliant systems.

Expect at least one matching question pairing an audit requirement to an artifact. Task 3.1 (guardrails, injection, hallucinations) was Module 9; the fairness judge (3.4.2’s tooling) is Module 13. A data-residency scenario (skill 2.3.4) points to single-Region residency, with Outposts/Wavelength as the in-jurisdiction lever — theory here.

Quiz.

  1. A GenAI app must (a) redact PII from ticket text before it reaches the model, (b) discover PII already sitting in a historical S3 data lake, and (c) mask PII on a single model call. Match each to the right tool.

    • A. Comprehend; Macie; the guardrail PII filter.
    • B. Macie; Comprehend; the guardrail PII filter.
    • C. The guardrail PII filter; Comprehend; Macie.
    • D. Comprehend for all three.

  2. A regulation requires customer transcripts to be purged after 30 days and access to them to be provable. Which combination satisfies it?

    • A. A bigger guardrail and temperature 0.
    • B. S3 Lifecycle expiry + CloudTrail + KMS encryption at rest.
    • C. Macie scans + a model card.
    • D. Comprehend redaction alone.

  3. A security requirement states: “Traffic to Bedrock must never traverse the public internet.” What do you use?

    • A. A NAT gateway with an Elastic IP.
    • B. An IP allowlist on the Bedrock endpoint.
    • C. VPC endpoints (PrivateLink) to keep traffic on the AWS network.
    • D. Client-side TLS pinning.

  4. An auditor asks for three things: the documented limitations of the system, the provenance of the facts in a given answer, and who invoked the model last Tuesday. Match each request to its artifact.

    • A. Model card; source attribution / lineage; CloudTrail.
    • B. CloudTrail; model card; the decision log.
    • C. The guardrail; Macie; CloudWatch.
    • D. The decision log; the model card; Comprehend.

  5. Users must be able to understand why the agent answered the way it did. Which approach delivers this?

    • A. Switch to a frontier model so the answers are better.
    • B. Source attribution (citations) plus agent tracing and a confidence display.
    • C. Raise the guardrail strength to HIGH.
    • D. Lower the temperature to 0 for deterministic replies.

Answers. 1 — A. Comprehend redacts text in flight, Macie discovers PII at rest in S3, and the guardrail PII filter masks on a single model call — three tools, three places. 2 — B. Retention is S3 Lifecycle, provable access is CloudTrail, protection at rest is KMS; the combination is the control. A and D solve none of it; C neither purges nor proves access. 3 — C. VPC endpoints / PrivateLink keep traffic on the AWS network; a NAT gateway (A) still routes to the public internet, and an allowlist (B) or TLS pinning (D) does not change the path. 4 — A. Documented limits are the model card, provenance is source attribution / lineage, and “who invoked the model” is CloudTrail. 5 — B. Transparency is attribution plus tracing plus a confidence display; a bigger model, a stricter guardrail, and temperature 0 are the classic distractors that change what the model says, not why you can explain it.

Traps to avoid.

  • Macie scans S3 at rest; it does not redact text in flight. That is Comprehend. The exam swaps the two on purpose — Macie discovers PII in a bucket, Comprehend detects it in a string you are about to send.
  • CloudTrail logs API calls, not prompt content. The prompt lives in invocation logs and the decision log — and those can contain PII, which is exactly why you redact at the edge.
  • A model card documents; it does not enforce. Enforcement is the guardrail and IAM. A scenario asking what stops a behavior wants a guardrail or a policy, not the card.

Key takeaways

  • Redact at the edge. Mask PII at intake, before any model call — the FM, the logs, and the memory then never see the raw values; everything downstream inherits the protection.
  • Sovereignty is a governance boundary. A single-Region deployment documents which jurisdiction every input and output is processed in; when law forbids data leaving a Region-less jurisdiction, Outposts/Wavelength bring inference in-jurisdiction (2.3.4, theory).
  • Three PII tools, three places: Comprehend (text in flight), Macie (S3 at rest), the guardrail PII filter (at the model call). The exam swaps them; do not.
  • One role per component, least privilege. Explicit actions and resource ARNs, zero wildcards — the intake role cannot read the order book, the API role cannot call a model.
  • CloudTrail proves access; the decision log proves decisions. Different trails for “who invoked what” versus “what the agent decided and why.”
  • A model card documents, it does not enforce. It states intended use, models, data, and honest limitations — enforcement is IAM and the guardrail.
  • Transparency starts with citations. Source attribution plus agent tracing is how a user, and an auditor, sees why Relay answered as it did.
  • Bedrock does not train on your prompts. The PII risk you own is your own storage — logs, memory, tables, fixtures — so redaction and retention matter most there.

What’s next

Relay is now secure enough to face the outside world — so let’s give it a front door. Module 11 ships Relay: API Gateway, Lambda, SQS, an EventBridge relay-events bus, a CDK stack, and a CI/CD pipeline — turning the local agent into a serverless service that consumes the least-privilege roles you just wrote.

Want the full AIP-C01 question bank and the next module in your inbox? Subscribe here — it’s free, like everything in this series.

Links: Module 10 lab · ← Module 9 · Course index · Module 11 →

References