Securing AI systems with IAM and encryption

Gwen Halvorsen, the cloud architect leading the AWS move, joined Noor's session for this topic. She had spent the autumn securing Cascade Ridge's accounts: protecting the root user, setting up IAM Identity Center, encrypting data with AWS KMS and turning on detection services. "AI doesn't replace any of that," she told Jonah. "It sits on top of it. An AI application is still an application. It has identities, it reads data, it calls services and it writes logs. Every one of those is something to secure."

What is new, Gwen explained, is that AI applications handle unusually sensitive material, such as entire call transcripts, and can take actions on a user's behalf. This lesson applies the security basics to AI: identity and permissions, encryption, private networking, data discovery, controls for agents, and the shared responsibility model for AI services. The exam guide names these services and features in its security task statement.

The shared responsibility model for AI

The shared responsibility model applies to AI services just as it does to the rest of AWS. For a managed service such as Amazon Bedrock, AWS is responsible for the security of the service itself: the infrastructure, the model hosting environment, and keeping customers' data separate. Amazon Bedrock does not use customers' prompts and responses to train the foundation models it offers, and model providers do not receive them, according to AWS's documentation; check the current terms for any service you use.

The customer is responsible for security in the cloud: who in the organization may call the models, what data is sent to them, how that data is encrypted, how outputs are handled, which guardrails apply, and what is logged. When a customer fine-tunes a model with its own data, the resulting custom model and the training data are the customer's to protect.

Identity and permissions

The first layer is identity. Every person and every program that touches the AI system should have its own identity with the least privilege it needs.

• People sign in through IAM Identity Center with their own identities. Noor has permission to experiment with models in the development account. Jonah can view evaluation results but not change the production configuration.
• Applications use IAM roles, which provide temporary credentials automatically. The summarizer runs with a role that can call one specific model, apply one specific guardrail, and read from one specific bucket. There are no long-term access keys in its code.
• Policies state exactly what each role may do. IAM policies can name the specific foundation models a role may invoke, so a developer cannot quietly switch to a different model, and can require a guardrail on every call.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InvokeApprovedModelOnly",
      "Effect": "Allow",
      "Action": ["bedrock:InvokeModel"],
      "Resource": "arn:aws:bedrock:REGION::foundation-model/APPROVED-MODEL-ID"
    },
    {
      "Sid": "ApplyApprovedGuardrail",
      "Effect": "Allow",
      "Action": ["bedrock:ApplyGuardrail"],
      "Resource": "arn:aws:bedrock:REGION:ACCOUNT-ID:guardrail/GUARDRAIL-ID"
    }
  ]
}

In the multi-account setup Gwen built, service control policies in AWS Organizations add an outer limit: for example, denying the use of any foundation model in Regions outside the approved ones. Even an administrator in a member account cannot override that. Lesson 8 shows why this matters for data residency.

# How an allow-list of approved models works, in miniature.
APPROVED = {"summarizer-role": {"approved-text-model-v2"}}
requests = [
    ("summarizer-role", "approved-text-model-v2"),
    ("summarizer-role", "experimental-model-x"),
    ("web-assistant-role", "approved-text-model-v2"),
]
for role, model in requests:
    allowed = model in APPROVED.get(role, set())
    print(f"{role:18} -> {model:24} {'ALLOW' if allowed else 'DENY (not approved for this role)'}")

summarizer-role    -> approved-text-model-v2   ALLOW
summarizer-role    -> experimental-model-x     DENY (not approved for this role)
web-assistant-role -> approved-text-model-v2   DENY (not approved for this role)

The default is deny. A role with no entry in the list gets nothing, which is how IAM itself works: anything not explicitly allowed is denied.

Encryption

The second layer is encryption, which the exam guide lists as encryption at rest and in transit.

• In transit. Calls to AWS service endpoints, including Amazon Bedrock, use TLS. Internal traffic, such as from the clinical system to the summarizer, should also use TLS.
• At rest. Data stored for the AI system, such as transcripts in Amazon S3, knowledge base content, fine-tuning datasets, custom models and logs, is encrypted with keys in AWS Key Management Service (AWS KMS). AWS services encrypt much of this by default; using a customer managed key lets Cascade Ridge control the key policy, see every use of the key in AWS CloudTrail, and disable the key if needed.

