Know Who Changed What, When - and Whether It Was Authorized

Monitoring tells you your servers are healthy. Change tracking tells you why they suddenly aren't. Every SSH session, every command, every file change on your servers - recorded at the kernel level, tied to who did it, and checked against the windows when change was actually allowed.

Every session, every command, every file change

The agent watches at the kernel with eBPF, so nothing needs to opt in to being tracked. There is no audit daemon to configure and no shell history to trust.

What gets recorded

  • SSH login sessions: who logged in, from where, for how long - with trusted-source allowlists
  • Commands executed on the host, captured at the kernel, not from shell history
  • File changes on paths you care about, with the process and user that made them
  • YARA scans on changed files, so a "config tweak" that drops malware gets caught in the same event
  • Out-of-hours activity: logins and changes outside business hours raise their own alerts

Was it authorized?

A change on production is either expected or it is an incident. Frameworks like SOX and PCI DSS have said this for years: production changes happen through authorized workflows, inside approved windows, with evidence. AlertKick applies the same rule to every session and file change it sees - a deploy during a maintenance window looks routine; the same commands at 2 AM on a Sunday from an unknown IP look like a breach, and get alerted as one.

Maintenance windows that actually enforce

Most tools treat maintenance windows as alert-silencing. AlertKick treats them as access control. Outside a window, SSH to protected hosts is locked at the host itself - not just monitored, blocked. Open a window and access returns for its duration; when the window closes, the host locks again.

Built for real operations

  • SSH lockdown enforced on the host, with trusted-source allowlists for the access that must always work
  • Time-boxed windows: locks release for the window and re-apply when it ends
  • Fail-safe by design: if the agent loses contact, a dead-man switch releases the lock so you are never locked out of your own server - and tells you it happened
  • Brute-force sources auto-blocked from failed-login patterns, no fail2ban setup required

Built for the fleet you'll run next: humans, pipelines, and AI agents

More and more production changes are made by machines - CI pipelines today, AI agents increasingly. That makes the question "who changed what, and was it authorized" harder and more important at the same time. An agent that operates your servers cannot also be the thing that audits them. AlertKick sits outside the actors making changes and records what actually happened at the kernel - ground truth that does not depend on any actor's own report.

Coming next: closed-loop change management

The direction we are building towards: a change is declared before it happens - by an engineer, a pipeline, or an AI agent - with its scope and expected effects. The affected hosts unlock for that change only. When it completes, AlertKick independently verifies that what changed matches what was declared - file diffs against declared scope, malware scans on changed paths, health checks green - then locks the hosts again. The full record becomes your change-management audit evidence, generated automatically.

Session tracking, maintenance windows, file integrity monitoring, and compliance evidence above are available today and form the foundation of this loop.

Feeds your compliance evidence

Every session, change, and window is the kind of evidence SOX and PCI DSS auditors ask for. AlertKick maps these events to controls automatically and includes them in generated compliance reports - see Compliance Monitoring.

Your servers, watched by tonight.

Install one agent. Get security monitoring, infrastructure alerts, and on-call management - all included with every host.

Start watching - free View All Features