domain_5

Shared Responsibility for AI

The shared responsibility model defines what AWS protects and what you protect. AWS secures the physical infrastructure, the network, and the global cloud foundation. You secure everything you put in the cloud — your data, your applications, your identity configuration, and how you use AI services.

For AI workloads, your side of the responsibility includes identity and access management, classifying your data, securing your applications, designing prompts, choosing models, curating your data corpus, managing agent permissions, logging, monitoring, governance, and meeting any regulatory requirements.

A critical concept: using a managed AI service, like Amazon Bedrock or SageMaker, does not transfer your security or compliance obligations to AWS. You are still responsible for protecting your data and how you use the model.

Core Security Principles

Let's explore six core security principles for protecting your AI workloads on AWS: least privilege, encryption, network isolation, secret protection, data minimization, and logging and audit.

Least privilege means granting only the permissions a user, application, model, or agent needs to perform its task. Use roles and policies instead of permanent credentials.

Encryption protects data at rest, like files in S3, and data in transit, like traffic over a network. You use encryption keys managed by AWS or yourself.

AWS Key Management Service, or KMS, lets you create and control encryption keys. When you use KMS with S3, it gives you control over key rotation, usage audits, and cross-account access.

For the simplest encryption on S3, choose server-side encryption with S3-managed keys. AWS handles the keys automatically.

If you need to control key rotation, audit key usage, or share encrypted data across accounts, use KMS with a customer managed key.

Only use customer-provided keys when you must supply and manage your own encryption key material. This is rare.

Think of it this way: S3-managed keys are like a hotel safe where the hotel keeps the key for you. KMS-managed keys are like having your own safe deposit box you control. Customer-provided keys are like bringing your own lock.

To protect data moving across networks, use TLS encryption. Combine it with AWS PrivateLink and VPC endpoints so traffic stays off the public internet.

Network isolation means placing resources in a Virtual Private Cloud, or VPC, and using private connections like VPC endpoints and AWS PrivateLink. This helps avoid exposure to the public internet.

Secret protection is about storing sensitive values like passwords and API keys securely. AWS Secrets Manager stores and can automatically rotate these secrets.

Data minimization means you only collect, send, and store the data you genuinely need. Strip out noise, mask sensitive fields, and avoid holding unnecessary information.

Logging and audit means keeping records of important events like model access, prompt metadata, API calls, agent tool usage, configuration changes, and human approvals. This creates an audit trail for security and compliance.

One final tip: if an application suddenly can't read an S3 object encrypted with KMS, don't assume the encryption is broken. The most likely cause is that the application's role is missing the KMS decrypt permission. Fix it by granting kms:Decrypt.

Security Services for AI Systems

AWS provides a set of security services that work together to protect your AI workloads. Let's walk through the key ones you need to know.

AWS IAM — I-A-M stands for Identity and Access Management. It is the service you use to create and manage users, roles, and groups, and to set permissions that control who can do what with your AWS resources.

AWS KMS — K-M-S stands for Key Management Service. It gives you control over the encryption keys used to protect your data. You can create keys, decide who can use them, and even set them to rotate automatically.

AWS Secrets Manager — a service that securely stores and automatically rotates secrets like database passwords, API keys, and other credentials. It keeps these out of your code and configuration files.

Amazon Macie — a service that discovers sensitive information in your S3 buckets, like personal data or financial records. A critical exam fact: Macie identifies and reports sensitive data, but it does not encrypt or change the data itself. You need another process to act on its findings.

Amazon GuardDuty — a threat detection service that continuously monitors for malicious activity and suspicious behavior in your AWS accounts and workloads. It analyzes things like logs and network traffic to find threats.

AWS PrivateLink — a feature that gives you private connectivity between your VPC and supported AWS services without your data ever touching the public internet. It helps keep sensitive traffic isolated.

