The fleet eye, heartbeat, and control plane for Kensa.
Continuous visibility into every transactional change across your Linux fleet. Proactive drift detection. Audit-ready evidence, automatically. For humans, compliance teams, and the AI agents that will operate production alongside them.
Three identities, one system
The Eye, the Heartbeat, and the Control Plane.
The Eye
Comprehensive view
Every change Kensa has ever made, on every host and across every fleet, stays visible and queryable. Nothing is lost. The transaction log is the primary interface.
Continuous · auditable · exportable to OSCAL
The Heartbeat
Proactive awareness
OpenWatch scans on a schedule whether a human is watching or not, with cadence that adapts to host health. It detects drift from baseline and raises an alert, so you catch it before an assessment, not during one.
Drift detection · liveness · adaptive scheduling
The Control Plane
Where the fleet is operated
Describe a change across your fleet, preview exactly what will be captured, applied, and rolled back, approve, and OpenWatch orchestrates it. Humans approve; agents operate; OpenWatch mediates and records intent.
The surface AI agents talk to, not Kensa directly
Capabilities
What OpenWatch does
Continuous compliance posture
Adaptive scheduling keeps the dashboard live, with scan cadence that adapts to host health.
Temporal compliance queries
"What was our STIG posture on February 1st?" Answered from the transaction log, no re-scan needed.
Compliance drift detection
When a passing rule starts failing, OpenWatch raises an alert automatically and tracks it to resolution.
Governance & exceptions
Request, approve, reject, time-limit, revoke: structured workflows with a full audit trail. No more spreadsheets.
Audit-ready evidence
Every check captures the exact command, output, expected vs. actual. Export as CSV, JSON, PDF, or signed OSCAL.
Multi-framework, single scan
One scan maps to STIG, CIS, and NIST 800-53 simultaneously. Same evidence, many assessors.
Architecture
One engine underneath. No exceptions.
Every transaction runs through the Kensa primitive. There is no parallel scanning path. The transaction log in PostgreSQL is the single source of truth that humans, auditors, and agents all read from.
┌─────────────────────────────────────────────────────────┐
│ You · Your team · (future) AI agents │
└────────────────────────────┬────────────────────────────┘
│ Control Plane API
┌────────────────────────────▼────────────────────────────┐
│ OpenWatch · dashboard + API │
│ Transactions · Posture · Drift · Exceptions │
│ Evidence · OSCAL export · RBAC · Audit │
├─────────────────────────────────────────────────────────┤
│ Kensa engine · scheduled workers │
│ scan · validate · rollback · drift · heartbeat │
├─────────────────────────────────────────────────────────┤
│ Transaction log · single source of truth │
└────────────────────────────┬────────────────────────────┘
│ SSH · port 22 · agentless
┌────────────────────────────▼────────────────────────────┐
│ Your Linux fleet · RHEL 8/9 · Rocky · AlmaLinux │
└─────────────────────────────────────────────────────────┘Security
Built for regulated environments.
Agentless by design, with an audit trail for control-plane actions: who approved what, and when.
API-first · agent-ready
The Control Plane is the surface automation talks to.
Frontends and agents consume the same OpenAPI contract, with RBAC, idempotency, and audit built in. An automation client that wants to change production doesn't get a shell. It files a remediation request for one rule on one host, which enters the governance lifecycle with the projected compliance lift attached. A human signs off (separation of duties: the approver can't be the requester); execution runs through Kensa's Capture/Apply/Validate/Commit; the result flows back into the audit log.
Authorization enforced. Intent recorded. Evidence captured. Audit trail by construction.
# An automation client requests a fix through the Control Plane,
# not by SSH-ing into the host directly. This call does not touch the host.
POST /api/v1/remediation/requests
Authorization: Bearer owk_<api-token> # role-scoped service-account token
Content-Type: application/json
{
"host_id": "app-7-prod-uuid",
"rule_id": "ssh-disable-root-login",
"scan_run_id": "scan-uuid" # optional provenance
}
→ 201 Created
{
"id": "a1f3...-7f3a",
"host_id": "app-7-prod-uuid",
"rule_id": "ssh-disable-root-login",
"status": "pending_approval",
"requested_by": "operator-uuid",
"transactional": true,
"reboot_required": false,
"projected_lift": { "cis": "…", "stig": "…", "nist": null },
"requested_at": "2026-05-06T14:22:10Z"
}
# A different human approves (separation of duties enforced):
POST /api/v1/remediation/requests/{rid}:approve → status: approved
# Then execution is queued; Kensa applies the fix and journals each step:
POST /api/v1/remediation/requests/{rid}:execute → 202 Accepted
# poll GET /api/v1/remediation/requests/{rid} for executed | failedWant the CLI instead of the platform?
Kensa is the compliance engine OpenWatch runs on: full CIS, STIG, and NIST 800-53 rule coverage, typed remediation mechanisms, automatic rollback, all over SSH. If you want a single binary for scripts and pipelines, start there.
FAQ
OpenWatch FAQ
What is OpenWatch?
OpenWatch is a compliance operating system for Linux fleets. It provides continuous posture, drift detection, temporal queries, governance workflows, audit-ready evidence, and an API-first control plane.
How does OpenWatch relate to Kensa?
OpenWatch is the control plane; every change it orchestrates runs through the Kensa transaction primitive (capture, apply, validate, commit or rollback). Kensa is the engine, and OpenWatch is the fleet-wide dashboard and API on top of it.
Is OpenWatch agent-based?
OpenWatch drives changes through Kensa over SSH, so there is no separate persistent agent required on the managed hosts.
What evidence does OpenWatch produce?
Structured, machine-readable evidence for every check, including OSCAL output, so results can be handed to auditors directly.