Skip to main content

Security Overview

Hitler implements multiple layers of security to protect against common attack vectors, with special emphasis on prompt injection protection for our AI-powered features.
Security is an ongoing process. While we implement industry best practices, always monitor logs for suspicious activity and keep dependencies updated.

Prompt Injection Protection

Since Hitler uses LLMs (Large Language Models) for natural language processing, we implement comprehensive protection against prompt injection attacks.

What is Prompt Injection?

Prompt injection occurs when malicious users attempt to manipulate an AI system by embedding instructions in their input that override the system’s intended behavior. Example Attack:
Without protection, an AI might comply with this request, potentially exposing sensitive information or performing unintended actions.

Our Defense Layers

Hitler implements a defense-in-depth strategy with multiple protection layers:

Input Sanitization

Dangerous patterns are detected and neutralized before reaching the LLM

Output Validation

LLM responses are validated before being shown to users

Canary Tokens

Secret markers detect if system prompts are being leaked

Threat Assessment

Risk scoring determines appropriate response actions

Threat Detection

Detected Attack Types

Our security module detects 40+ attack patterns across these categories:

Example Patterns Detected

Security Functions

Input Sanitization

What gets sanitized:
  • XML/HTML tags are escaped (<)
  • Markdown images are removed
  • Invisible unicode characters are stripped
  • Encoded payloads are blocked

Threat Assessment

Risk Scoring:
  • 0-20: Safe - Normal message
  • 21-50: Low/Medium - Some suspicious patterns
  • 51-70: High - Multiple threats detected
  • 71-100: Critical - Attack patterns identified

Output Validation

What gets checked:
  • Canary token leakage
  • System prompt echoing
  • Markdown image exfiltration attempts
  • Suspicious external URLs

Canary Token System

Canary tokens are secret markers embedded in system prompts. If they appear in output, it indicates the LLM is leaking its instructions.

Chat Service Integration

The chat service automatically applies all security measures:

System Prompt Hardening

Our system prompts include explicit injection resistance instructions:

Security Audit Logging

Security events are persisted to the database via the SecurityAuditService for long-term analysis and compliance:

Database Schema

Using the Security Audit Service

Log Structure Example

Security Monitoring

Hitler includes a real-time security monitoring system that aggregates events and triggers alerts based on configurable thresholds.

Setting Up Monitoring

Recording Events

Alert Types

Metrics Snapshot

Best Practices

For Developers

1

Always use sanitized input

Never pass raw user input directly to the LLM
2

Validate all outputs

Check LLM responses before displaying to users
3

Monitor security logs

Set up alerts for high/critical threat events
4

Keep patterns updated

Regularly update injection pattern database

For Administrators

1

Review security logs regularly

Check for patterns of attack attempts
2

Monitor blocked messages

High block rates may indicate targeted attacks
3

Report new attack patterns

Help improve detection by reporting bypasses

Additional Security Measures

Authentication & Authorization

  • JWT tokens for web users with short expiry
  • API keys for bot services with organization scope
  • Role-based access control (Employee, Manager, Admin)

Auth Guards

Three guard types are available for protecting API endpoints: Most controllers use AuthOrApiKeyGuard so both the web dashboard (JWT) and bot adapters (API key) can access the same endpoints.

Temporary Password System

Admins can create users with temporary passwords via the dashboard. The mustChangePassword boolean on the users table forces a password change on first login:
  1. Admin creates user with a temporary password
  2. mustChangePassword is set to true
  3. User logs in and is prompted to set a new password
  4. After changing, mustChangePassword is set to false

Data Protection

  • Organization isolation - Data never crosses org boundaries
  • Encrypted secrets - Platform tokens stored in Cloudflare KV with AES-256-GCM
  • No secrets in database - Sensitive data stored separately

Rate Limiting

Hitler implements two types of rate limiting:

User-Based Rate Limiting

For authenticated endpoints, rate limits are applied per-user:

IP-Based Rate Limiting

For public endpoints (login, webhooks), rate limits are applied per-IP with progressive penalties:
IP Rate Limit Presets: Progressive Penalties:
  1. First violation: Warning logged
  2. Second violation: Longer cooldown
  3. Third violation: Temporary IP ban
Rate limit events are logged to the database for analysis:

Input Validation

  • Zod schemas validate all API inputs
  • Maximum message length enforced (2000 chars)
  • Content-type validation on all requests

Reporting Security Issues

If you discover a security vulnerability, please report it responsibly:
  1. Email: security@hitler.app
  2. Do not disclose publicly until fixed
  3. Include reproduction steps if possible
  4. We aim to respond within 48 hours
We take security seriously. Valid reports may be eligible for recognition in our security acknowledgments.