Output filtering is a safety practice for AI applications. It means applying controls to what your model produces—and what users can submit as input—to block harmful, toxic, or inappropriate content. This might include filtering out things like SQL commands, shell code, or offensive language.

Source Citations and Data Origins

A source citation tells you where a piece of information came from. It's like a footnote that points back to the original document or dataset. Citations help people verify claims, build trust, and support audits. But here's the catch: just because something has a citation doesn't mean it's true. You still need to evaluate the source yourself.

Data lineage is the story of your data's journey. It tracks where the data originated, what transformations it went through, who accessed it, and what it was used for. Think of it as a detailed travel log for your data.

Data cataloging is about metadata—information about your data, such as column names, data types, and descriptions. A service like the AWS Glue Data Catalog stores this metadata, but it does not store the actual underlying data. It's like a library card catalog that tells you where to find a book, not the book itself.

SageMaker Model Cards are documents that describe a machine learning model. They cover the model's purpose, how it was evaluated, its limitations, and any governance information. They act like a model's ID card that explains what it's for and how it should be used.

Source citation versus data lineage: A source citation points to where a specific piece of information came from, like a single reference. Data lineage is broader—it traces the entire history of a dataset, including all the changes and uses along the way. Citations are like footnotes for individual facts; lineage is the full biography of the data.

Secure Data Engineering

Secure data engineering is about building data pipelines that are trustworthy, private, and tamper-proof. It starts with assessing the data itself, then applying privacy techniques, controlling who can see what, and making sure nothing gets altered without permission.

Bias in data — when a dataset unfairly favors one group or outcome, often because it doesn't represent the real world. A biased dataset can lead a model to make unfair or inaccurate predictions.

Misinformation in data — false or misleading content that looks like a fact. If a model learns from it, it can spread the wrong information.

Malicious content — data that is deliberately harmful, like poisoned training examples or hidden instructions designed to hijack a model's behavior.

Think of data quality as a safety check. Before you feed data into any AI system, you should look for bias, check for things that are factually wrong, and scan for anything that might have been planted to cause harm. Skipping this step can lead to unsafe models.

Once you have good data, the next step is protecting people's privacy. There is a whole toolkit of privacy-enhancing techniques, and you pick the right one based on how sensitive the data is.

Data minimization — collecting and storing only the data you actually need. If a field is not required, leave it out. This reduces the damage if there is ever a breach.

Masking or redaction — hiding or removing parts of sensitive data. For example, showing only the last four digits of a credit card and replacing the rest with asterisks.

Tokenization — replacing sensitive data with a non-sensitive stand-in, called a token. The real data is stored securely somewhere else, and the token is useless on its own.

Pseudonymization — swapping out personal identifiers, like a name or email, for a fake label or a code. Unlike anonymization, it can be reversed if you have the mapping key.

Anonymization — permanently stripping away all identifying information so that the data cannot be linked back to an individual. Once it's truly anonymous, it is no longer considered personal data.

Aggregation — combining data into group summaries, like reporting total sales by region instead of listing every single transaction. This hides individual details while still showing useful patterns.

Access controls are another kind of privacy technique. Even if the full dataset exists, you can set rules so that each person or system sees only what they are allowed to see, like a surgeon seeing patient records but not billing information.

How anonymization differs from pseudonymization. Anonymization is a one-way street — once applied, you cannot trace the record back to the original person. Pseudonymization replaces identifiers with codes, but someone with the lookup table can reverse it. Use anonymization when you truly never need to re-identify anyone; use pseudonymization when you might need to reconnect data for a legitimate purpose later.

Now let's talk about data access control. This is about making sure the right people and systems have exactly the right permissions, and nothing more. It's the principle of least privilege in action.

Identity and Access Management, or I A M — the service that lets you create users, groups, and roles, and attach policies that say exactly what they can and cannot do with your A W S resources.

Attribute-based access control, or A B A C — a way to grant or deny access based on tags and properties, or attributes. For example, allowing access only if the user's department tag matches the data's department tag, rather than just checking their job title.

