AWSAWS Certified Generative AI Developer - Professional2026-102.3 Design and implement enterprise integration architectures

Authorize each user before agent access

Completed by the knowledge check

Learning objective

Enforce each end user’s access to tools and retrieved data separately from the agent or FM service-role permissions.

Core idea

A shared agent role can legitimately access resources for many users. That role does not prove that the person making a request may access every resource the agent can reach. Your application must enforce both workload authority and end-user entitlement before a tool executes or evidence enters the model context.

For a senior engineer building an enterprise agent, the decision is where to enforce the user’s permission. Put it at the trusted retrieval or tool boundary. A prompt asking the model to respect permissions cannot replace a denial enforced by backend code and the resource’s authorization mechanism.

The identity flow in 2.3.6 establishes who signed in. This lesson binds that verified identity to the requested operation and data, including requests proposed by the model itself.

How it works

Establish a trusted caller context

For an API Gateway HTTP API, a JWT authorizer validates the caller’s token. It checks signature and claims including iss, aud or client_id, and time claims. With route authorizationScopes, the token must contain at least one configured scope through scope or scp. API Gateway passes validated claims to the integration through requestContext.authorizer.jwt.claims.

Use that context to derive the application identity. Do not accept a replacement user identifier, tenant, or group list from prompt text or model-produced tool arguments. Those fields are untrusted request content even when the same request also carries a valid token.

A route scope is an entry gate, not an ownership check on every object. A token allowing proposal updates does not prove access to a specified proposal. In the tool adapter, combine verified identity, allowed operation, target object, and authoritative entitlement before the downstream call. Reject absent or ambiguous entitlement rather than broadening the request to make it succeed.

Keep the model’s inputs separate from this trusted context. The model can choose a proposed operation and supply task arguments. Your adapter supplies caller identity and policy constraints through a path the model cannot overwrite.

Authorize tool execution

IAM policies define the actions a workload can perform on resources under specified conditions. Use them to limit the service role’s maximum reach. Then enforce the user’s business permissions in the adapter or target system. These controls answer different questions: can this workload call the service, and can this person perform this operation on this object?

Amazon Verified Permissions can externalize this business authorization decision. It evaluates whether a principal may perform an action on a resource in a given context using policies written in Cedar. It assumes the principal is already authenticated, for example through Cognito. The adapter supplies verified identity, the proposed action, the target resource, and trusted context to this policy decision point before using its shared role. An allow decision permits the adapter to proceed within the IAM workload ceiling; a deny decision stops execution. Verified Permissions does not replace either authentication or the role policy.

The model proposes the operation; the adapter supplies verified identity, and only an allow decision lets it proceed within the IAM workload ceiling.

For a shared service credential, the adapter must perform the user check before exercising that credential. Where the target has a user-delegated access mechanism, validate that its credential belongs to the authenticated user and has the required scope. Do not replace a denied delegated call with a broader shared credential as a recovery shortcut.

Treat authorization as specific to an invocation. A successful document read does not authorize an update to that document. A prior approval does not authorize different arguments. A check performed when the agent session began may be stale by the time a high-impact operation runs. Recheck the relevant entitlement at execution and bind the result to the exact action; approval handling is covered in 2.1.9.

Log the decision without exposing credentials: caller identity, requested operation, target, policy outcome, and correlation identifier are useful. Raw bearer tokens and unrelated document content are not necessary to explain a denial. This record is an application design responsibility rather than an automatic consequence of assigning a service role.

Authorize retrieved evidence

For metadata-filtered Knowledge Bases retrieval, construct the filter on the trusted backend. RetrievalFilter supports equals for a matching metadata key and value and andAll for the conjunction of filter conditions. andAll requires at least two members. The filter type is a union: each filter node specifies one member.

For example, combine the verified tenant’s metadata condition with the permitted document class. The field names and entitlement mapping are application choices, not built-in AWS tenant identifiers. See 1.4.6 for the retrieval and authoritative document-check design; the addition here is preserving the same verified caller context across the agent’s tools and evidence path.

For ACL-enabled Bedrock Managed Knowledge Bases sources, derive Retrieve.userContext.userId from the same verified caller context used for tools. AWS states that ACL awareness provides ACL-aware filtering, not authorization, and that the knowledge base does not authenticate end users. Non-ACL sources in a mixed-source knowledge base remain a separate access-policy case; see 1.5.11 for identity mapping, missing-context behavior, and revocation constraints.

Preserve the boundary after retrieval

Apply the same caller binding to citations, conversation history, and any application answer cache. A correctly filtered retrieval cannot prevent leakage from a cache shared across users with different entitlements. Include the relevant authorization scope and policy revision in the cache design, or avoid reuse where permission equivalence cannot be established.

These are application safeguards, not automatic promises of the retrieval API. Test them by changing one variable at a time: same question, different user; same user, revoked permission; same document identifier, different operation. A correct answer can be a denial or an empty evidence set.

Key distinctions and trade-offs

Role permission versus user entitlement: The workload role limits what the application can reach. User authorization limits what it may do for a particular caller. A shared role needs both checks.

Token scope versus object permission: An API scope authorizes a category of request. The target system or adapter must still enforce object-level access.

Metadata filtering versus managed ACL awareness: Trusted metadata filters implement your indexed policy projection. Managed ACL-aware sources accept verified userContext and apply their documented ACL behavior. Neither authenticates an arbitrary user identifier in a request body.

Availability versus confidentiality: Returning no evidence after a failed entitlement check preserves the boundary. Falling back to an unfiltered search increases availability by changing the security policy.

Architecture / decision scenario

A proposal agent serves two account teams through one workload role. Both teams can invoke the API, but only one may access a confidential customer proposal. The model asks to retrieve that proposal and then update its price.

The HTTP API authorizer validates the token and passes claims to the adapter. The adapter derives the caller, constructs tenant-bound retrieval filters for the ordinary index, and supplies verified userContext.userId for an ACL-enabled managed source. It treats non-ACL sources as a separate policy case.

Before updating the price, the tool adapter checks the caller’s write entitlement on the proposal. A read permission does not satisfy it. If write access is denied, the adapter returns a denied outcome and never uses the shared service credential for the update. Changing the user identifier in tool arguments cannot change this result.

The acceptance test repeats the request for the other account team and after revocation, including cached answers and the managed source’s documented credential-cache window.

Common exam traps

Equating a valid token with permission on every requested object.
Using the agent role as the end-user authorization decision.
Accepting a model-generated tenant or user identity as trusted context.
Assuming ACL-aware retrieval authenticates the supplied email address.
Assuming missing user context blocks non-ACL sources too.
Repairing a denied operation with a broader service credential.

What to remember

Bind every retrieval and tool call to verified caller context.
Enforce IAM workload limits and user entitlements independently.
Authorize the operation and object before executing a proposed tool call.
Scope ACL behavior to enabled managed data sources.
Include revocation and cache reuse in authorization tests.