AI 代理安全
AWS Uses Three-Stage Strands Hooks to Inspect Agent Tool Flows, but They Cannot Replace Access Controls
AWS proposes invoking Bedrock Guardrails separately on model input, tool parameters, and tool output, closing gaps left when only prompts and responses are inspected. The example supports tool-specific rules but provides no latency, false-positive rate, or security evaluation for structured actions.
On August 27, AWS published an implementation for protecting agents that extends [Amazon Bedrock Guardrails](https://aws.amazon.com/blogs/security/extend-amazon-bedrock-guardrails-to-tool-interactions-using-the-strands-agents-sdk/) from the model invocation boundary into the Strands tool lifecycle. The problem is that even when model-layer guardrails inspect prompts and responses, they may not see parameters about to be sent to a database, MCP server, or external API. They may also fail to intercept untrusted tool results before those results enter subsequent reasoning.
The example creates a `HookProvider` and registers three checkpoints: `BeforeInvocationEvent` reviews user or upstream-agent input before model inference; `BeforeToolCallEvent` checks the tool name and serialized parameters before the actual operation and cancels the call if it violates policy; and `AfterToolCallEvent` reviews external data, replacing the result with a blocking message when necessary. All three use Boto3’s `ApplyGuardrail` API, while `tool_names` can apply different policies to email, search, or payment tools. Because this approach does not require modifying individual tools, it can be packaged as a shared internal library.
More important technically is the separation of responsibilities across protection layers. The [Strands documentation](https://strandsagents.com/docs/user-guide/concepts/agents/hooks/) shows that hooks can cancel or rewrite tool calls. AWS also recommends applying schemas, regular expressions, and allowlists first to parameters of frequently used tools, then passing semantic content to machine-learning-based guardrails to limit additional latency.
However, this is a reference architecture, not a validated new security boundary. The article reports no attack success rate, false-blocking rate, or cost or latency per `ApplyGuardrail` call. Nor does it address dangerous SQL wrapped in legitimate-looking text, path traversal, or cumulative risks across multiple steps. Engineering teams must still protect operations with side effects through IAM least privilege, deterministic parameter validation, human approval, and audit logs, and must test whether the system fails open or fails closed when the guardrail service is unavailable.