Security

Security

Mingly implements multiple layers of security to protect user data and prevent abuse.

Security Layers

1. Input Sanitizer

Detects and mitigates prompt injection attacks across 8 categories:

Attack Type	Example Pattern
Role spoofing	"Act as", "You are now"
Instruction override	"Ignore previous instructions"
System prompt leak	"Repeat system prompt"
Data exfiltration	"Send data to..."
Delimiter injection	Fake system/role markers
Encoding attack	Base64/hex encoded payloads
Excessive length	>100k characters or >5000 lines
Unicode abuse	Invisible characters, homoglyphs

Risk scoring: Each detected pattern contributes a severity score (low: 5, medium: 15, high: 30, critical: 50). Scores are aggregated to produce an overall risk level.

Privacy: User content is never logged — only metadata (risk level, attack type counts).

2. Rate Limiter

Sliding-window rate limiting prevents abuse of individual handlers and the system as a whole.

Per-handler limits:

Handler	Requests/min
LLM calls	20
RAG operations	30–60
MCP tool execution	30
Integrations	3–5
File operations	30–100
Export	3–10
Global	500

The algorithm uses O(1) checks with automatic window cleanup every 5 minutes.

3. Role-Based Access Control (RBAC)

Hierarchical access control designed for team and enterprise use.

Roles (by privilege level):

Role	Level	Key Permissions
Super Admin	100	Full access, org management
Admin	80	All except org.manage
Manager	60	Team, RAG, MCP management
User	40	Chat, RAG search, analytics
Viewer	20	Read-only access
Guest	10	Chat view only

Organization hierarchy:

• Organization → Teams → Users
• Budget limits (tokens/spend per month) at each level
• SSO configuration per organization (SAML, OAuth, LDAP)

30+ granular permissions organized by category: chat, settings, RAG, MCP, integrations, admin, budget, GDPR.

4. Sensitive Data Detector

Scans outgoing messages for PII and credentials before they reach cloud LLM providers.

Detection types:

Data Type	Risk Level	Detection Method
Email addresses	Low	Pattern + TLD validation
Phone numbers	Medium	Pattern matching
IP addresses	Medium	Pattern matching
File paths	Low	OS path patterns
Social Security Numbers	Critical	Pattern matching
Credit card numbers	Critical	Pattern + Luhn algorithm
API keys	Critical	Known prefix matching
Passwords	Critical	Keyword context analysis

Recommendations: allow (low risk) → warn (medium/high) → block (critical)

Users can add custom detection patterns for domain-specific data.

5. Input Validator

Validates and bounds all inputs to prevent injection and overflow:

• Path traversal — Blocks ../, ..\\, URL-encoded variants, null bytes
• Size limits — Per-input-type maximums (RAG queries: 10k chars, MCP args: 50k chars, collection names: 128 chars)
• Type validation — Positive integers, bounded strings, alphanumeric names

API Key Security

API keys are stored in the operating system's secure credential store:

• macOS: Apple Keychain
• Windows: Windows Credential Vault

Keys are never stored in plaintext on disk, in config files, or in the database.

Network Security

• CORS headers on all server responses
• Bearer token authentication for server mode
• Session limits for WebSocket connections
• No telemetry — no usage data sent to third parties

GDPR Compliance

Built-in features for data protection regulation compliance:

Feature	GDPR Article
Data export (full user data)	Art. 20 — Data portability
Data deletion (anonymization)	Art. 17 — Right to erasure
No telemetry	Art. 5 — Data minimization
Audit logging	Art. 30 — Records of processing
Retention enforcement	Art. 5(1)(e) — Storage limitation

Audit entries are capped at 10,000 (oldest pruned automatically).

Local-Only Option

For maximum data security, use Ollama as the LLM provider. All processing stays on your machine — no data leaves your network.

---

Back to: Home | Related: Architecture | Configuration