Securing generative AI requires familiar cloud controls plus protections for prompts, models, retrieval data, tools, and generated output. The current AWS Certified AI Practitioner AIF-C01 security, compliance, and governance domain covers methods to secure AI systems and recognize governance requirements. The practitioner-level goal is to understand the control model, not to implement every AWS service in detail.
For deeper AWS security engineering, AWS Certified Security – Specialty SCS-C03 is the more specialized path. At the AI Practitioner level, a secure design starts by identifying data flows, ownership, and trust boundaries: who may invoke the model, what data can enter prompts or knowledge bases, which resources the application can reach, how activity is logged, what external tools are trusted, and what the system may do with generated output.
Use IAM to separate people, applications, and service permissions
Human administrators, application runtimes, model-evaluation jobs, agents, data pipelines, and knowledge-base ingestion should not share one broad role. Separate build-time and runtime privileges so a deployed application cannot automatically customize models, change guardrails, or rewrite its own knowledge-source permissions. Protect powerful service-role passing because it can become a privilege-escalation path. Give each component only the permissions it needs, use temporary credentials where possible, and restrict which identities may pass service roles to AI services.
Review both identity policies and resource policies where AWS services support them. Conditions can limit access by account, network path, tag, resource, or context. Least privilege matters especially for agents and tool-enabled systems because model output may influence which API action the application attempts.
Protect prompts and retrieved data as sensitive application data
Prompts can contain customer records, source code, credentials, health information, internal policy, or other confidential content. Apply input validation and content-size limits before requests reach the model. Prevent accidental submission of secrets where feasible through client-side or service-side filtering, and train users not to paste credentials into general-purpose AI interfaces. RAG adds document stores, vector indexes, embeddings, metadata, and retrieval results to the data path. Classify these assets and restrict access before the model is invoked. Review whether prompts or retrieved documents cross account, region, or organizational boundaries. Private connectivity, service endpoints, network controls, and resource policies can reduce exposure, but identity authorization must still determine who can access the data.
Apply data minimization and retention rules to prompt histories and evaluation datasets. The same AI privacy practices that protect ML data also apply to generative applications. Do not log full prompts by default when a smaller audit record is sufficient.
Encrypt data in transit and at rest
Amazon Bedrock uses encryption for data in transit and supports encryption at rest for relevant resources, with AWS KMS options for supported custom models, agents, and other resources. Encryption does not replace access control: a principal allowed to invoke the service or read the protected store can still access decrypted data through authorized APIs. Design key and IAM permissions together. The application still needs to protect S3 buckets, databases, vector stores, secrets, logs, and network connections around the model service.
Key policy and identity policy should work together. Monitor key disablement, deletion scheduling, grants, and policy changes because encryption can become an availability dependency as well as a confidentiality control. Recovery procedures should verify that authorized systems can still decrypt required AI data after failover or account changes. Customer-managed keys can add control, but they also create availability and administration dependencies. Restrict key administration, monitor policy changes, and ensure recovery procedures account for encrypted backups and AI resources.
Guardrails provide application-level safety controls
Amazon Bedrock Guardrails can evaluate prompts and model responses using content filters, denied topics, word filters, prompt-attack detection, and sensitive-information filters. These features can help enforce application policy consistently across supported model interactions.
Configure guardrails for the actual use case rather than accepting a generic threshold. Maintain versioned guardrail definitions and evidence of test results. Because AWS can update underlying safeguard models, periodic regression testing helps confirm that allowed and blocked behavior still matches organizational policy after service changes. Test both false negatives and false positives, define user-facing blocked messages, and review behavior after guardrail updates. A guardrail is a policy enforcement layer, not a replacement for model evaluation, authorization, or application logic. Test behavior at the application boundary as well as the model call, because formatting, streaming, retries, tool execution, and postprocessing can create security outcomes that a content filter never sees.
Prompt injection is a trust-boundary problem
Generative applications often combine instructions from developers, users, retrieved documents, websites, or tool output. Classify each source by trust level and ensure lower-trust content cannot redefine higher-priority policy. Where external web or document content is ingested, sanitize and constrain it rather than presenting it to the model as trusted system instruction. Untrusted content can contain instructions designed to override the intended behavior. Treat retrieved text and external content as data, not as authority.
Separate system instructions from untrusted content, minimize tool permissions, validate tool arguments, and require confirmation for high-impact actions. Treat model-generated parameters as untrusted input to downstream systems. Enforce schema, value ranges, resource scope, and business authorization in application code before any tool or AWS API executes. If an agent can modify AWS resources, the IAM role—not the prompt—must be the ultimate boundary on what the system is capable of doing.
Knowledge bases need document-level authorization
RAG systems can accidentally create a data-leak path when a user is allowed to query a knowledge base containing documents they could not access directly. Test authorization with representative users from different roles and tenants, including denied cases. The retrieval layer should filter before content is sent to the model, not rely on the model to decide which retrieved passages should remain secret. Preserve access context in ingestion and retrieval, or separate knowledge bases when authorization models require it.
Deletion and retention also matter. Protect ingestion roles and source connectors so a compromised document system cannot silently poison the knowledge base. Track source provenance and update times, and alert when a high-value knowledge source stops synchronizing or changes unusually quickly. When a source document is removed or access changes, the index should be updated so stale chunks do not remain retrievable. Monitor ingestion failures and freshness so security policy is not based on an index that no longer matches the source.
Logging should cover management and application events
Use AWS audit capabilities such as CloudTrail for supported management and API activity, and add application logs that capture model invocation context without storing unnecessary sensitive content. Protect logs from modification and define retention that supports incident investigation. Redact tokens and private data before logging rather than trying to clean an exposed log store later. Track changes to IAM, guardrails, model access, knowledge bases, agents, encryption keys, and logging configuration.
Operational monitoring should also detect unusual invocation volume, cost spikes, repeated policy blocks, suspicious tool calls, unexpected regions, or identities accessing AI resources outside normal patterns. Correlate these signals with authentication and deployment events so responders can tell whether the cause is a stolen credential, a new release, abusive users, or a runaway agent loop. Security teams need enough context to distinguish user error, application defects, and deliberate abuse.
Governance connects security controls to policy and compliance
Maintain an inventory of AI applications, models, data sources, owners, risk classifications, and approved use cases. Include external model providers, plugins, tools, and downstream integrations because AI risk extends beyond the Bedrock resource itself. Shadow prototypes should not become production dependencies without entering the same governance process. Record which regions, accounts, models, and external integrations are allowed. Governance reduces shadow AI and gives security teams a place to apply consistent requirements.
Compliance evidence can include access reviews, encryption settings, evaluation results, incident procedures, data-retention controls, model approvals, and change history. Map each control to an owner and review frequency. Governance fails when evidence is produced once for an audit but no operating process keeps the control effective afterward. The organization should be able to show not only that a security feature exists but that it is configured, reviewed, and effective for the application.
Secure AI needs incident response and change control
Models, prompts, knowledge bases, guardrails, agents, and IAM policies all change. Treat significant changes as releases with testing and rollback. Cloud posture and detection services still matter around the hosting environment, but the AI application also needs controls specific to model inputs, outputs, retrieval, tool use, and the identities allowed to invoke each capability.
Prepare for compromised credentials, exposed prompts, poisoned knowledge sources, unexpected model behavior, leaked data, and unsafe automated actions. Assign a named incident owner before launch, along with backup contacts and clear escalation authority. Run tabletop scenarios that include revoking model access, disabling an agent, rotating secrets, isolating a knowledge source, changing a guardrail, and preserving audit evidence. Recovery must cover both cloud resources and AI-specific configuration. A secure generative-AI system is one the organization can continuously observe, constrain, revoke, recover, test, and revalidate under changing threats—not simply one that has encryption and a content filter enabled.
Agent and tool permissions deserve their own threat model. A model that can call a search index, ticketing system, database, or deployment API should receive only the operations and data needed for that workflow, with server-side authorization independent of the model’s text output. Treat tool arguments as untrusted input, validate them against policy, and preserve an audit trail so prompt injection cannot silently turn model influence into unrestricted application authority.