Security
What's protected, and how you check.
Every claim below is either verifiable from the source or observable on a running device. Where something is not yet built, this page says so rather than implying otherwise.
Where your data goes
The short version: conversations, files, memory and provider keys stay on your device. Below is what leaves it, exhaustively.
| Data | Where it lives | Leaves the device? |
|---|---|---|
| Conversations and memory | Device disk | Never |
| Mounted files | Wherever you mounted them | Never |
| Model provider API keys | /etc/deputyos/secrets.env (0600) | Never — not even to us |
| Prompts and responses | Device, plus your model provider | Only to the provider you configured, directly |
| Backups | Your bucket, or our managed tier | As ciphertext only — encrypted before upload |
| Telemetry | — | There is none |
| Device heartbeat (if linked) | Control plane | Status and version only, no content |
Don't take our word for it. Watch
egress with tcpdump or at your router, or boot the
air-gapped tier with the cable out and see that it still works. That test
is worth more than this page.
On by default, not on request
Every control below is active from first boot with no checkbox. Security that requires configuration is security most people never get.
- AppArmor
- Enforce mode, one profile per assistant profile. The agent is confined to its own paths; a compromised assistant cannot read arbitrary files.
- Firewall
- ufw default-deny inbound. Nothing is reachable unless it was explicitly opened.
- fail2ban
- Ban-on-repeat for authentication surfaces, active from boot.
- Hardened sysctls
- Kernel parameters tightened at bake time rather than left at distribution defaults.
- ClamAV
- Signature database pre-loaded in the image, so scanning works with no network.
- Magika
- Content-type detection on the agent file-upload path, so a renamed executable is caught by content rather than extension.
The chain from source to device
A signature proves who built something. It does not prove what they built it from — which is exactly the gap supply-chain attacks exploit. Each link below closes a different part of that gap.
- 1
Source
Apache-2.0, public. Every line that ends up in an image is readable.
- 2
Reproducible build
Bit-pinned inputs so the same source yields the same bytes. You can rebuild and compare hashes rather than trust us.
- 3
Signature
minisign over every artefact. Proves who published it.
- 4
Attestation
SLSA provenance describing which source, builder and inputs produced the artefact. Proves where it came from.
- 5
SBOM
CycloneDX inventory of every component, so a new CVE can be answered in seconds.
- 6
Verification on device
The updater checks signature and checksum before an image is staged. An unverified artefact never boots.
Full detail in the update trust chain .
What we do not claim
A security page that only lists strengths is not useful. These are the real limits as of this release.
- No third-party audit yet. The trust chain has not been independently reviewed. Commissioning one is part of procurement readiness, and this page will say so when it happens.
- SLSA L3 is not complete. Attestations ship today, but full L3 needs a second independent build host producing bit-identical output. That verifier is not yet running.
- The agent can act. An assistant that runs commands and touches files is a large blast radius by design. AppArmor confines it and mounts are revocable, but mount narrowly and treat the device as trusted infrastructure.
- Cloud models see your prompts. If you configure a hosted provider, prompts go to that provider under their terms. Only the air-gapped tier or a local model avoids this.
- Lose the backup key, lose the backups. Client-side encryption means we cannot recover your data. That is the point, and it is also a real operational risk.
Reporting a vulnerability
Email security@deputyos.com. We aim to acknowledge within two working days and to ship a fix or a documented mitigation within 90 days, coordinating disclosure with you.
Please do not open a public issue for a security report. Full policy, including scope and the disclosure timeline, is in reporting vulnerabilities .