With A B A C, you can write fine-grained rules. Imagine a filter that says, 'a data analyst can only see rows from the region they are assigned to.' This works alongside I A M roles and database permissions to create multiple layers of control.

With privacy and access sorted, we need to think about data integrity. This means making sure data hasn't been changed by accident or by someone who shouldn't have changed it.

Checksum — a short digital fingerprint of a file or a piece of data. If even one bit changes, the fingerprint changes completely. You can use checksums to verify that data hasn't been corrupted or tampered with.

Immutable storage — a storage setting where once data is written, it cannot be changed or deleted for a set period. Think of it as a write-once, read-many safety lock.

Versioning is also a powerful integrity tool. When you turn on versioning for a storage bucket, every update creates a new version instead of overwriting the old one. If someone makes a bad edit, you can just roll back to the previous version.

Together, access controls, versioning, checksums, and immutable storage form a strong defense. Access controls stop unauthorized changes. The others give you a safety net to detect and recover from problems.

Our last big idea for secure data engineering is separating environments. Never, ever use real production data to test your code.

Separation of environments — keeping your development, testing, and production systems fully isolated from each other. Different data, different permissions, different accounts if possible.

The main risk is that test environments usually have weaker security. If real customer data ends up there, it is suddenly much easier for someone to find and steal. Instead, use synthetic data, which looks and behaves like real data but contains nothing sensitive, or use a sanitized copy where all personal details have been masked.

AI Security and Privacy Threats

AI systems face unique security challenges. You need to secure the application itself, detect threats in real time, manage software vulnerabilities, and protect the underlying infrastructure. Equally important are AI-specific risks like prompt injection, data leakage, and toxic outputs, all of which must be logged for audit purposes.

Application security for AI means validating every input, authenticating users, authorizing their actions, and protecting all application programming interfaces, or APIs, from abuse. Think of it as the front door lock on your AI service.

Threat detection involves monitoring for suspicious access patterns, unusual devices, anomalous network traffic, and security findings. It's like having a security camera that watches for break-ins or strange behavior around the clock.

Vulnerability management is the practice of regularly patching software dependencies, scanning compute workloads and containers for known weaknesses, and remediating them before attackers can exploit them.

Infrastructure protection uses network isolation to keep systems off the public internet, identity controls to manage who can do what, secrets management to protect passwords and keys, and monitoring to watch over everything.

Prompt injection is an attack where malicious input tries to override the model's original instructions. An attacker might hide a command in user text, tricking the model into ignoring its safety rules.

Prompt injection differs from data leakage. Injection tricks the model into doing something it shouldn't, while data leakage is when the model accidentally reveals private information. Injection is about controlling the model; leakage is about exposing secrets.

To defend against prompt injection, treat all external content as untrusted input, never as instructions. Use trusted system instructions that an attacker cannot alter, filter prompts for suspicious patterns, and require human approval before any sensitive action is taken.

Data leakage prevention stops confidential information from appearing in prompts, logs, model memory, or outputs. It's about ensuring secrets like personal data or business plans don't accidentally get exposed.

Output filtering scans model responses for dangerous content before they reach the user. It blocks things like database commands, program code, system shell instructions, or sensitive personal information. Think of it as a safety net that catches harmful language on the way out.

Toxicity refers to harmful, abusive, or threatening content. To address it, use automated content filters, continuous monitoring, and human moderators to review flagged outputs. It's about keeping interactions safe and respectful.

An audit trail logs important events like model version changes, prompt submissions, configuration updates, and deletions. It must respect privacy by not capturing sensitive data unnecessarily. These logs create a trustworthy record for later review.

Hallucination Detection and Grounding

Let's talk about one of the trickiest problems in AI: hallucinations. A hallucination is when a model gives an answer that sounds confident but is actually incorrect or has no support in the real world.

