Hover a node · click to focus · ←/→ steps
Versioned rails in Git. Input → dialog → output checks; high-severity detections fail closed before the provider.
When you need this
- RAG corpus includes user-uploaded or third-party docs
- Agents execute tools based on model output
- Security questionnaire asks about injection controls
- Incidents of ‘ignore previous instructions’ in prod
Prerequisites
- Threat model for retrieval + tools
- Gateway hook for scanners
- Separation between system instructions and untrusted content
Tools
Assess vs OSS rails when you need managed updates for attack patterns.
Trial on customer-facing bots; keep rails versioned in Git with eval coverage.
Run at inference boundary, not only in batch pipelines.
Deploy as single ingress before adding a second LLM vendor.
Steps
- 1
Isolate untrusted content
Clear delimiters / structured messages. Never concatenate retrieved docs into the system prompt. Treat tool results as untrusted.
- 2
Scan inputs and retrieved chunks
Lakera or equivalent on user input and top-k chunks. Block or quarantine on high-risk detections.
- 3
Constrain tools
Allowlists, argument schemas, and human approval for writes. Agents must not gain new tools at runtime in prod.
- 4
Output rails and PII
Guardrails + Presidio on outputs. Refuse to emit secrets or exfiltrate system prompts.
- 5
Red-team continuously
Corpus of injection payloads in CI. Quarterly live red-team on the highest-risk app.
Adoption pitfalls
- Scanner only on user chat, not retrieved docs
- Model-only ‘you are secure’ instructions
- Tool APIs overly broad (shell, unrestricted SQL)
Adoption checklist
- Untrusted content never in system prompt
- Scanner on user + retrieval path
- Write tools require approval
- CI injection corpus blocking merges
SEER REAL assessment / sprint
Assessment red-teams one RAG/agent path. Sprint adds scanner + content isolation + tool constraints for that path.