Add llm guardrails
Skill ContextJet-ai/awesome-llm-observability/skills/add-llm-guardrails
50+ curated LLM observability tools PLUS 26 Agent Skills (several with runnable, unit-tested scripts) to build, evaluate, debug, secure & monitor reliable LLM apps. Tracing, evals, guardrails, LLMOps.
npx -y skills add ContextJet-ai/awesome-llm-observability --skill add-llm-guardrailsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
What its author says it does
Copied from the file, not written here
Use this to add safety and security guardrails to an LLM/agent app - blocking prompt injection, PII leakage, jailbreaks, toxic output, off-topic responses, or invalid structured output. Trigger on "add guardrails", "prevent prompt injection", "stop PII leaks", "validate the model's output", "make this safe for production", especially for regulated/finance/enterprise use.
The file declares its own license as CC0-1.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
3.1 KB, as published. Nobody here has run it
Add guardrails to an LLM app
Guardrails are validation layers on the input (before the model) and output (before the user/downstream). They're mandatory for regulated and enterprise deployments. Treat them as tested code, and observe them (a guardrail that fires silently is useless).
Two layers, distinct jobs
Input guardrails (run before the LLM):
- Prompt-injection / jailbreak detection - reject or sanitize inputs trying to override instructions.
- PII detection - flag/redact sensitive data before it reaches a third-party model (see the
redact-pii-for-tracingskill for the tracing side). - Topic / policy - reject off-scope requests.
Output guardrails (run before returning):
- Structured-output validation - enforce the schema (JSON/enum/type); repair or reject on failure.
- Toxicity / safety - block harmful content.
- Groundedness / hallucination - check the answer is supported by the retrieved context (for RAG).
- Sensitive-data egress - ensure the response isn't leaking secrets/PII.
Implementation shape
- Pick a library - Guardrails AI (validators + structured output), LLM Guard (PII, injection, toxicity), or NeMo Guardrails (programmable rails). Don't hand-roll regexes for security.
- Wrap input → validate/sanitize → call model → wrap output → validate → return or repair.
- Decide the failure mode per guardrail: block (hard fail), redact (transform), or flag-and-log (soft). Regulated flows usually block; UX flows often redact.
- Fail closed for security-critical checks - if the guardrail errors, treat as a failure, not a pass.
Observe your guardrails (critical)
Emit a span/event every time a guardrail fires (which one, input hash, action taken). Without this you can't tell if injection attempts are rising, if PII redaction is over/under-triggering, or if a guardrail silently broke. Dashboard: guardrail-trigger rate over time + false-positive spot-checks.
Verify
- Red-team it: feed known injection strings, PII samples, and malformed-output cases; confirm each is caught.
- Confirm guardrail firings show up in traces.
- Confirm the failure mode is right (block vs redact) for each check.
Anti-patterns
- Output validation only, no input guardrails (injection walks right in).
- Guardrails that fail open on error (a crashing PII check that lets data through).
- Silent guardrails with no telemetry - you're blind to attacks and to your own false-positive rate.
- Regex-only "security" - brittle against adversarial inputs.