Security is the product
Our customers are CISOs and security engineers. They scrutinize the security posture of their tools. Every architectural decision in LLMSec reflects this. This page documents what we've built, why, and what our threat model looks like.
Architectural principles
No data crosses the boundary
LLMSec runs entirely inside the customer's network. Probe prompts, model responses, findings, and reports never leave the customer's infrastructure. This is not a policy commitment — it's a structural property of the architecture.
Offline license verification
License keys are Ed25519-signed blobs verified against a public key baked into the binary. No network call is required for license validation. Air-gapped environments are supported by design.
Deterministic scans
Same configuration produces the same scan. Random-seeded attacks record their seeds. Scan fingerprints provide tamper-evidence. Reports can be verified by re-running the scan with the same inputs.
Honest about judge limitations
Automated judges have known false-negative problems. We publish calibration metrics, use ensemble approaches, and never claim >95% detection accuracy. Credibility comes from transparency.
Threat model
What we've considered, what we've mitigated, and what we've explicitly accepted:
| Threat | Mitigation | Severity |
|---|---|---|
| Supply chain compromise | Pinned dependencies and lockfiles. Every Docker image is scanned with Trivy at release. SBOM published with every release. SLSA Level 3 target. | High |
| License system bypass | Software DRM is bypassable by motivated adversaries — we rely on contractual and regulatory deterrence. Regulated fintechs don't pirate enterprise security tools; it's traceable and an audit finding. | Low (accepted) |
| Compromised LLMSec instance leaks data | Scan data encrypted at rest. Prompts and responses never logged by default. OWASP ASVS L2 baseline. Single-tenant by design — no tenant isolation breach risk. | Medium |
| Tampered reports | Ed25519 signature over all inputs and outputs. Scan fingerprint embedded in report. Future: public verify endpoint at llmsec.io/verify/<report-id>. | High |
| Prompt injection of judges | Ensemble judges (multiple independent assessors). Published calibration metrics. Human review queue for UNSURE verdicts. Transparency about judge limitations. | Medium |
Advantages of the on-prem model
The on-prem deployment model significantly reduces the security surface compared to SaaS alternatives:
No tenant isolation breach risk
LLMSec is single-tenant by design. Each deployment serves one organization. There is no multi-tenant infrastructure for attackers to exploit.
No exposure of our infrastructure
We don't run the scanner for customers — they run it. There is no LLMSec scanner server to attack. Our attack surface is limited to the marketing site.
No SOC 2 burden
We never receive customer data. SOC 2 Type II audit costs ($30–100K/year) are irrelevant for our model. Customers are not relying on our security posture for their data.
Air-gapped environments
LLMSec can run with no internet access. License verification is offline. No network egress required for scanning. Updates can be applied manually from signed bundles.
Security standards
OWASP ASVS L2
Current targetApplication Security Verification Standard Level 2 for the scanner and CLI.
SLSA Level 3
TargetSupply chain integrity for build artifacts. Pinned deps + signed releases.
SOC 2 Type II
Not requiredWe don't host customer data, so SOC 2 is irrelevant for our model. Customers are not relying on our posture for their data.
Penetration test
Planned post-3 customersThird-party pen test of the product binary. Deferred until we have budget from first license deals.
Data-handling commitments
- We never receive, store, or process your scan inputs, model outputs, or report contents.
- LLMSec does not phone home. No analytics, usage tracking, or scan telemetry by default.
- License keys are cryptographic tokens verified locally. They are not API keys that call our servers.
- If you opt in to anonymized telemetry (off by default), only aggregate statistics are shared — never individual scan data.
- No cookies, tracking pixels, or analytics on demo calls or customer interactions beyond what you explicitly consent to.