Securing AI Systems on AWS: IAM, Encryption, Guardrails, and Grounding

Security on AWS is always shared. AWS is responsible for security of the cloud — the physical data centers, the hardware, and the managed services that run your models, including Amazon Bedrock and Amazon SageMaker. You are responsible for security in the cloud — your data, who can access it, and how you configure the services you use. The line does not move just because the workload uses AI.

Applied to a generative AI application, this split is concrete. AWS patches and protects the infrastructure that hosts the foundation model. You decide which IAM principals can call the model, whether the prompts and responses are encrypted, whether traffic stays on a private network, and what data you feed the model in the first place. If you upload sensitive customer records into a training set without controls, that is your responsibility, not a platform failure.

The exam expects you to place a given task on the correct side of the line. Questions like who is responsible for encrypting the data used to fine-tune a model point to the customer. Questions about the security of the underlying compute point to AWS. A useful rule of thumb: the more managed the service, the more AWS handles the operational layers, but access control, data protection, and configuration always remain yours. Every other control in this lesson is you fulfilling your half of that model.

AWS Identity and Access Management (IAM) decides who can do what. You grant permissions through IAM policies attached to users, groups, or — the preferred pattern — IAM roles that applications and services assume temporarily. For AI systems, the guiding principle is least privilege: give each component only the permissions it needs, and nothing more.

In a typical setup, the application that calls a model runs with a role that allows exactly one action — invoking that model — and can read only the specific data store it needs. It cannot delete the training bucket, cannot read other teams' data, and cannot change security settings. A data-science team member who prepares training data gets read access to the raw data and write access to a working area, but not production credentials. If any single component is compromised, least privilege limits how far the damage spreads.

Roles matter because they hand out temporary credentials instead of long-lived access keys that can leak and linger. An application on AWS assumes a role and receives short-lived credentials automatically, so there is no secret to hard-code. So the secure way to give an AI application access to a model or data source is an IAM role scoped to the minimum permissions it needs. An IAM user with permanent access keys adds a long-lived secret to protect, and broad administrator access turns any single compromise into a compromise of the whole account.

Encryption protects your data even if someone reaches the storage or the network. There are two states to cover, and the exam tests both by name.

Encryption at rest protects stored data — training datasets in Amazon S3, model artifacts, vector databases, and logs. AWS services integrate with AWS Key Management Service (KMS) to manage the encryption keys, and many services encrypt data at rest by default. You can use an AWS-managed key or a customer managed key when you need control over key rotation and access. Encrypting the bucket that holds your training data means the raw files are unreadable to anyone who somehow bypasses access controls.

Encryption in transit protects data moving over the network — a prompt travelling from your application to a foundation model, or a response coming back. This is handled with TLS (HTTPS), so the data cannot be read or altered while it moves between components.

For an AI workload you want both. Data sits encrypted in storage, moves encrypted across the wire, and is decrypted only where it is legitimately used. A common exam distractor offers encryption in only one state; the complete answer covers data both at rest and in transit. Encryption also supports compliance requirements, but its first job here is straightforward: keep the data confidential end to end.

Amazon Macie finds sensitive data in Amazon S3, and AWS PrivateLink keeps traffic to AI services on a private network path — two narrow problems that each map to one service.

Amazon Macie uses machine learning and pattern matching to discover sensitive data, such as personally identifiable information (PII), stored in Amazon S3. Before you train or fine-tune a model, you want to know whether names, email addresses, payment-card numbers or health records are sitting in the data, so you can remove or mask them before they end up baked into a model. Macie offers two ways to look. Automated sensitive data discovery runs continuously: Macie samples objects across your buckets every day and keeps a running view of which buckets are likely to hold sensitive data — a good fit when new files keep landing in many buckets. Sensitive data discovery jobs are targeted scans you define and run, once or on a schedule, over specific buckets for a deeper look. Either way, Macie reports what sensitive data it found and where; it does not clean the data for you.

AWS PrivateLink provides private connectivity between your virtual private cloud (VPC) and AWS services, so requests never traverse the public internet. For Amazon Bedrock and Amazon SageMaker AI you create an interface VPC endpoint — an elastic network interface with a private IP address in your subnet. (Gateway endpoints exist only for Amazon S3 and Amazon DynamoDB, so they are not how you reach Bedrock.) A NAT gateway or internet gateway would still send the traffic over public endpoints, which is exactly what a sensitive workload — a bank sending customer prompts to a foundation model — wants to avoid.

An interface endpoint can carry its own VPC endpoint policy, a resource policy that limits what can be done through that endpoint: for example, allowing only the invoke actions on one approved model. The endpoint policy works alongside IAM: a request must be allowed by both the caller's identity policy and the endpoint policy, so even a role with broader Bedrock permissions cannot use the endpoint to call an unapproved model.

