Vigilbase OS never changes anything in your providers without a person's approval. Every change is an action plan, and an authorised member approves the exact steps they want to run. Your organisation's policy sets the rules for those approvals and for what Vigil may start on its own.
Action plans
An action plan describes a change precisely before anyone approves it:
- the target resources and the exact changes, shown as a diff
- the rationale and the evidence it cites
- each step's effect class: Reversible, Compensatable or IRREVERSIBLE
- blast radius, prerequisites, protected resources, estimated cost and timing
- how each step will be verified
- optional recovery steps
- an expiry, a version and a SHA-256 hash of the whole plan
There are two kinds of plan. A remediation plan belongs to an investigation and cites its evidence. A collection setup plan sets up delivery of telemetry to Vigilbase, such as a Cloudflare Logpush job, and is proposed from the connection's setup controls.
What an approval binds to
When you approve, you select each step you want to run. Nothing is approved by default, and recovery steps are never included unless you tick them. Your approval is bound to the plan's version and hash, the policy version and an expiry. If the plan, its targets, its parameters or its evidence change, the approval no longer applies.
Before every step runs, Vigilbase checks again that:
- the approval has not expired or been revoked, and you still have authority to approve
- the policy and credentials still allow it
- no kill switch is engaged
- the target has not changed since the plan was made (drift)
If any check fails, the step does not run.
Step-up
Approving or rejecting a plan always needs a recent confirmation that it's you: an authenticator code, or a sign-in with multi-factor authentication, within the last hour. This happens in a Vigilbase Identity window and cannot be turned off. Some sensitive steps ask for a fresher confirmation.
What your policy controls
Owners and members with policy rights edit the policy in Settings. Saving creates a new policy version.
| Setting | What it does |
|---|---|
| Require separation of duties | The person who proposed a plan can never approve it. Always enforced for critical actions. |
| Self-approval | With separation of duties on, owners and admins may approve their own collection setup plans for the actions you tick, such as Logpush setup and removal. Response actions and critical actions always need a second person. |
| Approval lifetime (minutes) | Approvals expire if the plan is not executed within this time. |
| Critical action keys | Action keys that always need a second person. Some actions are marked critical by their connector as well. |
| Protected resources | Resources that plans are blocked from targeting or that need extra review. |
| Compatible earlier versions | Earlier policy versions whose approved plans stay executable. Plans still awaiting approval must always be recreated after a policy change. |
| Allowed model providers | The AI model providers Vigil may use for your organisation. |
| Vigil autonomy | What Vigil may start on its own: Collection, Analysis and Investigation. |
What Vigil may do
Vigil is read-only. It can search evidence, open and update investigations and propose plans, within the tools and budgets your organisation allows. It has no write tools, whatever your Vigil autonomy settings say. Only the action runtime changes a provider, and only for an approved plan.
Text inside logs, emails, provider labels or documents is treated as evidence, never as an instruction to Vigil.
Kill switch
The organisation Kill switch immediately blocks every action execution. Running executions halt at the next step boundary and no new step starts. Detection, collection and investigation continue. Vigilbase can also engage a global kill switch for all organisations, which you cannot release yourself. See Settings.