AWSAWS Certified Generative AI Developer - Professional2026-102.1 Implement agentic AI solutions and tool integrations
Deploy agents with separate access boundaries
Completed by the knowledge check
Learning objective
Deploy agents with AgentCore Runtime and manage tool access using AgentCore Gateway and Identity.
Core idea
AgentCore Runtime, Gateway, and Identity solve different parts of a production agent architecture. Runtime hosts execution. Gateway provides controlled access to configured targets, including tools. Identity manages workload identities and credentials for accessing external services.
A complete design must answer four questions: who may invoke the agent, which version executes, which tools the agent may reach, and whose permissions those tools use. Deploying a container answers only the hosting question. Giving that container an execution role does not automatically authorize it to act as every customer.
Draw inbound and outbound access as separate boundaries. Inbound authentication establishes who is calling Runtime or Gateway. Outbound authentication establishes how an agent or Gateway authenticates to a target. Business authorization still decides whether that caller can perform the requested operation on the selected resource.
How it works
Deploy and invoke a Runtime version
CreateAgentRuntime creates a Runtime and its initial version. Updating its configuration creates another immutable version. Runtime endpoints reference specific versions and provide stable invocation addresses. The automatically created DEFAULT endpoint moves to the new version when the Runtime is updated.
Use CreateAgentRuntimeEndpoint to create an environment-specific endpoint when production must stay on a reviewed version. Non-DEFAULT endpoints must be explicitly updated: use UpdateAgentRuntimeEndpoint with agentRuntimeVersion to promote or roll back to the intended version. Treat that version reference as a release decision. Testing a candidate through one endpoint while production references another avoids coupling deployment of a candidate to immediate production use.
Your implementation must satisfy the service contract for its selected protocol. HTTP uses port 8080 and /invocations; MCP uses port 8000 and /mcp; A2A uses port 9000 and / (root). Do not copy the HTTP server contract to an MCP or A2A deployment without checking that protocol’s contract.
The AgentCore SDK’s BedrockAgentCoreApp provides the application entry-point abstraction used in AWS’s deployment examples. Whichever implementation you choose, verify request handling, health behavior, identity propagation, and the terminal response before promoting the endpoint. A healthy server can still have an incorrect tool authorization path.
Call InvokeAgentRuntime with the agent’s ARN and a session identifier for related interactions. Runtime handles execution infrastructure and session isolation. The backend still owns the relationship between authenticated users and sessions; see 2.1.3. Do not encode tenant authorization solely in a user-supplied session ID.
Place tool access behind Gateway targets
An AgentCore Gateway has configured targets. For MCP targets, Gateway aggregates their capabilities into a unified MCP server, giving clients a consolidated tools/list response. Tool invocation uses the MCP tools/call operation. See 1.5.10 for the retrieval-specific interface contract.
Target type matters. MCP targets can represent Lambda functions, API definitions, or MCP servers. HTTP targets proxy traffic directly without MCP aggregation or protocol translation. Inference targets route model traffic according to the requested model. A Gateway is therefore not universally an MCP translator for every configured target.
Configure inbound authorization to control who can reach the Gateway. AWS documents OAuth/JWT, IAM using AWS Signature Version 4, authenticate-only, and no-authorization configurations. Authenticate-only validates tokens while delegating authorization to the target; no authorization is intended for development and testing. Select a production design that actually enforces the required access decision.
Configure outbound access separately for each target. Lambda and Smithy targets use the Gateway’s execution role. OpenAPI and MCP-server targets can use an AgentCore credential provider for API keys or OAuth credentials, IAM-based SigV4 authorization, or no authorization for a public endpoint. Do not infer a target’s outbound credentials from the method used to authenticate the client to Gateway.
Keep the target permission scope narrow. If the Gateway role can invoke an unrestricted business function, the function must still check the caller’s authorized resource scope. Tool discovery and a successful network call do not establish permission to change the customer named in model-generated arguments.
Use Identity for the correct credential subject
AgentCore Identity manages workload identities and credential providers. It integrates with Runtime and Gateway so that agents can access AWS resources and third-party services without embedding long-lived credentials in prompts or application source.
For user-delegated OAuth access, AWS’s SDK example uses requires_access_token with provider_name, scopes, and auth_flow="USER_FEDERATION". The provider identifies the configured OAuth integration; scopes describe requested access. The flow obtains user consent and a token for acting on that user’s behalf. Configure the provider’s callback URL in the authorization server rather than accepting an arbitrary redirect destination.
Credential retrieval also needs execution permissions. AWS’s example explicitly grants bedrock-agentcore:GetResourceOauth2Token and the required secret access; deploying an execution role does not automatically grant token-vault access. Limit those permissions to the workload identity and provider the agent actually uses.
Do not confuse an asserted user ID with a verified identity. GetWorkloadAccessTokenForUserId treats the user ID as an opaque string. AWS identifies this as suitable for quickstart and development scenarios. For a production request carrying an end-user JWT, GetWorkloadAccessTokenForJWT validates the token’s issuer, signature, and expiry. Bind the resulting identity to the application’s authorization context before tools act.
Key distinctions and trade-offs
The following boundaries need independent configuration:
| Boundary | Concrete mechanism | What it does not prove |
|---|---|---|
| Runtime deployment | Runtime version and endpoint reference | That the agent may access every tool |
| Client to Runtime or Gateway | IAM/SigV4 or configured OAuth authentication | That the requested business action is authorized |
| Gateway to target | Execution role or credential provider | That a model-selected customer belongs to the caller |
| Agent to external service | Workload identity and scoped OAuth token | That every downstream operation is approved |
Agent identity versus user identity: A workload can act autonomously under its own permissions or use user-delegated credentials. Choose the subject required by the downstream service rather than sharing one user’s token across sessions.
Deployment versus promotion: Creating a version prepares code to run. Moving a production endpoint to that version changes what production invokes. The DEFAULT endpoint’s automatic movement matters when release approval is separate from deployment.
Architecture / decision scenario
A procurement assistant reads inventory through a Lambda tool and creates draft purchase requests in an external procurement service. The team deploys the agent to Runtime, tests a candidate version, and points a production endpoint at the approved version.
The backend authenticates employees, verifies their organization, and invokes the production endpoint with an owned session. The agent discovers the inventory tool through Gateway’s MCP target. Gateway uses its execution role to invoke the inventory Lambda; that Lambda checks the authorized organization before returning stock data.
The procurement service requires employee-delegated OAuth. Identity supplies a token through the configured provider and USER_FEDERATION flow, with the scopes needed for draft creation. Production identity binding uses the JWT path rather than trusting a submitted employee ID.
If consent is absent or a tool denies access, the assistant explains the blocked step and leaves the draft uncreated. It does not retry under a broader shared credential. The hosting version, tool route, credential subject, and business permission are all explicit parts of the same operation.
Common exam traps
- Treating Runtime deployment as configuration of Gateway and Identity.
- Assuming
DEFAULTremains pinned after a Runtime update. - Applying the HTTP port and path to every Runtime protocol.
- Confusing Gateway inbound authorization with target outbound credentials.
- Assuming every Gateway target participates in MCP aggregation.
- Treating
GetWorkloadAccessTokenForUserIdas verification of an end user. - Sharing a user-delegated token across unrelated users or tenants.
What to remember
- Runtime versions execute behind endpoints; promote the intended version deliberately.
- Gateway target categories have different routing and authentication behavior.
- Configure inbound and outbound authentication as separate boundaries.
- Identity supplies credentials for a workload or a delegated user, not business approval.
- Validate resource authorization before each consequential tool operation.
Knowledge check
Production clients invoke an AgentCore Runtime through its DEFAULT endpoint. The team wants to update the Runtime with a candidate container image and test it, but production must keep running the reviewed version until the release is approved. Which design meets that?
DEFAULT and test the candidate through a new non- DEFAULT endpointDEFAULT endpoint and repoint it with UpdateAgentRuntimeEndpoint after approvalDEFAULT , which stays on the version it pointed to before the updateDEFAULT and test the candidate in a separate Runtime sessionDEFAULT to it automatically, so production on DEFAULT would run the candidate the moment it is deployed. A non- DEFAULT endpoint changes only when UpdateAgentRuntimeEndpoint sets its agentRuntimeVersion , which keeps deployment and promotion apart.Clients authenticate to an AgentCore Gateway with OAuth JWTs. When the Gateway calls its Lambda target, the call fails with an access-denied error. Which configuration does the fix belong in?
A production backend receives each employee’s JWT, but it obtains workload access tokens by calling GetWorkloadAccessTokenForUserId with an employee ID taken from the request body. Which change makes the delegated credentials rest on a verified identity?
GetWorkloadAccessTokenForJWT with the employee’s tokenUSER_FEDERATIONGetResourceOauth2Token permissionsGetWorkloadAccessTokenForUserId treats the ID as an opaque string, so it is suited to development without an identity provider token. The JWT path validates issuer, signature, and expiry. Consent flows and narrower permissions still act for whoever the asserted ID names, and a valid ID is not proof that the caller is that employee.A Gateway tool invokes a Lambda function that creates purchase drafts. The Gateway authenticates every client with a JWT, and its execution role may invoke only this function. The model supplies the organization ID as a tool argument. What prevents an authenticated employee from creating a draft for another organization?
References
- AWS, microVMs
- AWS, Understand the AgentCore Runtime service contract
- AWS, Core concepts for Amazon Bedrock AgentCore Gateway
- AWS, Provide identity and credential management for agent applications with Amazon Bedrock AgentCore Identity
- AWS, Build your first authenticated agent
- AWS, AgentCore Runtime versioning and endpoints