AWS bedrock-agentcore high security documentation change
Summary
Clarified allowedTools scope, added security note about InvokeAgentRuntimeCommand, and improved inline function tool implementation
Security assessment
Explicitly warns about InvokeAgentRuntimeCommand bypassing tool restrictions and requires IAM controls. Implements session corruption prevention by requiring atomic toolUse+toolResult submission. Both changes address security risks.
Diff
diff --git a/bedrock-agentcore/latest/devguide/harness-tools.md b/bedrock-agentcore/latest/devguide/harness-tools.md index 3cf1257d5..0798f09b3 100644 --- a//bedrock-agentcore/latest/devguide/harness-tools.md +++ b//bedrock-agentcore/latest/devguide/harness-tools.md @@ -28 +28,3 @@ Default tools `shell` and `file_operations` are available in every session unles -The `allowedTools` parameter controls which tools the agent can use. If omitted, all tools are allowed. Supported patterns: +The `allowedTools` parameter controls which tools the agent can use. If omitted, all tools are allowed. + +Supported patterns: @@ -41,0 +44,4 @@ Builtin glob | `"file_*"` | `file_operations`, `file_read` +###### Note + +`allowedTools` scopes LLM tool selection during `InvokeHarness` only. It does not affect [InvokeAgentRuntimeCommand](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-execute-command.html), which is a separate API with its own IAM action (`bedrock-agentcore:InvokeAgentRuntimeCommand`) that executes commands directly without passing through the LLM. To prevent direct command execution, do not grant `bedrock-agentcore:InvokeAgentRuntimeCommand` in your IAM policies. + @@ -116 +122 @@ Pass `tools` at create, update, or invoke time: - # Use ${arn:...} to reference a credential provider — the ARN is resolved + # Use ${arn:...} to reference a credential provider - the ARN is resolved @@ -240 +246 @@ Pass an inline function tool at invoke time: - # 2. The agent calls the tool - capture the toolUseId from the stream + # 2. The agent calls the tool - capture the toolUseId and input from the stream @@ -241,0 +248,2 @@ Pass an inline function tool at invoke time: + tool_name = None + tool_input = None @@ -245 +253 @@ Pass an inline function tool at invoke time: - if "toolUse" in start and start["toolUse"].get("type") == "inline_function": + if "toolUse" in start and start["toolUse"].get("name") == "get_weather": @@ -246,0 +255,5 @@ Pass an inline function tool at invoke time: + tool_name = start["toolUse"]["name"] + if "contentBlockDelta" in event: + delta = event["contentBlockDelta"].get("delta", {}) + if "toolUse" in delta: + tool_input = (tool_input or "") + delta["toolUse"].get("input", "") @@ -248,0 +262 @@ Pass an inline function tool at invoke time: + # Include the assistant's toolUse message followed by your toolResult @@ -252 +266,6 @@ Pass an inline function tool at invoke time: - messages=[{ + messages=[ + { + "role": "assistant", + "content": [{"toolUse": {"toolUseId": tool_use_id, "name": tool_name, "input": json.loads(tool_input)}}], + }, + { @@ -261 +280,2 @@ Pass an inline function tool at invoke time: - }], + }, + ], @@ -263,0 +284,4 @@ Pass an inline function tool at invoke time: +###### Note + +You must include both the assistant `toolUse` message and your `toolResult` in step 3. The harness intentionally does not persist the inline function turn to the session - if the client never returns a result, persisting a partial turn (assistant `toolUse` without a matching `toolResult`) would leave the session in a corrupted state. By requiring the client to send both messages, the session remains clean regardless of whether the client completes the tool call. +