| Version | Supported |
|---|---|
| 0.1.x | ✅ |
MIND is designed with specific security properties:
| Property | Description |
|---|---|
| Determinism | No randomness, no hidden state |
| Bounded memory | Fixed allocation, no growth |
| No network | No outbound connections |
| No filesystem | Only explicit save/load |
| No execution | Cannot run arbitrary code |
| Non-Goal | Reason |
|---|---|
| Adversarial embedding resistance | Out of scope |
| Side-channel protection | Not designed for |
| Cryptographic security | Not applicable |
| Memory encryption | Host responsibility |
MIND assumes:
- The host process is trusted
- Embeddings come from trusted sources
- State files are stored securely
- The runtime environment is not compromised
MIND does not defend against:
- Malicious embeddings designed to poison memory
- Compromised host processes
- Physical access attacks
- Memory inspection by other processes
Do not report security vulnerabilities through public GitHub issues.
Instead, please report them via email to:
Include:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Suggested fix (if any)
| Stage | Timeframe |
|---|---|
| Acknowledgment | 48 hours |
| Initial assessment | 7 days |
| Fix development | 30 days |
| Public disclosure | 90 days (coordinated) |
- Acknowledgment — We will confirm receipt of your report
- Assessment — We will evaluate severity and impact
- Communication — We will keep you informed of progress
- Credit — We will credit you in the advisory (unless you prefer anonymity)
When using MIND:
# Restrict permissions
chmod 600 mind.state
# Store in secure location
mv mind.state /secure/path/
# Consider encryption at rest- Validate embeddings before feeding to MIND
- Use trusted embedding models
- Monitor for anomalous patterns
- Run MIND in isolated processes
- Use sandboxing where available
- Limit file system access
- Monitor resource usage
MIND welcomes security audits. If you are conducting a security assessment:
- Contact us at security@mind-project.org
- We will provide a point of contact
- We can arrange access to development builds
- We will coordinate disclosure
When all memory slots are full, new experiences are silently ignored. This is by design (bounded memory) but could be exploited to prevent learning.
Mitigation: Monitor slot utilization via cr_state_temporal().
Plasticity never reaches zero (ε = 0.05), meaning the system is always slightly malleable. This is by design (mercy) but means beliefs can always be influenced given enough repetition.
Mitigation: This is a feature, not a bug. Design your system accordingly.
S2S calibration signals are not authenticated. A malicious peer could send false calibration data.
Mitigation: Authenticate peers at the transport layer. MIND does not handle authentication.
| Date | Change |
|---|---|
| 2026-02-12 | Initial security policy |