What Runelm defends — and what it does not.
Only the HIGH path provides full data isolation. The MEDIUM path is probabilistic risk reduction under contract. Be honest with stakeholders. Be specific about which tier provides which guarantee.
Defends against
- ᛜ
Provider-side retention exposure
Classification routes sensitive content to L1 or contractually-protected L2. HIGH never reaches an external provider. MEDIUM reaches only providers with DPA + zero-retention API tier.
- ᛜ
Provider breach
HIGH content was never sent; MEDIUM content was pseudonymized before sending. A compromised provider log contains rune-substituted text only.
- ᛜ
Legal compulsion against the provider
If HIGH, no prompt to produce. If MEDIUM, prompts contain only pseudonyms; the substitution map is held by the customer.
- ᛜ
Silent provider policy change
Every L2 provider entry requires a current dpa_on_file. An expired DPA blocks MEDIUM routing automatically.
- ᛜ
Model memorization on shared infra
HIGH never reaches a model that could memorize it externally. MEDIUM is pseudonymized — leaked fragments contain ORG_4, not the real name.
- ᛜ
Routing mistakes / operator cost-cuts
Routing enforcement is unconditional. There is no --allow-l3-for-high flag. The system enforces, it does not ask.
- ᛜ
Prompt-injection via placeholder synthesis
Map-bounded rehydration. Only reverse placeholders the outbound sanitizer placed for this session. Synthesized ones stay masked.
- ᛜ
Confirmation-oracle attacks on the audit log
Prompt hashes are HMAC-SHA-256 with a server-side secret. Without the secret, no guess can be confirmed.
- ᛜ
Audit-log tampering
Entries shipped to a tamper-evident store: S3 Object Lock, Loki with retention, hash-chained file. Local DB rows are advisory.
- ᛜ
Insider abuse of the audit log
Every query to the audit log is itself logged. A second-tier auditor reviews access patterns.
Does not defend against
Communicate these clearly. Each one is a real threat — addressed by a different layer of your stack, not by Runelm.
- ᚲ
Semantic inference
An LLM can deduce "Fortune 500 financial services firm" from context without explicit names. The MEDIUM path mitigates but does not eliminate this.
- ᚲ
Compromised host
Runelm security is bounded by the security of the host it runs on. If root is taken, Runelm is moot. Standard host hardening required.
- ᚲ
Compromised local inference
The HIGH-tier local path protects against external providers, not against an attacker who has gained access to local inference infrastructure.
- ᚲ
The LLM's response itself
A model that emits a real client name from training data bypasses outbound classification. Output filtering is a separate layer (and an open research problem).
- ᚲ
Side-channel mapping of the classifier
A patient attacker probing the decision boundary across many sessions. Rate limiting plus per-caller anomaly detection mitigates; perfect defense is open.
- ᚲ
Post-quantum cryptography
AES-256-GCM is post-quantum-acceptable per current NIST guidance. Plan for crypto-agility from day one — the cipher and hash are config-driven.
- ᚲ
Supply-chain compromise
Pinned dependencies, hash-checked installs, SBOM generation. Standard supply-chain hygiene applies, not Runelm-specific.
How to describe Runelm to your auditors
“Sensitive data is classified before it reaches any external LLM. Content marked HIGH is processed only by inference running inside our own infrastructure — it never leaves our network. Content marked MEDIUM is pseudonymized: identifying entities are replaced with stable placeholders before the prompt is sent to a contractually-protected provider, and the provider’s response is rehydrated locally before being shown back to the user. The substitution maps are encrypted at rest and tied to specific sessions; they are physically destroyed when the engagement ends. Every classification, routing, and substitution decision is logged with a tamper-evident, cryptographically signed audit trail — without storing the prompt text itself.”
Compliance mapping
Runelm is a control, not a compliance product. The controls map to recognizable objectives in major frameworks.
- SOC 2
- CC6.1, CC6.7, CC7.2, CC9.1, A1.2
- ISO 27001:2022
- A.5.34, A.8.11, A.8.12, A.8.15, A.8.34
- GDPR
- Art. 25, Art. 32, Art. 30
- HIPAA
- 164.312(a)(2)(iv), 164.312(b), 164.312(c)(1)
- PCI-DSS 4.0
- 3.4, 10.2, 11.5
- EU AI Act
- Annex IV, Art. 10, Art. 12, Art. 13