Start with the hook that fires first. `BeforeInvocationEvent` runs before model inference or tool execution, inspects the incoming messages, and blocks the request when the content violates policy, and AWS notes the model never sees blocked content [6]. Its stated scope is user input, data from other agents, MCP tool servers, and RAG pipelines [6]. The third checkpoint sits on the way out, validating results before they reach the user or move to a downstream component [8].
Enabling this fleet-wide means tallying the evaluations first. A model invocation already costs two guardrail passes, one on the prompt before inference and one on the response after [2]. Add all three checkpoints to a turn that calls a single tool and you are at five [14]. Measure the per-check latency on your own traffic first, because the placement of a check tells you nothing about its price.
The model boundary ships with a trust dial. Input tagging marks which portions of the prompt get evaluated, so a system prompt you control can be skipped [4]. At the tool boundary, you are the dial. Nothing in a hook knows that a read-only search tool and a funds-transfer tool deserve different policies until you scope them per tool, and that scoping is the actual work here [10]. Without that scoping, a guardrail that blocks nothing still adds latency and produces a compliance record, nothing more.
Then read what the checks are looking for. The harms AWS names are content harms: its worked example is an agent that retrieves inaccurate or misleading external content, treats it as authoritative, and produces skewed recommendations in lending, healthcare, or legal advice [11]. The tool-parameter gap is described the same way, in terms of PII and policy-violating content reaching the tool unchecked [5]. A classifier tuned for that will not tell you a file path resolves one directory too high, or that an account ID belongs to a different customer. Those are schema and authorization checks, and they still live inside the tool.
AWS's framing of this design is worth a closer look. Each checkpoint is presented as validating data at a trust boundary without changing your existing tools or agent logic [12]. At the level of source files, that is true. The runtime still acquires a new failure path that your test suite probably does not cover yet.
The design is sound where the exposure is genuinely data crossing a boundary you do not own. Agents consume tool responses, MCP server output, and API calls, and AWS's point is that this content can influence agent behaviour before any model-level guardrail gets a look [13]. MCP is a standard for connecting AI systems to data sources and tools, which means the content arriving over it is written by whoever runs the server [15]. That is the case for a hook. If your tools take tightly structured arguments and your real risk is who is allowed to call them, the hooks are still useful plumbing, but the guardrail behind them is checking the wrong thing.
