VIGIL — Sovereignty
Deployment, keys, and revocation
The sovereignty model is concrete. The institution controls the hardware, the keys, the targets, the logs, the evidence, and the reports. SIGIL's role stops at signing the software and issuing usage rights.
No backdoor, no telemetry, no hidden account
Both editions run on the institution's infrastructure. Operator accounts, targets, logs, evidence, reports, keys, and results stay under the institution's control. SIGIL has no default access to that data, does not see engagements, and holds no hidden administrative account.
A revocable right that is not a kill-switch
An installation with no telemetry — possibly air-gapped — cannot be revoked instantly from afar without introducing a control channel, and that channel would contradict sovereignty and create risk. Instead, usage rights take the form of a signed usage-rights certificate, verified locally. The institution holds only the public key needed to verify it.
What revocation does, and does not, do
| Always permitted | Blocked on expiry or revocation |
|---|---|
| Read, search, and export your data | New active scans |
| Verify and replay existing evidence | Launching advanced engines |
| Backup, staging restore, and migration | Creating new permits |
| Emergency stop and safe shutdown | Re-enabling or bypassing the status |
Revocation blocks new sensitive actions. It never blocks the institution's access to its own data, and it never prevents the institution from stopping the system.
Updates and support
Updates are signed and shipped with a build manifest and a software bill of materials; offline import is supported. Optional version reporting sends only a version and channel identifier — never assets or results. Support receives only a redacted diagnostic bundle generated locally and shared voluntarily. For a sensitive incident, temporary access must be approved by the institution, logged, bounded, and revoked at closure; the default remains no access.