--- title: "LLMind security — signed semantic metadata, threat model | LLMind" description: "How LLMind secures file metadata. Signed semantic metadata, HMAC-SHA256 and ed25519, SHA-256 file checksum, responsible disclosure for researchers." url: https://llmind.org/security/ source_format: html --- # LLMind security and signed semantic metadata ## Threat model LLMind is designed to defend against **tampering with file metadata in transit or at rest**. LLMind protects against: - Silent modification of enrichment claims (an attacker modifying the description or entities without detection) - File corruption or replacement - Loss of integrity evidence if a file is moved or copied LLMind does **not** protect against: - An attacker with access to the signing key (symmetric or private key) - Coercion of the original signer - Compromise of the environment where enrichment happens - Disclosure of the file's content itself (encryption is out of scope) The assumption is: a file is either already compromised (content-level threat) or it's trustworthy. LLMind adds a layer that says "the metadata describing this file hasn't been modified." ## LRFS signing scheme summary Each enrichment layer (description, entities, structure, etc.) in the XMP packet is individually signed with either HMAC-SHA256 (symmetric, shared key) or ed25519 (asymmetric, public key). The entire file gets a SHA-256 checksum so consumers can detect if the file content has changed since enrichment. **HMAC-SHA256 (symmetric):** You generate a shared key, enrich files with it, and distribute the key only to your team or trusted downstream consumers. Only someone with the key can verify a signature. This is appropriate for private corpora within an organization. **Ed25519 (asymmetric):** You generate a keypair. The CLI signs with the private key. You publish the public key. Anyone with the public key can verify a signature without your private key. This is appropriate for public datasets, published research, or open-source software. For complete technical details, see [/spec/signing-scheme/](https://llmind.org/spec/signing-scheme/). ## Self-hosted deployment LLMind is an open-source Python library. It runs anywhere Python runs. No external service required. No telemetry. No phone-home. You can run the CLI on your laptop, in your datacenter, in a CI/CD pipeline, or in an air-gapped environment. You control the signing keys. You control the enrichment pipeline. You own the data. If you need to integrate LLMind into a compliance framework (SOC 2, HIPAA, PCI-DSS), you do so by running it in your own audited environment. The library itself doesn't provide those guarantees — your infrastructure and policies do. ## Responsible disclosure If you discover a security vulnerability in LLMind, please email [security@llmind.org](mailto:security@llmind.org) (or [hello@llmind.org](mailto:hello@llmind.org) until a dedicated address is set up) with: - A clear description of the vulnerability - Steps to reproduce it - The impact (e.g., signature bypass, key leakage, etc.) We aim to acknowledge all reports within 72 hours. We'll work with you to fix the issue before public disclosure. Do not open public GitHub issues for security vulnerabilities — give us time to coordinate a response. We do not currently offer a bug bounty program, but we will recognize responsible disclosure researchers by name (with permission). As LLMind matures, we may establish a formal bounty program. ## What we don't do **No SOC 2, ISO, or PCI certifications:** LLMind is a library, not a service. Certifications apply to services that process and store data. Your deployment's compliance depends on your environment, not the library. **No hosting or managed service:** We don't run a SaaS platform that stores files or signing keys. The web converter (app.llmind.org) is a convenience tool that processes files in-browser; files are not persisted. For sensitive workflows, run the CLI yourself. **No encryption:** LLMind signs metadata to detect tampering. It does not encrypt file content. If you need encryption, layer that on top (use LUKS, BitLocker, or any file-level encryption before enrichment). **No key rotation service:** You manage signing keys like any other sensitive material. Use a key management system (HashiCorp Vault, AWS KMS, etc.) if needed. LLMind doesn't provide that infrastructure. ## FAQ - ### Is LLMind SOC 2 compliant? No. LLMind is an open-source Python library, not a hosted service. Compliance certifications like SOC 2 apply to services that process and store customer data. Your self-hosted deployment inherits your environment's compliance posture — if you run LLMind in a SOC 2 audited environment, your deployment is compliant. We provide the tool; your infrastructure provides the guarantees. - ### Can I verify a signed file without access to the signing key? Yes, if it was signed with ed25519 (asymmetric). With ed25519, anyone with the public key can verify a signature. With HMAC-SHA256 (symmetric), only the holder of the shared key can verify. Choose ed25519 for public datasets or published research where verification is a feature. Use HMAC-SHA256 for private corpora where only your team needs to verify. - ### Does LLMind transmit my files anywhere? No. The Python CLI and all components are open-source and run locally. Files never leave your machine unless you explicitly send them. The web converter (app.llmind.org) processes uploads in-browser before sending to a backend for enrichment; files are not retained. Read the privacy policy at app.llmind.org for browser converter details. - ### Which signing algorithm should I use? Use ed25519 for public datasets, published research, or scenarios where third parties need to verify signatures without your key. Use HMAC-SHA256 for private corpora within an organization where only your team holds the key. Ed25519 is also faster and produces smaller signatures. For new deployments, ed25519 is the default. - ### How do I report a security issue? Email security@llmind.org (or hello@llmind.org if that address is not yet set up) with reproduction steps and details. We aim to acknowledge reports within 72 hours. Do not open public GitHub issues for security vulnerabilities — give us time to respond and coordinate a fix.