Amazon Bedrock Agents turn model reasoning into action through action groups. An action group describes functions or an OpenAPI-defined API surface that the agent may choose during orchestration. Bedrock can pass the requested action to a Lambda function for fulfillment, or it can return control to the application so the application decides how to execute the action. That execution choice is central to the security and reliability design.<\/p>\n
Under the Generative AI on AWS<\/a> architecture, Bedrock Agents Tool Use is the managed-agent path for tools. It is different from client-side Converse tool use and different from AgentCore Gateway. The existing Amazon Bedrock Agents<\/a> article provides the broader orchestration context.<\/p>\n Tool use should be designed as a contract: what the model may request, how arguments are validated, who authorizes the action, and how the result is returned to the reasoning loop.<\/p>\n An action group can be defined with function details or through an OpenAPI schema. The names, descriptions, parameters, and schema influence which capability the model selects and how it constructs arguments.<\/p>\n Descriptions should be precise enough to distinguish similar tools. If two action groups both sound like \u201cget customer data,\u201d the model may route unpredictably. Parameters should constrain required fields and types instead of forcing a downstream function to recover missing business context from free text.<\/p>\n Tool schema quality is part of model quality because the model only sees the contract the application provides.<\/p>\n Bedrock can invoke a configured Lambda function after the model selects an action and gathers the required parameters. The Lambda function receives the action context, performs the business logic, and returns a result for the agent to incorporate into the next reasoning step.<\/p>\n This pattern keeps side effects out of the foundation model. IAM and Lambda resource policies determine whether Bedrock may invoke the function, while the function itself can perform application authorization, input validation, transactions, and downstream calls.<\/p>\n The planned Lambda for GenAI Backends<\/a> article covers how serverless functions fit into broader GenAI application architecture.<\/p>\n An action group can use This is useful for high-impact operations, systems that already have an application-side transaction layer, or environments where tool execution cannot be placed inside the Bedrock-owned Lambda path.<\/p>\n Return control also makes human approval easier because the application can stop before execution and present the proposed action to the user or reviewer.<\/p>\n The model choosing a tool does not prove the user is authorized to use it. Authorization should be enforced by the Lambda function or application that executes the action, using trusted identity and resource context.<\/p>\n A support agent may have an action called \u201cissue refund,\u201d but the execution layer still needs to verify the user, order, amount, policy, and any approval threshold. Prompt instructions cannot replace those checks.<\/p>\n The existing API security<\/a> article applies directly because agent actions are API requests generated through a model-mediated interface.<\/p>\n A Bedrock agent may decide to call an action again after receiving an error, but the downstream action can have side effects. If the first request succeeded and only the response was lost, another execution can duplicate the business operation.<\/p>\n High-impact tools should support idempotency keys or read-after-write recovery so the fulfillment layer can recognize a replay. Transient technical errors can be retried safely only when the operation semantics support it.<\/p>\n The agent\u2019s reasoning loop should not become an uncontrolled retry engine for payments, deployments, account changes, or other non-idempotent work.<\/p>\n A tool can return text from databases, websites, tickets, or other systems. That text can contain malicious or irrelevant instructions. The agent should treat tool output as evidence for the user task, not as a new privileged system prompt.<\/p>\n The planned Prompt Injection Defenses on AWS<\/a> article goes deeper into this threat. Tool descriptions, argument validation, output sanitization, and separation of instructions from untrusted content all contribute.<\/p>\n Guardrails can add content controls, but they do not remove the need to design the tool boundary defensively.<\/p>\n When an agent gives a wrong final answer, operators need to know whether the wrong tool was selected, the arguments were wrong, the tool failed, or the tool returned correct data that the model misinterpreted.<\/p>\n Trace data should therefore correlate the agent turn, action group, function or API name, parameters where safe, fulfillment latency, downstream status, and response. Sensitive arguments can be redacted or hashed while preserving the ability to diagnose the path.<\/p>\nAction groups define the capabilities the agent can request<\/h3>\n
Lambda fulfillment centralizes business logic outside the model<\/h3>\n
Return control is useful when the application must own the execution<\/h3>\n
RETURN_CONTROL<\/code> instead of Lambda fulfillment. In that mode, Bedrock returns the predicted action and parameters to the application through the agent response. The application can inspect, approve, modify, or execute the action and then continue the interaction.<\/p>\nAuthorization should be checked at execution time<\/h3>\n
Tool retries need to distinguish reasoning from fulfillment<\/h3>\n
Tool results should be treated as data, not trusted instructions<\/h3>\n
Observability should show the action selected and the outcome returned<\/h3>\n