AWSAWS Certified Generative AI Developer - Professional2026-103.2 Implement data security and privacy controls

Authorize requests before trusting model instructions

Completed by the knowledge check

Learning objective

Enforce IAM identity and resource policies plus application authorization independently of model prompt instructions.

Core idea

An agent can propose an operation; it cannot grant permission to perform it. AWS policies decide whether an AWS principal may call a service on a resource. Your application separately decides whether the authenticated person may access a particular record or authorize a business action.

A prompt such as “only read the user’s records” describes desired model behavior. It does not change the credentials attached to a request or create a binding authorization rule. Enforce permissions in trusted code and service policy evaluation before data enters the model context or a tool causes an effect. A refusal generated after unauthorized retrieval arrives too late to protect the data.

How it works

Identify the principal at each boundary

Begin with a request map: authenticated person, application workload, retrieval service, and action executor. Record which principal signs each AWS API call and which identity your application uses for entitlement checks. An application role can represent the workload without representing the user’s full business identity.

Identity-based policies attach to IAM users, groups, or roles and define permitted actions and resources. Resource-based policies attach to supported resources and identify permitted principals. In a resource policy, Principal identifies who receives the grant; Action, Resource, and Condition describe its scope. Resource-level permissions are a separate concept: an identity policy can name a resource ARN without becoming a resource-based policy.

For example, an S3 bucket policy controls access to the bucket, while an application role’s identity policy controls that role’s S3 operations. Use a role appropriate to the workload and limit its actions to the required operations and resource ARNs. Keep retrieval and mutation capabilities distinct when they have different business consequences. This makes the service credential’s authority reviewable even if the model proposes an unexpected operation.

Evaluate the applicable policies correctly

For ordinary same-account permissions-policy evaluation, AWS combines identity-based and resource-based allows. An explicit deny in either overrides an allow. Do not describe the two policy types as a universal intersection in which both must always contain an allow. A resource-based allow can grant same-account access even when an identity policy does not independently grant that action.

Cross-account resource access requires permission on both sides: the requesting principal’s account must allow the request, and the resource’s account must allow that principal. An identity allow alone cannot establish the remote resource’s trust. Conversely, a resource policy that names an external account is not evidence that every intended caller in that account has the identity permission it needs. An explicit deny decides first; after it, same-account access needs one allow and cross-account access needs both sides.

Other policy types change the result. Permissions boundaries and session policies limit applicable identity permissions and same-account resource-policy grants to a role ARN; AWS Organizations service control policies constrain principals, and resource control policies constrain resources in their scope. These controls do not replace the need to examine the actual request and principal. Start diagnosis with the applicable explicit denies, then inspect which allows and limits apply.

Principal type matters. Within the same account, a resource policy granting access directly to a role session ARN can escape implicit denies in identity policies, permissions boundaries, or session policies. An applicable explicit deny still wins. AWS also documents special treatment for IAM role trust policies and KMS key policies. Use the service’s documented evaluation rules rather than assuming that a missing allow in one policy always creates a reliable restriction.

Match policies to supported resources

Amazon Bedrock supports identity policies for service access. Its documented resource-policy support applies to guardrails and guardrail inference profiles. Do not infer that every Bedrock resource accepts an attached resource policy because the service supports that policy type somewhere.

For inference restrictions, AWS documents bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream, and bedrock:CreateModelInvocationJob in a deny policy targeting a foundation-model ARN. Denying InvokeModel also blocks dependent invocation operations such as Converse. Choose the permission set from the actual synchronous, streaming, or batch path; do not assume a deny covering one interface necessarily covers every independent inference mechanism.

Resource policies on downstream S3 buckets, queues, or secrets protect those resources separately from model invocation. A role permitted to invoke a model does not thereby gain permission to read its grounding corpus or retrieve a tool credential. Maintain these policy boundaries even when the application presents a single conversational interface.

Enforce the business decision in the application

Before retrieval, bind the request to a verified user and trusted entitlement data. Decide which tenant, document set, and fields that person may access. Before a tool executes, evaluate the proposed resource and operation against that same trusted context. Reject missing identity, a mismatched tenant, an unauthorized record, or an operation outside the allowed action set.

Define the business entitlement model independently of IAM. Amazon Verified Permissions can externalize that application decision through Cedar policies; see 2.3.7. Do not use a tenant ID supplied in a user message or model-generated tool argument as proof of ownership. Resolve the authorized scope independently and compare the proposal with it. The model may supply a candidate document ID, but it must not supply the authority to read that document.

Return an authorization failure to the workflow without giving the agent a more powerful fallback role. If a legitimate task needs approval, use a separate authenticated approval boundary; see 2.1.9. Retrieval-specific entitlement handling and tool authorization are covered in 2.3.7. This lesson’s decision is where those checks stand relative to AWS policy evaluation: both must pass, and neither depends on obedience to a prompt.

Key distinctions and trade-offs

Service authorization versus record entitlement: IAM evaluates AWS principal, operation, resource, and request context. Your application evaluates the person’s permitted business scope. A shared service role makes this distinction especially important.

Implicit deny versus explicit deny: A missing allow is not equivalent to an explicit deny when another applicable policy grants access. Inspect the principal type and policy combination before relying on absence as a restriction.

Resource policy versus resource ARN: Naming a bucket or model ARN narrows a statement’s resources. Attaching a policy to a supported resource defines a different policy surface.

Model instruction versus enforcement: Instructions guide the proposed behavior. Trusted checks and AWS policy evaluation determine whether the proposal can execute.

Architecture / decision scenario

A claims assistant serves multiple customers using one application role. That role may invoke an approved Bedrock model and read a constrained S3 corpus. A bucket policy also grants a partner account access to an approved export prefix.

The team reviews the application identity policy, the bucket policy, and the partner’s cross-account identity permission as separate policy inputs. It checks for explicit denies and does not treat the bucket policy as a second mandatory allow for every same-account read.

For each conversation, the application derives customer identity from the authenticated session. A model-proposed document read must pass the customer’s entitlement check before the S3 call. A prompt injection that asks for another customer’s file fails that check even though the shared AWS role could read it. A denied request does not trigger a retry under an administrator role.

Common exam traps

Treating a system prompt as an access-control policy.
Assuming the workload role proves the end user’s record entitlement.
Requiring both identity and resource allows for every same-account request.
Forgetting explicit denies or principal-specific session evaluation.
Assuming every Bedrock resource supports an attached resource policy.
Checking authorization only after retrieved data enters the model context.

What to remember

Identify the AWS principal and business identity separately.
Evaluate the actual policy combination and service exceptions.
Scope inference and downstream data permissions independently.
Authorize retrieval and effects before they occur.
Model proposals never create permission.