Agent-security conversations stall on a question that sounds simple: where does the guardrail go? "We have guardrails" tells you nothing until you can say which boundary they sit on — what they see, what they block, and what passes through them untouched.
The OWASP ACS v0.1 hook model gives that question a vocabulary: input, tool_call, tool_result, memory, subagent. Five places an enforcement point can sit in an agent stack. As of catalog v1.3.0, every one of our 124 probes declares the surface a guardrail must cover to block it — 85 probes land on the input boundary, 29 on tool_call, 10 on tool_result, 7 on memory, 4 on subagent.
Declaring it is step one. The interesting question is what the data says about each surface.
What 227 findings say
We mapped every categorized finding from our dogfooding dataset — 227 of the 243 — through the same category-to-surface table the catalog uses:
| Hook surface | Findings | Share |
|---|---|---|
| input | 179 | 79% |
| tool_call | 41 | 18% |
| tool_result | 3 | 1.3% |
| memory | 3 | 1.3% |
| subagent | 1 | 0.4% |
Two honest caveats before anyone quotes those numbers: our catalog is input-heavy by design (injection and policy testing is where most of the probe library lives), so the finding distribution partly reflects coverage, not the universe of risk. And this is internal dogfooding data, not customer deployments.
With that said, three patterns are worth an implementer's attention.
Pattern 1 — the input boundary is where volume lives
79% of findings trace to the input surface: injections, jailbreaks, policy violations, instruction-hierarchy overrides, prompt leakage. If you are standing up your first enforcement point, this is the one with the most demonstrated failures against it — and the failure shape is consistent. Refusals hold against known templates and collapse against reframing: a fabricated authority claim converted instruction-hierarchy refusals into compliance nine times in our dataset, six of them critical.
The operational takeaway is not "filter inputs harder." It is that input-boundary enforcement is semantic — it has to survive paraphrase, multi-turn escalation, and encoding, which is exactly why we run adaptive multi-turn probes rather than a static payload list.
Pattern 2 — the crossings are where incidents live
Multi-counting tells a different story than primary-surface counting. Several categories touch two surfaces — unauthorized exfiltration spans tool_call and tool_result; supply-chain and RAG poisoning span tool_result and memory; secret disclosure spans input and tool_result. Counted that way, the data-flow boundaries (tool_result, memory) touch 19 and 5 findings respectively rather than 3 and 3.
That gap is the point. A guardrail can be perfect at the input boundary and still leak, because the leak happens downstream: data enters through a tool result, gets written to memory, and exits through a later tool call. Findings that cross boundaries are the ones that turn into incident reports — and they are invisible to any single-hook deployment.
Concretely from our data: MCP-reported issues (9 findings) sit entirely on tool boundaries — the servers themselves surfaced how agents consumed their tools and resources incorrectly. Multi-agent attack paths, while small in our dataset (agents were mostly single-agent), form a distinct surface that input filtering cannot reach at all: the injection arrives via another agent, already inside the trust boundary.
Pattern 3 — coverage gaps are structural, not accidental
Memory and subagent are thin in our dataset for a structural reason: the agents we tested were mostly stateless request/response deployments. Deployments with persistent memory or subagent delegation move risk onto surfaces our default suites exercise lightly. If your architecture has those components, ask for coverage on those hooks explicitly — the surfaces you don't test are the ones your attacker gets for free.
From surfaces to verdicts
Naming the surfaces is useful for planning. Verifying them is the harder part — and "we have guardrails on all five surfaces" is a claim, not evidence.
That is what the Guardrail Verification profile we shipped this week does: you assert claims ("prompt injections are refused", "credentials are neither harvested nor exfiltrated", "destructive operations are gated"), and the platform runs the probe set mapped to those claims — 10 claims, 39 probes in v1 — then reports a per-claim verdict: blocked, partially blocked, or bypassed, with evidence links to every failing probe. The claims map to hook surfaces the same way the catalog does, so the report tells you which boundary failed, not just that something did. (A failed or incomplete run reads not_verified — a scan that didn't finish must never masquerade as a passing attestation.)
The evidence packages that back those verdicts now also carry an AgBOM — a CycloneDX 1.5 bill of materials for the agent's environment: its model, its MCP server connections with trust tiers, the tools those servers expose, and the dependency graph between them. The guardrail verdict and the inventory of what it guards ship together.
The catalog is public
Everything this post is built on is public and versioned: catalog v1.3.0 with per-probe ACS surfaces, the claim taxonomy, and the Q3 benchmark data — including the failure-rate and caveat sections. If you're implementing ACS hooks, early access gets you the verification profile and the CLI.