Systems — VIGIL
VIGIL — Governed cybersecurity and evidence platform
Status: Pre-deployment
VIGIL is a cybersecurity platform that helps duly authorized operators find, confirm, remediate, and document vulnerabilities — under one rule: a technical capability is never an authorization. No model or agent can authorize itself, and no finding is trusted until an independent, re-verifiable check confirms it.
At a glance
| System name | VIGIL |
|---|---|
| Category | Governed cybersecurity and evidence platform |
| Status | Pre-deployment |
| Designed for | Public institutions, running on their own infrastructure |
| Standards | Built against OWASP, MITRE ATT&CK, NIST SP 800-115, PTES, and PASTA |
| Authorization model | A technical capability is never an authorization; every consequential action passes a conjunctive, fail-closed authorization chain |
| Source code | Kept strictly private; not published or distributed |
Capability is not authorization
VIGIL's organizing rule is that being able to do something is never permission to do it. Models and agents may observe and propose; they never declare their own authority, and they never declare a finding true. Every consequential action passes a single conjunctive, fail-closed chain before anything runs.
Governance
Identity, role, and a fail-closed risk classifier stand in front of every action. Roles are cumulative — viewer, analyst, operator, owner — and the owner role is the trust root, not a bearer account. WARDEN classifies each action A0–A3 and constrains the approval it needs.
Evidence
A finding is a lead until an independent authority re-verifies it. VIGIL runs a set of deterministic checks — Oracles — that turn an observation into a confirmed fact only when a re-verifiable signal fires. A confirmed fact is signed and can be re-checked offline; a report always separates what is proven from what is merely observed.
Sovereignty
A VIGIL installation belongs to the institution. It runs on the institution's own hardware, and the operator accounts, targets, logs, evidence, keys, and reports stay under the institution's control. SIGIL has no default access, receives no operational telemetry, and holds no hidden administrative account.
What “governed” means in practice
“Governed” is not an adjective of reassurance here; it names three properties, each of which can be checked. The first is authorization. Every consequential action passes one conjunctive, fail-closed chain — a valid local principal, the exact permission, a signed usage right, an authorized scope, a WARDEN risk class, human approval, and egress control — and the absence of any control is a denial, never a default allow. How the authorization chain works walks through every step, including the multi-party quorum a destructive action requires.
The second is evidence. Models and agents may observe and propose, but an observation remains a lead until an independent, deterministic Oracle re-verifies it into a signed fact that can be re-checked offline. The Oracle model — lead versus fact explains what these checks prove and, just as deliberately, what they do not.
The third is ownership. The installation runs on the institution's hardware; keys, evidence, and reports stay under its control; SIGIL receives no operational telemetry; and revocation blocks new sensitive actions without ever touching the institution's access to its own data. Deployment, keys, and revocation sets out the full model.
Sovereignty guarantees
| Guarantee | How VIGIL delivers it |
|---|---|
| Data residency | Runs on the institution's own hardware; targets, logs, evidence, and reports never leave it. |
| Key custody | The institution holds its private keys; SIGIL holds only the public key needed to verify signatures. |
| Telemetry | None by default. SIGIL receives no operational data and does not see engagements. |
| Revocation | Blocks new sensitive actions only; it never blocks the institution's access to its own data, and it is never a remote kill-switch. |
| Source code | Kept strictly private; not published or distributed. |
| Update integrity | Signed builds with a bill of materials; offline import is supported. |
Current state, stated plainly
VIGIL's functional registry records the wiring status of every capability. Nothing on this site is presented as operational that the registry does not mark as live. The two-edition distribution model described in our institutional materials is a planned distribution architecture, not a shipped product.
All VIGIL source code is kept strictly private. It is not published, mirrored, or distributed. Evaluation of the code, where appropriate, happens under a controlled, confidential arrangement — never as a public download.
Questions institutions ask
Can SIGIL access our data or our results?
No. A VIGIL installation runs on your hardware. Operator accounts, targets, logs, evidence, keys, and reports stay under your control. SIGIL receives no operational telemetry by default and holds no hidden administrative account.
Is there a remote kill-switch?
No. Usage rights are verified locally by a signed certificate. If a right is revoked, VIGIL blocks new sensitive actions, but it never blocks your access to your own data, and it can never stop you from stopping the system yourself.
Can a model or agent decide something is vulnerable on its own?
No. Models and agents may observe and propose. A finding becomes a confirmed fact only when an independent, re-verifiable Oracle fires; otherwise it stays a lead. Reports always distinguish the two.
Is VIGIL's source code available?
No. All VIGIL source code is kept strictly private. Where a formal evaluation of the code is appropriate, it is arranged under confidential, controlled conditions.
Which standards is VIGIL built against?
VIGIL is built against established, public methodologies: OWASP testing guidance, the MITRE ATT&CK knowledge base of adversary techniques, NIST SP 800-115 — the technical guide to information security testing and assessment — the Penetration Testing Execution Standard (PTES), and the PASTA threat-modelling methodology. These frame how engagements are scoped, conducted, and documented. This is design alignment, stated as such: no third party has certified conformance, and this page does not claim otherwise.
Can VIGIL run in a disconnected or air-gapped environment?
It is designed to. Usage rights are verified locally against a signed certificate, so the system does not need to reach SIGIL — or any outside network — to operate. Updates are signed, ship with a build manifest and a software bill of materials, and can be imported offline. No telemetry is sent by default, so a disconnected installation gives up nothing except optional version reporting, which in any case sends only a version and channel identifier.