#Two problems with a flat pipeline
Most content safety is a pipeline. Text enters, passes an injection filter, a personal data scanner, a toxicity classifier and a policy check, and a decision leaves. Every stage runs on every input.
Latency floor. The slowest detector sets the cost of every request, including the large majority nothing was going to block. A grounding check that calls a model at four hundred milliseconds is four hundred milliseconds on every trivial query.
Lost attribution. When everything runs and votes, the decision is a scalar. A high-precision injection detection and a low-confidence toxicity score become one number, and nothing downstream can say which detector was responsible. That makes per-detector tuning impossible, since moving one threshold moves the composite for every other input.
#The ordering
Six layers, sorted by cost and precision, each able to end evaluation.
- Boundary, under 5ms. Deny lists over topics, actions and data. A lookup.
- Instinct, under 10ms. Injection, jailbreak and exfiltration patterns.
- Reflex, under 10ms. Operator-authored condition and action rules.
- Awareness, under 50ms. Personal data, topic, sentiment and intent. Mostly annotating.
- Values, under 100ms. Toxicity, brand safety, honesty constraints.
- Judgment, under 500ms. Grounding, relevance and compliance scoring.
The saving is real and it is not the justification. A layer may terminate only if its precision is high enough that later evidence could not change the decision. A cheap detector with poor precision must not short circuit however fast it is.
#Explanation is the output that matters
A short-circuiting chain produces a decision with one named cause: layer, detector, confidence. That goes in an audit record, can be shown to a customer, and becomes a regression test.
Compare "blocked, composite risk 0.71". Nobody can act on that, nobody can say which detector to tune, and every attempt to tune it moves every other input.
People do not run a full risk assessment before flinching, and the flinch is allowed to be the whole answer. What matters afterwards is being able to say which flinch it was.
#Why input filtering is not sufficient
Direct prompt injection is the obvious attack and it is the easier one . The harder case is indirect injection, where hostile instructions arrive inside content the system retrieves rather than from the user . A document in your own corpus can carry an instruction, and no amount of scanning the user's message will catch it.
That is why retrieved content passes through the same layers as user input, and why the system's own output is scanned before it leaves. The OWASP list for these applications treats injection and insecure output handling as separate items for good reason .
#Profiles
Safety is not universal. A bank's customer assistant and an internal engineering tool need materially different boundaries, and expressing that as flags on a shared pipeline produces a configuration surface with no coherent semantics. Composing the six primitives into a named profile keeps the configuration reviewable as a unit, which is economy of mechanism applied to policy .
#The blind spot
An input terminated at an early layer is never examined by later ones, so its personal data content and grounding are unknown. Correct for blocking, and a systematic censoring of any statistic computed over blocked inputs. Shadow evaluation of a random sample through the full chain restores an unbiased estimate at sample cost, and it does not restore per-request attribution.
References
- [1]Open Worldwide Application Security Project, “OWASP Top 10 for Large Language Model Applications”, OWASP, 2023https://owasp.org/www-project-top-10-for-large-language-model-applications/ ↗
- [2]Kai Greshake et al., “Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection”, ACM Workshop on Artificial Intelligence and Security (AISec), 2023doi:10.1145/3605764.3623985 ↗
- [3]Fábio Perez, Ian Ribeiro, “Ignore Previous Prompt: Attack Techniques For Language Models”, NeurIPS Workshop on ML Safety, 2022
- [4]National Institute of Standards and Technology, “Artificial Intelligence Risk Management Framework (AI RMF 1.0)”, NIST AI 100-1, 2023doi:10.6028/NIST.AI.100-1 ↗
- [5]Jerome H. Saltzer, Michael D. Schroeder, “The Protection of Information in Computer Systems”, Proceedings of the IEEE, vol. 63, no. 9, pp. 1278-1308, 1975doi:10.1109/PROC.1975.9939 ↗