Guardrail Placement: A Multi-Layered Approach

 

Most people feel, placing guardrails exclusively at the output stage. This wastes API compute money on bad queries, exposes the system to dangerous reasoning states, and adds noticeable latency

I Propose a Multi-Layered Framework:

Layer 1 (Input/Pre-processing): Implement cheap, fast checks (regex or light classifiers) for prompt injections, toxicity, and PII before spending money on the core agent execution

Layer 2 (Tool Level): Verify parameters before a tool is called, restricting dangerous commands (like blocking "DROP" SQL commands or capping row returns).

Layer 3 (Reasoning/Execution): Monitor the agent while it runs to prevent infinite loops, excessive tool calls, or runaway costs

Layer 4 (Output): Serve as the final defense to ensure no PII or system prompts leaked, accepting higher latency only as a final check.

Gliner API's can be used for Guard Rails, it detects Personally Identifiable Information in text. RegEx can also be used in the Inputlayer