\nGenerative AI security spans identity, data, prompts, models, retrieval, tools, logs, network paths, secrets, and downstream actions. A production Bedrock application can be compromised without the foundation model itself being compromised: a leaked runtime role, permissive knowledge base, vulnerable tool API, exposed prompt log, or injected document can all create serious impact. Security therefore belongs in the application architecture around the model as much as in model safety configuration.<\/p>\n
The AWS Certified Generative AI Developer \u2013 Professional (AIP-C01)<\/a> exam treats security as an end-to-end application responsibility: IAM boundaries, sensitive data, model safety, retrieval authorization, tool permissions, and governance determine whether a workload is ready for production. AWS Certified AI Practitioner<\/a> covers foundational AI concepts; AWS Certified Machine Learning Engineer \u2013 Associate (MLA-C01)<\/a> refers to the earlier exam version of a related machine-learning engineering certification. AWS\u2019s MLA-C02 transition schedule<\/a> confirms that English MLA-C01 delivery ended September 28, 2026, while MLA-C02 English beta delivery began September 29. MLA-C01 remains available in Japanese, Korean, and Simplified Chinese during the announced transition to January 14, 2027 general availability.<\/p>\n Two users asking the same question may have different authorization to private account records. Filter sources from authenticated identity before retrieval and independently authorize downstream tool actions. Asking the model to hide unauthorized text after it has received that text is not an adequate boundary. Test a wrong-tenant request, a revoked role and a response cache that must not share private answers. Guardrails may help filter content, but do not replace IAM, secret handling or approved geography. Reassess privileges when new tools, memory services or connectors are introduced. Supported Bedrock Guardrails controls<\/a> vary by model and Region, so filtering policies need testing against the chosen deployment rather than assumption.<\/p>\n \nApplications should invoke Bedrock and downstream services through IAM roles or workload identities with only the actions and resources required. Separate development, staging, and production roles.<\/p>\n Do not give every GenAI workload broad `bedrock:*`, S3, KMS, database, and Lambda permissions for convenience. One prompt injection or application bug should not become account-wide authority.<\/p>\n The approved access-control principle applies: authority should follow the principal, resource, action, and relevant context.\n<\/p>\n \nUser prompts can contain PII, credentials, proprietary text, incident data, or regulated records. Model responses can echo or transform the same information.<\/p>\n The secure PII handling principle means minimizing collection, controlling retention, encrypting logs, and limiting who can inspect prompt content.<\/p>\n Do not enable full invocation logging by habit in every environment. Decide whether metadata, sampled content, or full content is required for the risk level.\n<\/p>\n \nUser prompts, retrieved documents, webpages, emails, and tool outputs can all contain instructions intended to override developer policy. Treat external text as data, not as trusted system instructions.<\/p>\n Bedrock Guardrails prompt-attack filtering can help detect jailbreak and prompt-injection patterns, but application authorization should remain independent.<\/p>\n The AI security risks context is important because successful injection becomes dangerous only when the surrounding system gives the model sensitive data or powerful tools.\n<\/p>\n \nRAG systems should filter documents according to user or tenant authority before passages enter the prompt. The most semantically relevant document may be confidential.<\/p>\n Knowledge-base service roles, OpenSearch Serverless access policies, KMS, S3 permissions, and application metadata filters can all participate in the security boundary.<\/p>\n Test with multiple identities and confirm an unauthorized user cannot retrieve protected text indirectly through generated answers.\n<\/p>\n \nTool interfaces should expose specific business actions with validation rather than arbitrary shell, SQL, or API access. Keep read and write capabilities separate where possible.<\/p>\n For sensitive actions, preserve user context and require explicit authorization or human confirmation. A model deciding to call a tool should not be equivalent to an IAM grant.<\/p>\n Make tools idempotent and bounded so retry or agent loops cannot create duplicate destructive actions.\n<\/p>\n \nDatabase passwords, API tokens, third-party credentials, and signing keys should come from workload identity or a managed secret system instead of prompt templates, notebooks, source repositories, or container images.<\/p>\n AWS Secrets Manager can keep runtime secrets out of prompt templates and source repositories when permissions and rotation are configured correctly.<\/p>\n Review traces and error messages so secrets are not exposed during tool failure or debugging.\n<\/p>\n \nGuardrails can enforce content filters, denied topics, sensitive-information controls, prompt-attack detection, and related supported policies. They are valuable for model-facing safety.<\/p>\n They do not determine whether a user may query a customer account, delete a record, or access a confidential dataset. Those are application and IAM authorization questions.<\/p>\n Layer controls so one failure does not collapse the full security model.\n<\/p>\n \nUse private connectivity, VPC controls, service endpoints, KMS encryption, S3 policies, and vector-store network policies where the architecture and risk require them.<\/p>\n The data-exfiltration perspective is especially important for applications that can retrieve large corporate corpora or invoke tools with outbound network access.<\/p>\n Network restrictions should reflect actual dependencies so security does not break required model or tool connectivity unexpectedly.<\/p>\n Security events should be monitored with evidence preservation in mind. Collect IAM changes, Bedrock invocation metadata, Guardrail interventions, knowledge-base changes, tool access, secrets access, network events, and application authentication signals.<\/p>\n Correlate them with request IDs so investigators can reconstruct one suspicious interaction across model, retrieval, and tool layers.<\/p>\n Keep retention long enough for delayed investigations while masking or restricting sensitive prompt content.\n<\/p>\n \nRunbooks should include revoking a runtime role, rotating tool secrets, disabling one prompt or model version, blocking a knowledge source, tightening a guardrail, or taking an agent tool offline without rebuilding the whole application.<\/p>\nStart with workload identity and least privilege<\/h2>\n
Protect prompts and responses as sensitive data<\/h2>\n
Defend against prompt injection at multiple layers<\/h2>\n
Enforce authorization before retrieval<\/h2>\n
Constrain tool execution and agent authority<\/h2>\n
Protect secrets outside prompts and code<\/h2>\n
Use Guardrails for content policy, not authorization<\/h2>\n
Secure network and storage paths<\/h2>\n
Practice incident response for GenAI-specific failures<\/h2>\n