The two services are complementary: Macie protects the data before it is used, and PrivateLink protects the connection while the AI system is used.

AI systems face every traditional cloud threat plus risks that come from the model itself — prompt injection, data leakage and toxicity — so you layer AI-specific controls on top of general cloud security.

General cloud security still applies: application security (secure code, authenticated APIs), threat detection (for example Amazon GuardDuty spotting suspicious activity), vulnerability management (for example Amazon Inspector scanning instances and container images) and infrastructure protection (network isolation, AWS WAF, AWS Shield against DDoS). These address stolen credentials, unpatched software and network attacks, whether or not a model is involved.

Prompt injection is the signature AI threat: an attacker hides instructions inside the input — typed directly, or embedded in a document or web page the model reads — so the model ignores its original instructions and does something unintended, such as revealing hidden data or calling a tool it should not. Data leakage is the risk that a model exposes sensitive information — from its training data, its retrieved documents or another user's session — in its responses. Toxicity covers harmful, offensive or hateful output. Because model behaviour is probabilistic, you cannot fully prevent these with input rules or instructions alone.

The defenses are layered. Treat every input as untrusted, and screen it (Amazon Bedrock Guardrails can detect prompt attacks). Apply output filtering and validation so responses are checked before they reach the user. Practise data leakage prevention by keeping sensitive data out of prompts and training sets and limiting what the model and its tools can reach — an injected instruction can only misuse access the system actually has. And keep an audit trail of the interactions, covered next. No single control is enough; AI security is defense in depth around an unpredictable model.

An audit trail for AI records what was asked and answered as well as who called which model, and on AWS that takes two complementary logs: Amazon Bedrock model invocation logging and AWS CloudTrail.

Because invocation logs contain the prompts and responses themselves, they are sensitive data and need the same protection as any other. Encrypting the destination with SSE-S3 protects the data at rest but leaves the key entirely to AWS. Encrypting it with a customer managed AWS KMS key (SSE-KMS on the S3 bucket, or a KMS key on the CloudWatch Logs log group) gives you control of the key policy — who may decrypt the logs — and every use of the key is itself recorded in CloudTrail. Add tight IAM access to the bucket or log group, and a retention period that matches your compliance requirements. Policy in AgentCore and AgentCore Gateway add their own logs of agent tool calls and policy decisions (in Amazon CloudWatch) to the audit record.

Documenting data origins means recording where data came from and how it changed, so every model and every answer can be traced back to trusted sources. Trustworthy AI starts with knowing your data's origin. Source citation and documenting data origins is the practice of recording where training and reference data came from and how it was transformed. Data lineage tracks that journey — from raw source, through cleaning and transformation, to the dataset a model finally trains on — so you can answer where a given piece of data originated. Data cataloging keeps an organized inventory of datasets with descriptions, owners, and locations, so teams can find and govern data rather than losing track of it.

Source citation works at the level of a single answer. When a generative AI application answers from your documents — for example with Amazon Bedrock Knowledge Bases — the response returns citations that point to the source passages used, so a reader can check each answer against the text that supports it. That is different from documenting a model or a dataset as a whole: a citation says where this answer came from, while lineage and catalogs describe where the data came from and model cards describe the model.

Amazon SageMaker Model Cards support this by documenting a model in one place: its intended use, the data it was trained on, how it was evaluated, and known limitations. A Model Card becomes the record that later answers what went into this model and why we trust it. It is documentation, not version control: Amazon SageMaker Model Registry tracks model versions and approval status, and Amazon SageMaker Clarify produces bias and explainability reports that a card can reference.

Alongside documentation, secure data engineering keeps the pipeline itself trustworthy. Best practices include assessing data quality so the model does not learn from bad or biased inputs, applying privacy-enhancing technologies such as masking or anonymizing personal data, enforcing data access control so only authorized people touch the data, and protecting data integrity so records are not tampered with or corrupted. Together these give you data you can trust and prove the origin of — foundations that make every later security and grounding control meaningful.

You reduce hallucinations — confident statements that are false — by grounding the model in trusted sources, then validating and scoring each response before anyone relies on it.

Grounding ties a model's answer to verified sources instead of letting it invent facts. The main technique is Retrieval Augmented Generation (RAG): at answer time the system retrieves relevant passages from an approved, current knowledge base (for example Amazon Bedrock Knowledge Bases) and supplies them to the model, which answers from that context. RAG needs no retraining and stays current as the documents change, which is why it is preferred over fine-tuning when the goal is factual accuracy on your own content. Simply adding a system-prompt instruction such as say you don't know if you aren't sure is not a reliable control: it supplies no facts, and the model has no dependable way to tell when it is wrong.