Hannah chose customer managed keys for the transcripts and for the summarizer's logs, because those held the most sensitive content. Disabling the key would make the data unreadable, which gave her a strong control in an emergency.

Private networking

The third layer is the network. By default, an application calls AWS services through their public endpoints, over the internet but encrypted. AWS PrivateLink lets an application in a VPC reach supported services, including Amazon Bedrock and Amazon SageMaker AI, through interface VPC endpoints, so the traffic stays on the AWS network and never crosses the public internet. Endpoint policies can further limit which actions and resources are allowed through the endpoint.

Gwen placed the summarizer's processing in private subnets with no route to the internet and gave it interface endpoints for Bedrock, S3 and KMS. "If someone ever gets code running in that subnet," she said, "it has nowhere to send our data except the services we chose."

Finding sensitive data with Amazon Macie

You cannot protect sensitive data you do not know you have. Amazon Macie uses machine learning and pattern matching to discover sensitive data, such as names, phone numbers, addresses and payment card numbers, in Amazon S3 buckets, and reports where it is and whether the buckets are exposed. The exam guide names Macie among the services that secure AI systems because AI projects often gather large amounts of data into new places.

Before Noor assembled the 300 transcripts for the summarizer's evaluation, Hannah ran Macie on the bucket. It found client phone numbers and two card numbers that callers had read aloud to pay a bill. The evaluation set was rebuilt with those details masked, and the finding became a requirement for the production design: card numbers spoken on calls are masked before any transcript is stored.

Controls for agents

When AI systems act through tools, their identities and permissions need special care. The exam guide names two features of Amazon Bedrock AgentCore, AWS's set of services for running AI agents.

• AgentCore Identity manages identities and credentials for agents, so an agent can act for a specific user, or on its own behalf, with credentials it obtains securely when needed, instead of secrets stored in its code.
• Policy in AgentCore lets you define rules, written in the Cedar policy language, that decide which tool calls an agent may make and under what conditions. It checks each call before it reaches the tool and denies anything not explicitly permitted.

For the booking agent idea from lesson 6, Noor sketched the policy in plain words: the agent may search for open slots and hold a slot for ten minutes; it may book only for the client who is signed in; it may never cancel a booking it did not make; and any surgery booking requires staff approval. The point is that limits are enforced outside the model. Even if the model were manipulated into trying something else, the policy would deny it.

Protecting knowledge bases and training data

Generative AI systems often draw on a knowledge base: a collection of documents that is split into chunks, converted to vectors and stored so the system can retrieve relevant passages for each question. The website assistant's knowledge base held clinic hours, parking instructions, booking policies and the list of services. A knowledge base is data like any other, and it needs the same protection, plus one extra thought: anything in it might be quoted to a user.

Noor and Hannah agreed two rules. First, a knowledge base for a public assistant contains only material that is already public, so even a perfect attack could reveal nothing secret. Client records never go near it. Second, if an internal assistant ever needs access to restricted documents, the retrieval step must respect the user's own permissions, so the system cannot hand someone a passage they would not be allowed to open themselves. The same thinking applies to fine-tuning data: a model trained on sensitive records can sometimes reproduce parts of them, so sensitive fields are removed before training, not after.

Threat detection and vulnerability management

The exam guide also lists threat detection, vulnerability management and infrastructure protection among the security considerations for AI systems. These are the same services that protect the rest of the environment. Amazon GuardDuty watches account activity, network traffic and other signals for threats, such as credentials being used from an unusual location or an instance contacting a known malicious address; it also offers protection for some AI workloads. Amazon Inspector scans EC2 instances, container images and Lambda functions for known software vulnerabilities and unintended network exposure, which matters because AI applications are built from code libraries that need patching like any others. AWS WAF can filter abusive traffic to a public assistant, such as floods of requests from a single source.

Gwen had already turned these on across all accounts during the autumn. For the AI workloads she added one alarm: an unusual rise in calls to Bedrock from any role, which could signal a stolen credential being used to run up costs or extract data.

Guardrails as a security control

Amazon Bedrock Guardrails, covered in lesson 4, is also a security feature. Sensitive information filters prevent personal data from leaking into responses, and the prompt attack filter helps detect attempts to override the system's instructions. Requiring a guardrail on every model call, through application code and IAM policy, makes sure no path skips it.