Practical LLM Security: Takeaways From a Year in the Trenches

LLMs cannot manage permissions or security boundaries - treat them as application inputs that require proper security controls

Fine-grained access control on training data is generally not possible - if the LLM sees sensitive data, assume an attacker can eventually extract it

RAG (Retrieval Augmented Generation) systems are particularly vulnerable to data leakage through:

• Improper document access controls
• Malicious document poisoning
• Prompt injection attacks
• Logging of sensitive conversations

Plugins/extensions represent the highest security risk:

• Can enable RCE, SSRF and other traditional web vulnerabilities
• Need strict parameter validation and sandboxing
• URLs and endpoints should be hardcoded, not LLM-generated

Guardrails are not reliable security controls:

• Better suited for content moderation
• Can be bypassed through various prompt injection techniques
• Should be used as supplementary controls only

Key mitigation strategies:

• Isolate LLMs from sensitive data whenever possible
• Implement strict access controls on RAG data stores
• Minimize logging of prompts and responses
• Properly sandbox plugin execution
• Educate users about security limitations

Treat all LLM integrations as internet-facing from a security perspective

Focus on data flow analysis - track where sensitive information enters and exits the system

Remember traditional application security principles still apply alongside LLM-specific controls