Architecture invariants
These properties must hold for every Sundew deployment. If any invariant is violated, the deployment is compromised and must be torn down.Canary token safety
Sundew generates canary tokens (fake credentials) that AI agents may discover and attempt to use. All canary values are designed to be harmless:
Every canary value is validated at startup via
sundew.canary.is_verifiably_fake(). Deployment fails if any canary could be mistaken for a real credential.
Risk: pivot to host network
Scenario: An attacker exploits a vulnerability in Sundew or its dependencies to pivot to the host network. Mitigations:- Docker network isolation with
--network=noneor dedicated internal bridge - Read-only root filesystem (
--read-only) - No capabilities (
--cap-drop=ALL) - Seccomp default profile
- No volume mounts except
./data/ - Regular dependency audits via
make audit
Risk: log storage exhaustion
Scenario: Attacker floods the honeypot, filling disk and crashing the host. Mitigations:- SQLite max size: 500 MB (oldest events pruned automatically)
- JSONL rotation: 100 MB with 5 backups
- Docker storage limit:
--storage-opt size=1G - Rate limiting: 100 req/s per source IP
Risk: fingerprinted as Sundew
Scenario: An agent detects patterns shared across Sundew deployments. Mitigations:- Persona engine generates unique responses, headers, timing, and error formats per deployment
test_anti_detection.pyverifies zero cross-instance correlation across 5 different personas- For highest security, use fully custom persona packs (not generated)
Security auditing
Run the full audit:pip-audit-dependency vulnerability scanbandit -r src/-static analysis for Python security issuespytest tests/test_security.py-runtime invariant verificationpytest tests/test_anti_detection.py-anti-fingerprinting verification
Responsible disclosure
Report security vulnerabilities to contact@sundew.sh with subject[SUNDEW-SECURITY].
Do not file public GitHub issues for security vulnerabilities.