Governance
Governance
Every change to detection rules or data-source configuration passes through a staged intake that validates, previews, and audits before anything persists. Approval and activation are always separate steps.
Staged intake
Control Desk treats configuration changes — new detection rules, new data sources — as candidates that must pass through an explicit intake flow before they can affect a run.
Rule intake
A candidate detection rule is first validated: the system checks that it is structurally well-formed, references real canonical fields, and does not conflict with existing rules in ways that would produce undefined behavior. If validation passes, the rule can be previewed: the system shows what findings it would produce against the current data, without writing anything. No state changes during validate or preview. Only an explicit approval action persists the rule — and that approval always lands the rule in the inactive state.
Data-source intake
A candidate data source goes through a parallel flow: the connector configuration is validated, the source is read and its records are shown in canonical form as a preview, and structural checks are run against those records — all without persisting anything. Approval persists the source in the inactive state. Activation is a subsequent, deliberate action.
Approve is not activate
This separation is enforced, not documented. When a rule or data source is approved, the system writes it in the inactive state regardless of what was submitted. There is no way to approve something and have it become active in the same action. Activation requires a separate, authenticated request.
The effect is that an operator can build a queue of approved-but-not-yet-active rules, review them as a set, and choose when to promote them to active — without the act of review itself changing detection behavior. This matters in environments where changes need sign-off before they go into effect.
Atomic, audited write-back
All configuration writes are atomic: a change either commits in full or rolls back entirely. A partial write — where some fields updated and others did not — cannot occur. This means the configuration is always in a known, complete state.
Every write is accompanied by an audit record that captures the before and after state. The audit trail is append-only: it cannot be modified through the normal operation path. An operator can reconstruct the full configuration history at any point in time by reading the audit trail forward from the initial state.
Single-administrator gating
Every write and every activation is gated behind single-administrator authentication. The model is deliberately narrow: one authenticated administrator controls what can enter the active configuration. This is a scope decision, not a technical limitation. Multi-user roles and permissions are on the development roadmap, but the current model is single-admin by design — a deliberate boundary that keeps the audit trail readable and the governance surface small.
Read access to rules and data-source configurations does not require authentication. An operator can inspect the current active configuration, view rule definitions, and browse source metadata without logging in. Writes and activations require authentication.
Dry-run grading of candidate rules
Before a candidate rule is activated, it can be dry-run graded. The dry run checks two things:
- False-positive check: the candidate rule is evaluated against a corpus of known-good data. If the rule fires on clean data, those are false positives, and the candidate may need refinement before it is safe to activate.
- Recall check: the candidate rule is evaluated against a corpus with a planted break of the type the rule is designed to catch. The check verifies that the rule fires — that it would have caught the break — before activation.
Both checks run without activating the rule. The results are visible in the intake flow so the operator can make an informed decision before committing the activation.
The AI rule miner
Control Desk includes an AI-assisted rule miner for use at authoring time. An operator can paste policy text, data documentation, or a description of a known problem class, and the miner will generate candidate detection rules drawn from that text. Every candidate must cite the passage it was derived from — a candidate without a citation is not produced.
The rule miner is a tool for the operator, not an autonomous agent. Its output enters the same intake flow as any manually authored rule: validate, preview, approve, then activate as a separate step. The miner never activates rules on its own. It never runs during a detection run. It is an authoring-time assistant that feeds the same governance gate as everything else.
For how governance rules interact with detection runs, see Detection. For the pipeline step where audit records are written, see Pipeline.