Hallucination — an incorrect or unsupported model output. It's not a small mistake; it's a fabricated detail or a completely made-up answer.

Why does this happen? There are several common causes. The model might lack the right context, or the prompt could be vague. Sometimes the retrieval step pulls weak or outdated information. High randomness settings, like a high temperature, can make the model more creative but also more likely to drift from the facts. And when the model feels pressure to answer but has no good information, it will often just invent something.

To fight hallucinations, we have a whole toolkit. A powerful approach is RAG: Retrieval-Augmented Generation. With RAG, we give the model access to a trusted, up-to-date knowledge base. Before it answers, it retrieves relevant facts from that base. This way, the answer stays grounded in evidence, not just the model's memory.

We also use source citations. When the model includes where it got its information, we can check that source ourselves. But remember, a citation is not a guarantee of truth. A model can cite a bad source. Always evaluate the source.

Another layer of defense is output validation. We run automated checks or have a human reviewer look at the answer before it goes to the user. And we can design the model with clear instructions to admit uncertainty. The model should say 'I don't know' rather than guess.

For factual tasks, we lower the randomness. Turning down the temperature parameter makes the model stick closer to the most probable tokens, which is usually safer when precision matters. Services like Bedrock Guardrails let us enforce these rules at the platform level.

Confidence score — an estimate of how sure the system is about an answer. It can be based on retrieval scores, the model's own probability calculations, rule-based checks, or even a separate evaluation model.

But here's the critical warning: a confidence score is an indicator, not proof. A high score does not mean the answer is correct. It just means the system thinks it is. Low-confidence or high-risk outputs should always be reviewed by a person or rejected automatically.

Grounding — the practice of connecting an answer to trusted external evidence. Grounding is what makes an answer trustworthy. The most common way to achieve grounding is RAG.

To recap the mitigations, think of them as layers: give the model trusted data through RAG, ask it to cite its sources, check its work with validation and human review, use confidence scores as a safety net, and dial down randomness when the stakes are high.

Governance and Compliance Services

This section covers the AWS services that help you keep your cloud environment secure, compliant, and well-governed. Think of them as your audit, monitoring, and advisory toolkit.

AWS CloudTrail — a service that records every API call made in your account, giving you a complete activity log for auditing and security investigations.

Amazon CloudWatch — a monitoring service that collects metrics, logs, and events from your resources, lets you set alarms, and gives you operational visibility into your applications.

AWS Config — a service that tracks how your AWS resources are configured over time and can evaluate whether those configurations meet your compliance rules.

AWS Artifact — a self-service portal where you can download AWS compliance reports and agreements, such as SOC reports or ISO certifications, on demand.

AWS Audit Manager — a service that helps you continuously collect and organize evidence for audits, mapping your AWS usage to the controls in common compliance frameworks.

AWS Trusted Advisor — an advisor that scans your account and gives you real-time recommendations across cost optimization, performance, security, and fault tolerance.

AWS Well-Architected Tool — a tool that helps you review your workloads against the AWS Well-Architected Framework's best practices and identify areas for improvement.

Amazon Inspector — a vulnerability scanner that automatically checks your workloads for software vulnerabilities and unintended network exposure.

How CloudTrail differs from CloudWatch: CloudTrail records who did what and when — it is your API activity audit log. CloudWatch tracks how your resources are performing — it is your metrics and operational health dashboard.

How AWS Config differs from CloudTrail: CloudTrail tells you the API events that happened. AWS Config tells you what your resource configurations look like right now and whether they have drifted from your desired state.

How AWS Artifact differs from Audit Manager: Artifact gives you ready-made AWS compliance reports. Audit Manager helps you build your own audit trail by mapping your AWS activity to specific compliance controls.

How Trusted Advisor differs from the Well-Architected Tool: Trusted Advisor runs automated checks and gives you specific recommendations. The Well-Architected Tool is a guided review process where you answer questions about your workload and get improvement suggestions.