Transactional configuration management for Linux.
Each change is captured before it runs and validated after. If validation fails, Kensa restores the captured pre-state. A failed change is rolled back, not left half-applied. Every change leaves auditable evidence, whether a human or an AI made it.
The transaction model
A change is a transaction, not a best-effort script.
Kensa applies each change as a transaction over the state it manages: capture that state, apply the change, verify the result. Verify passes → commit. Verify fails → restore the captured state. Both paths are recorded.
The transaction's scope is the state Kensa captures, not the host's power, the network, or effects outside it. When something outside that boundary interrupts a run, the append-only transaction log is the source of truth. Within the captured boundary a change is reversible, and every run, completed or interrupted, is accounted for in signed evidence.
An interrupted run isn't a third outcome. Recovery resolves it to one of these, from the log.
How it works
Four phases, one transaction.
If a phase fails, Kensa restores the captured pre-state and records it. Within the captured boundary, the run ends at the target state or the pre-change state, not stuck halfway.
Capture
Record the precise pre-state of whatever is about to be touched. Typed capture handlers for packages, services, sshd, kernel params, SELinux, PAM, crypto policies, and more.
Apply
Make the change with the corresponding remediation handler. Handlers are declarative and idempotent. Run twice, same result.
Validate
Verify the change produced the intended effect and broke nothing else. Services must restart. Configs must parse. Dependent state must stay consistent.
Commit / Rollback
Passed → keep the change, write evidence. Failed → the rollback handler restores captured pre-state automatically, recorded as rolled back.
What makes Kensa different
Six things scanners don't do
Scan + Remediate + Rollback
Typed mechanisms capture pre-state and auto-reverse on validation failure. A failed change is rolled back, not left half-remediated.
One rule, all frameworks
A single rule maps to CIS, STIG, and NIST 800-53 at once. No duplicate content to maintain.
Evidence auditors trust
Structured JSON per check: exact command, stdout, expected vs. actual, timestamp. Machine-verifiable.
YAML rules, not XML
Human-readable, Git-friendly, reviewable by the engineers who manage the systems. Not SCAP.
Adapts to each host
Runtime probes detect capabilities: sshd drop-ins, authselect, crypto policies, FIPS, SELinux. One rule, RHEL 8/9.
Daemonless
No persistent install. An ephemeral helper is staged per run and removed (opt out with KENSA_NO_AGENT=1). Pure SSH, no open ports. Runs across your fleet in parallel.
Quick demo
Three commands to safe remediation.
Scan to see posture. Dry-run to preview the changes. Remediate. Rollback on validation failure is automatic. Daemonless: nothing persistent installed on the target; Kensa works over SSH.
# 1 · Scan a host$ kensa check --sudo -H 192.168.1.10 -u admin -r rules/# 2 · Dry-run remediation (see what would change)$ kensa remediate --sudo -H 192.168.1.10 -u admin -r rules/ --dry-run# 3 · Remediate (rollback on validation failure is automatic)$ kensa remediate --sudo -H 192.168.1.10 -u admin -r rules/
Framework coverage
Full coverage on the platforms you run
Coverage is reported per platform, since what matters for an assessment is the OS you actually run.
The deepest reason Kensa matters
As AI agents increasingly modify production (editing configs in CI, applying patches, responding to alerts), every one faces the same problem: how do I know the change didn't break something, and how do I undo it if it did?
An agent cannot safely mutate production without a primitive that captures state, applies transactionally, validates the outcome, and rolls back on failure. That primitive is Kensa. The agent describes what it wants; Kensa captures, applies, validates, and decides. The human in the loop sees a full transaction log of every attempt, committed or rolled back, with evidence.
Need a dashboard, scheduling, and history?
OpenWatch turns Kensa from a CLI into continuous infrastructure: the eye, the heartbeat, and the control plane. It remembers every transaction Kensa has ever run, across your whole fleet.
FAQ
Kensa FAQ
What is Kensa?
Kensa is a command-line engine that scans, remediates, and rolls back Linux configuration and compliance state. It runs transactionally: it captures the pre-state, applies a change, validates the result, and commits or rolls back automatically.
How does automatic rollback work?
Every change runs through four phases. Capture records the pre-state, Apply makes the change, Validate verifies the result, and Commit or Rollback either keeps the change with signed evidence or restores the captured pre-state when validation fails.
Which compliance frameworks does Kensa cover?
A single rule maps to CIS, STIG, and NIST 800-53 at once, so one rule set covers multiple frameworks without duplicate content to maintain.
Does Kensa need an agent on the target hosts?
No. Kensa is daemonless and runs over plain SSH. There is no persistent agent to install or maintain on the hosts it manages.