Security
What VigilantDev protects, and what it does not.
A security product should say where its protection ends. This is the threat model for the first release.
Protects against
- A compromised console or cloud. An attacker with full control of the console can only send requests the device policy already allows.
- A misled AI agent. Prompt injection or a bad plan cannot reach capabilities the device has not allowed.
- An operator going too far. Remote staff work inside each device's policy, and every request is recorded on the device.
- A rogue update to policy. Policy changes need a local administrator's approval on the machine.
Does not protect against
- Someone who already has local admin rights. They can change the policy or remove the agent. Protect local accounts as you do today.
- Malware already running on the device. VigilantDev limits what arrives remotely. It is not antivirus.
- A policy that allows too much. If a capability is set to
allow, the device will run it.
Design principles
Small surface, clear rules.
| Deny by default | A capability the policy does not mention is refused. |
|---|---|
| No shell | The agent only runs typed capabilities with validated parameters. |
| Outbound only | The agent connects out to the console. No inbound ports are opened. |
| Local authority | The policy file is changed on the device, never pushed. |
| Tamper-evident ledger | Hash-chained entries on the device record every request and verdict. |
| Open source agent | The code that runs on your machine will be public. |
Disclosure
Found a weakness? Tell us first.
Write to us with the details and steps to reproduce. We reply within two business days and credit researchers who want it.
enes@vigilantdev.com