A generative AI application faces the usual security risks of any application, plus new ones: prompts that try to hijack the model, answers that leak private data, toxic content, and conversations that need an audit trail. No single control covers all of this. This lesson goes beyond recognising prompt attacks to the controls a team puts around an AI system: filtering what goes in and comes out, keeping private data out of answers, logging every interaction, encrypting data, and finding threats and vulnerabilities.
Defense in depth
Security for AI works in layers, so one failure doesn't expose everything:
- Identity and access. Only approved people and services can call the model or read its data.
- Network. Private connections such as AWS PrivateLink keep traffic off the public internet.
- Input checks. Prompts are screened before the model sees them.
- Output checks. Responses are screened before the user sees them.
- Monitoring. Logs and alerts show what happened and when.
AWS's guidance for generative AI recommends validating prompts before they reach a model, for example with guardrails, size limits and rate limits, and combining those with checks in the application itself. Prompt-level defences, such as clear instructions in a system prompt, help but can be talked around, so they're never the only layer.
Filtering inputs and outputs
Data leakage happens when a model reveals information the user shouldn't get, such as another customer's details or confidential documents. Two controls work together:
- Limit what the model can see. In a RAG application, filter retrieval so each user only gets documents they're allowed to read. Bedrock managed knowledge bases offer ACL-aware retrieval for this: your app authenticates the user and passes their identity, and only documents they may read come back. A model can't leak a document it never received.
- Filter what comes out. Amazon Bedrock Guardrails can block or mask personal data in responses.
Toxicity is hateful, abusive or threatening content, in user input or model output. Bedrock Guardrails content filters cover model conversations. For text from other sources, Amazon Comprehend detects toxic content. For recorded speech, Amazon Transcribe toxicity detection analyses both the words and the tone of voice. That feature works on batch transcription in US English.
Logging and audit trails
Two AWS logs answer different questions:
| Log | What it records | Question it answers |
|---|---|---|
| Amazon Bedrock model invocation logging | Full request and response bodies, model ID, caller identity, token counts | What exactly did users ask, and what did the model say? |
| AWS CloudTrail | API calls such as InvokeModel, CreateGuardrail and DeleteGuardrail, with who made them, when and from where | Who changed or called what? |
Invocation logging is off by default and sends logs to Amazon CloudWatch Logs, Amazon S3 or both. Because these logs hold real prompts, they can contain personal data, so encrypt them with AWS KMS and limit who can read them.
Encryption in transit and at rest
Bedrock requires TLS 1.2 for API connections and recommends TLS 1.3. At rest, you can use AWS KMS keys you manage for custom models, knowledge base data sources, agents and evaluation jobs. Training data and documents in S3 can use server-side encryption with KMS keys.
Threats and vulnerabilities
- Threat detection. Amazon GuardDuty analyses CloudTrail events and can flag suspicious Bedrock activity, such as a user signing in from an unusual place and then removing a guardrail.
- Vulnerability management. When you host models yourself, Amazon Inspector continuously scans EC2 instances, container images in Amazon ECR and Lambda functions for known software vulnerabilities and unintended network exposure.
On the exam
"Record every prompt and response" points to model invocation logging. "Who deleted or changed it" points to CloudTrail. "Users see data they shouldn't" means restrict access at retrieval, not just in the prompt. "Known vulnerabilities in our model's containers" points to Amazon Inspector.