The problem
Ask an engineering team where its AI guardrails live and the answer is almost always the same: in front of the model. A classifier reads the incoming prompt, scores it, and the request passes or fails. Some teams add a second pass on the output side. Framed that way, the work sounds finished: a prompt filter and a response filter, both tuned and monitored.
The ceiling on that design has nothing to do with how well either filter is tuned. A prompt-layer detector reads the assembled payload: system prompt, retrieved context, history, and user input, concatenated into one block of text. If an attack arrives inside a retrieved document rather than the user’s own message, the detector reads it all but cannot tell where any part came from unless assembly preserved that, and most don’t. No classifier, however well trained, answers a question it was never given the information to answer.
That is not a training problem. It is a placement problem. Before you choose a detector, you choose where it sits, which fixes, in advance, the best accuracy that detector can ever reach. A detector stationed where it cannot see a document carrying an injection will not detect it, no matter how good the model behind it becomes. The document was never in its input. You cannot classify evidence you were never handed.
ARCH-001 shows why this happens systematically. Strip any enterprise AI system to the path one request takes and six stages appear: a document is uploaded, context is retrieved, a payload is assembled, the model produces tokens, a tool call may fire, and the exchange is logged. A chokepoint is a stage where the request is fully materialized and execution can pause. Each of the six has a different view of the truth, and placement decides which view a control gets, before anyone chooses what runs there.
Forces
Observability rises as the request moves downstream, and the ability to prevent falls at nearly the same rate. Retrieval sees the selected chunks and the requester’s identity, nothing about what the model will do with them. The prompt chokepoint sees the entire assembled payload, but by the time a response exists the action has often already been requested, and the system cannot undo it. Logging sees the most, the whole exchange after the fact, yet prevents nothing. Tool execution breaks the trend: a narrower slice than logging, the function, arguments, target, and identity behind the call, yet full power to stop the action before it happens.
The chokepoint that sees the most also carries the tightest latency budget, and the one with room to spare sees the least. Upload sees a whole document, unhurried, off the request path with nobody waiting: the right home for anything expensive, full-document classification, entity extraction, a slow model. Prompt and response detection sit on the path a user feels. In one illustrative budget for a synchronous assistant turn, a 2,500ms p95 turn spends 250ms on retrieval and 1,700ms on inference, leaving 550ms, 22 percent, for every detector combined: 120ms for prompt-layer detectors in parallel, 180ms for response-layer detectors, 40ms for a tool-call policy decision, and a 210ms reserve for when something is slow. The stage with the most room to look knows the least about who will use what it approved.
Blocking early is cheap and structurally blind. A retrieval-layer entitlement check runs before the model ever sees a payload, deterministic rather than statistical, eliminating a whole class of disclosure before it happens: the single highest-value item on ARCH-001’s own defensible-default list, an authorization decision, not a detector. What retrieval cannot see is what the model will do with the content, since that hasn’t happened yet. Every early chokepoint trades the same way: cheap to check, blind to what comes after.
The pattern
State the rule plainly: a chokepoint’s accuracy ceiling is fixed by what it can observe, not by the model behind it, and no detector can classify evidence it never receives. Choose the chokepoint first, asking which harm you are defending against and where the evidence lives, then choose a detector for it, never the reverse.
Split the harms into two families, because the chokepoints that address them differ. Information harm is data reaching someone who should not have it: leaked PII, a disclosed system prompt, a retrieved document outside the requester’s entitlement. It is addressable at upload, retrieval, response, and logging, since a log is itself a leak surface, not a place to undo an earlier disclosure. Action harm is the system doing something in the world that should not have happened: a row deleted, a payment issued, a pull request merged. Tool execution is the last agent-side chokepoint that can prevent it: the point where the intended action, its arguments, and the delegated identity behind the call finally coexist, before the agent’s own control decides whether it fires. That claim is scoped to the agent’s own path, not the enterprise’s full stack: an API gateway, a service’s authorization check, database permissions, cloud IAM, and resource policy can all still refuse the call downstream, and Authority at the Call Site argues the check belongs at whichever layer genuinely cannot be bypassed, not always here. Tool execution belongs to both families at once: a tool call is also an egress path, an email send, a webhook. Willison’s lethal trifecta names the same shape, private data, untrusted content, and a way to communicate externally; treating tool execution as purely an action control leaves that route uninstrumented.
Mapping a real risk list onto the six chokepoints makes the claim checkable line by line. Prompt injection’s best chokepoint is retrieval, then prompt, since injected text usually arrives inside retrieved content, which the prompt layer sees but cannot attribute. Excessive agency’s best chokepoint is tool execution alone, since nothing in the text tells you whether this actor may perform this act. Three risks on the OWASP list, among them supply chain and weight poisoning, have no runtime chokepoint at all, and this six-stage control plane does not cover them; calling it complete coverage oversells it.
None of this is a new mechanism: Subramaniam and Fowler’s Guardrails pattern already names the runtime check at a stage like this, but not which stage, or why that choice bounds what the check can detect. Proposed status here means that specific placement argument did not turn up, named, in the prior art surveyed: not that nobody noticed a detector needs the right input, only that no source stated it as a design rule before a classifier is chosen.
Worked example
Take a coding assistant that reads a repository, proposes changes, and runs a few tools. The obvious guardrail instinct is a prompt-layer check: read the model’s intent and judge whether it looks dangerous. Placement rules that out first: a prompt-layer detector reads text, not the function, arguments, target, or identity the call will run under, since none of that exists yet. Whatever that detector’s ceiling, it isn’t defending what matters: which action is about to happen, and to what.
Put the control at tool execution instead, and a different pipeline is possible: the evidence is now present. The scenario and numbers below are ARCH-008’s own, reused rather than invented. Budget, a constructed target rather than a measurement: 120ms p95 for the policy decision, generous since most is deterministic work, not inference. On every call: a tool registry lookup, 5ms; an authority check against actor, action, and resource, 20ms; an argument scan for secrets and paths outside the workspace, 15ms. An LLM judge against the written policy, 400ms, reserved for calls where reversal cost is impossible and the cheap tiers leave it ambiguous.
Read that pipeline bottom up: the expensive, model-based part is the smallest part of the design, seeing only calls that are irreversible and ambiguous, a small share of traffic on an assistant whose calls are mostly reads. The load is carried by a registry lookup and a deterministic authority check, both authorization questions rather than classification ones, answerable because tool execution is the one chokepoint where the function, the arguments, and the identity are all present at once. ARCH-001 reaches the same conclusion from the retrieval side. Neither blueprint is independent evidence alone, but the same shape appearing twice is more convincing than one assertion.
When not to use it
This pattern is a placement decision, needing somewhere to place a control: a request that starts, moves through stages, finishes. A scheduled batch job, a streaming ingestion pipeline, or a background agent with no per-request boundary never produces that path, so there’s no chokepoint to choose, only a credential to scope once, at design time, for whatever service account does the work.
A single-turn, read-only tool with no write capability and no untrusted retrieval has a blast radius already capped. Mapping all six chokepoints for a tool that only populates two is analysis spent on a system too small to need it. A prototype not yet touching production data can make that call deliberately, but not past the point where retrieval draws from a shared corpus, or a tool can write.
Getting placement right can feel like finishing the job; that is the trap worth naming here. A chokepoint with the right evidence still needs a detector worth building: an authority check running a stale policy version, or a classifier trained on the wrong distribution, fails just as badly from the correctly chosen chokepoint as from the wrong one. This pattern buys the input a detector needs. It does not buy the detector.
Related patterns
Verdict Composition picks up once a chokepoint has more than one detector: placement decides the stage, that pattern decides how the outputs combine without treating incomparable scores as comparable. Tiered Detection decides, within a chokepoint, which calls get the expensive check and which get the cheap one, the same shape as the coding assistant’s judge seeing only the ambiguous band. Authority at the Call Site is the enforcement mechanism once placement puts a control at tool execution, the last agent-side chokepoint that can stop an action. Fail Closed, Degrade on Exposure governs what a chokepoint does when its detector times out, differently for each of the six, since upload can fail open where tool execution cannot. Split the Log owns the sixth chokepoint itself, what gets written down about the other five and how long it survives. Placement tells you where to put a control; these are what to do once it’s there.