Grounding lowers the rate of hallucination but does not eliminate it — a model can still add details that are not in the retrieved passages. So you add output validation, checking each response before it is used: against the source, against business rules, or against an expected format such as a JSON schema. Amazon Bedrock Guardrails provides a source-based check called the contextual grounding check. Given the grounding source, the user's query and the model's response, it scores grounding (is every claim supported by the source? new information counts as ungrounded) and relevance (does the response answer the query?). You set a threshold for each, from 0 to 0.99, and responses scoring below it are blocked. It is built for summarization, paraphrasing and question answering over a supplied source, not for open-ended conversational chat.

Confidence scoring generalises that idea: attach a score to each answer and route anything below a threshold to a fallback — a human agent, a clarifying question or a refusal — instead of trusting every response equally.

Amazon Bedrock Guardrails is the configurable safety layer on inputs and outputs: content filters (hate, insults, sexual content, violence, misconduct and prompt attacks), denied topics, word filters, sensitive-information filters that block or mask PII, and the contextual grounding check. You attach a guardrail to calls to Bedrock models, and you can use the ApplyGuardrail API to evaluate any text against the same guardrail without invoking a Bedrock model — for example the prompts and responses of a model hosted on an Amazon SageMaker AI endpoint or outside AWS — so one policy covers every model you run. Guardrails is covered in more depth as a responsible-AI feature; here treat it as the enforcement point for what goes into and comes out of the model.

An AI agent does more than answer: it calls tools and APIs on someone's behalf, so securing it means controlling whose credentials it uses (Amazon Bedrock AgentCore Identity) and which actions it may take (Policy in AgentCore).

AgentCore Identity: credentials for agents

Amazon Bedrock AgentCore Identity is the identity and credential service for agents. Each agent gets a workload identity, and AgentCore Identity handles both directions of access. Inbound, it authenticates who is calling the agent — through IAM or an existing identity provider. Outbound, it obtains the credentials the agent needs for downstream tools — OAuth tokens and API keys — and keeps them in a token vault encrypted with AWS KMS (optionally a customer managed key), so developers never hard-code secrets in agent code.

Outbound access comes in two forms:

• User-delegated access (OAuth authorization code flow, sometimes called 3-legged OAuth): the end user signs in to the third-party service and consents; the agent then acts with that user's own permissions, such as opening a pull request in that developer's code repository.
• Machine-to-machine access (OAuth client credentials, 2-legged OAuth): the agent acts as itself, with no end user involved, such as syncing account records into a CRM under a service account.

Compare that with storing one API key per user in AWS Secrets Manager. Secrets Manager stores and rotates secrets well, but the team is still collecting and holding each user's secret, and nothing in that design asks the user to consent. AgentCore Identity's user-delegated flow gets access from the user's own sign-in and scopes the token to that user.

Policy in AgentCore: rules the agent cannot talk its way around

Policy in AgentCore enforces deterministic rules on what an agent may do. Policies live in a policy engine attached to Amazon Bedrock AgentCore Gateway, which intercepts every tool call the agent makes and evaluates it before the tool runs. Policies are written in Cedar, AWS's open-source authorization language, or described in natural language and translated into Cedar and validated. A rule can test the caller's identity, the tool being called and the tool's input parameters — for example, allow the discount tool only when the requested discount is 15 percent or less.

The key distinction is where the rule lives:

The two controls work together: AgentCore Identity decides what the agent can reach and on whose behalf, and Policy in AgentCore decides which of those calls are allowed. IAM still governs the AWS resources the agent's runtime role can touch.

Securing a generative AI application end to end means stacking these controls so each covers a different layer. Here they are at a glance, then a walkthrough that uses them together.

Walkthrough. A company builds a question-answering assistant over its product documentation on a foundation model. First it runs Macie over the knowledge base in S3 to find and remove stray PII, and encrypts the bucket with KMS. The application assumes an IAM role that allows only invoking the model and reading that one knowledge base. Requests reach the model through PrivateLink, so prompts never travel the public internet, protected by TLS in transit. The assistant answers each question from passages retrieved from the approved documents (RAG grounding), so it does not invent facts. Bedrock Guardrails screens prompts for attacks, filters the output, masks PII and blocks answers that fail the contextual grounding check. Model invocation logging writes every prompt and response to an S3 bucket encrypted with a customer managed KMS key, while CloudTrail records who called the model. When the assistant later gains an agent that applies discount codes, AgentCore Identity supplies its credentials and Policy in AgentCore caps the discount each call may apply. Each control covers one half of the shared responsibility model — and together they secure the app from access through output.